Limit use of the Bind, Impersonate and Escalate permissions in the Kubernetes cluster (RBAC)
Cluster roles and roles with the impersonate, bind or escalate permissions should not be granted unless strictly required. Each of these permissions allow a particular subject to escalate their privileges beyond those explicitly granted by cluster administrators. The impersonate privilege allows a subject to impersonate other users gaining their rights to the cluster. The bind privilege allows the subject to add a binding to a cluster role or role which escalates their effective permissions in the cluster. The escalate privilege allows a subject to modify cluster roles to which they are bound, increasing their rights to that level. Each of these permissions has the potential to allow for privilege escalation to cluster-admin level.
Risk Level: High
Cloud Entity: Kubernetes Role Binding
CloudGuard Rule ID: D9.K8S.IAM.48
Covered by Spectral: No
Category: Security, Identity, & Compliance
GSL LOGIC
KubernetesRoleBinding should not have role.rules contain [ verbs contain [ 'bind' ] or verbs contain ['impersonate'] or verbs contain ['escalate']]
REMEDIATION
Where possible, remove the impersonate, bind and escalate rights from subjects.
References
- https://raesene.github.io/blog/2020/12/12/Escalating_Away/
- https://raesene.github.io/blog/2021/01/16/Getting-Into-A-Bind-with-Kubernetes/
Kubernetes Role Binding
A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.
Compliance Frameworks
- CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.2.0
- CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.3.0
- CIS Kubernetes Benchmark v1.20
- CIS Kubernetes Benchmark v1.23
- CIS Kubernetes Benchmark v1.24
Updated about 1 year ago