[Bug]: A security issue regarding flink-kubernetes-operator

[sparkEchooo]

What happened?

Summary

The jaeger-operator in GKE gave excessive authority when defining Service Account named "jaeger-operator-operator-serviceaccountname-d705". Besides, this Service Account is mounted in a deployment named "jaeger-operator-1-jaeger-operator", witch makes it possible for attackers to raise rights to administrators.

Detailed Analysis

1. I deployed jaeger-operator in the marketplace of Google's GKE cluster.
2. The clusterrole named "jaeger-operator-1:operator.serviceAccountName-r0" defines the "*" verbs of "*". And this clusterrole is bound to the Service Account named "jaeger-operator-1-jaeger-operator".

Attacking Strategy

If a malicious user controls a specific worker node which has the deployment mentioned above , or steals the Service Account token mentioned above. He/She can raise permissions to administrator level and control the whole cluster.

Mitigation Discussion

• Developer could use the rolebinding instead of the clusterrolebinding to restrict permissions to namespace.
• Developer could specify specific permissions instead of using "cluster-admin"(*.* permissions).

A few questions

• Is it a real issue in jaeger-operator?
• If it's a real issue, can jaeger-operator mitigate the risks following my suggestions discussed in the "mitigation discussion"?

If it's a real issue, does jaeger-operator plan to fix this issue?

Steps to reproduce

1. get the token
2. control the cluster

Expected behavior

Permission escalation

Relevant log output

No response

Screenshot

No response

Additional context

No response

Jaeger backend version

No response

SDK

No response

Pipeline

No response

Stogage backend

No response

Operating system

No response

Deployment model

No response

Deployment configs

No response

[sparkEchooo]

Dear jaeger-operator maintainers, I am Xingyu Liu, and I found this potential risk in jaeger-operator that can be leveraged to get the cluster's admin token, resulting in cluster-level privilege escalation. These are some similar issues that have been confirmed for your reference: kubewarden (https://nvd.nist.gov/vuln/detail/CVE-2023-22645) Clusternet (https://nvd.nist.gov/vuln/detail/CVE-2023-30622) OpenFeature (https://nvd.nist.gov/vuln/detail/CVE-2023-29018)

I hope this information will assist you in better understanding and addressing my report. If you require any further details about the report itself, please feel free to contact me. Looking forward to your reply!

[pavolloffay]

I wonder who manages configuration files for https://console.cloud.google.com/marketplace/product/google/jaeger-operator. It shows Jaeger version 1.45 which is quite old (the new one is 1.55).

I would recommend installing jaeger-operator via officially maintained https://operatorhub.io/operator/jaeger. The required RBAC is defined in https://github.com/k8s-operatorhub/community-operators/blob/main/operators/jaeger/1.55.0/manifests/jaeger-operator.clusterserviceversion.yaml#L108.

The official documentation also covers how to install the operator without cluster roles https://www.jaegertracing.io/docs/1.56/operator/#install-modes

[sparkEchooo]

Hi! Sorry for the delay.

I would like to inquire if there are any plans to update the Jaeger version on the GCP Marketplace. If an update is planned, would it be possible for us to receive public thanks for our efforts? We believe that such recognition would be a great encouragement for our team and would further motivate us to contribute to the enhancement of the platform.

If you're looking to update Jaeger on the GCP Marketplace, this might help: "https://cloud.google.com/marketplace/docs/partners/kubernetes/maintaining-product".

Reporter List

• Xingyu Liu([ll.travor@outlook.com])
• Nanzi Yang([nzyang@stu.xidian.edu.cn])
• Jinku Li([jkli@xidian.edu.cn])

Looking forward to your reply!

[iblancasa]

As @pavolloffay pointed, we don't manage the GCP Marketplace Jaeger Operator. Also, we don't know who maintains it.