everettraven
commented
2 months ago @HouqiyuA Thanks for raising this issue, would you mind sharing where this potential risk was identified?
I'm not sure there is any actual risk of this happening (could definitely be wrong) as the operator-sdk is a tool for scaffolding an operator project and it is up to operator authors to ensure they are following best practices regarding permissions and security.
Dear Team Members:
Greetings! Our team is very interested in your project and we recently identified a potential RBAC security risk while doing a security assessment of your project. Therefore, we would like to report it to you and provide you with the relevant details so that you can fix and improve it accordingly.
Details:
In this Kubernetes project, there exists a ClusterRole that has been granted list secrets high-risk permissions. These permissions allow the role to list confidential information across the cluster. An attacker could impersonate the ServiceAccount bound to this ClusterRole and use its high-risk permissions to list secrets information across the cluster. By combining the permissions of other roles, an attacker can elevate the privileges and further take over the entire cluster.
We construct the following attack vectors to address the above risks:
First, you need to get the Token for the ServiceAccount that has this high-risk privilege. if you are already in a Pod with this over-privileged privilege, you can run the following command directly to get the Token: cat /var/run/secrets/kubernetes.io/serviceaccount/ token. If you are on the node and not in the Pod, you can run the following command to get the kubectl describe secret.
Use the obtained Token information to authenticate with the API Server. By including the Token in the request, you can be recognized as a legitimate user with the ServiceAccount and gain all privileges associated with the ServiceAccount. This ServiceAccount identity can therefore be used to list all the Secrets in the cluster.
We give two ways to further utilize ServiceAccount Token with other permissions to take over the cluster:
Method 1: Elevation of Privileges using ServiceAccount Token bound to ClusterAdmin.
Use a Token with the privileges of the ClusterAdmin role that has the authority to control the entire cluster. By authenticating with this Token, you can gain full control of the cluster.
Method 2: Create privileged containers using the ServiceAccount Token with the create pods permission. If you have a ServiceAccount with create pods privileges in your k8s cluster, you can use the Token in the Secrets of this ServiceAccount to create a privileged container that mounts the root directory. This container is excluded from the master node by setting a taint tolerance, which leaks the master's kubeconfig configuration file. In this way, the attacker can take over the entire cluster.
For the above attack chain we have developed exploit code and uploaded it to github: https://github.com/HouqiyuA/k8s-rbac-poc
Mitigation methods are explored:
Carefully evaluate the permissions required for each user or service account to ensure that it is following the principle of least privilege and to avoid over-authorization.
If list secrets is a required permission, consider using more granular RBAC rules. Role Binding can be used to grant list secrets permissions instead of ClusterRole, which restricts permissions to specific namespaces or resources rather than the entire cluster.
Isolate different applications into different namespaces and use namespace-level RBAC rules to restrict access. This reduces the risk of privilege leakage across namespaces
Looking forward to hearing from you and discussing this risk in more detail with us, thank you very much for your time and attention.
Best wishes.
HouqiyuA