Skip to content


General Resources

Link Description A site dedicated to good practices and tooling around Kubernetes RBAC
Kubernetes Authorization Introductory article discussing RBAC and how you can use it to secure your cluster
Simplify Kubernetes Resource Access Control using RBAC Impersonation Kubernetes RBAC includes a special impersonate verb, that can be used to allow Subjects to acquire other User or Group identities
Authentication between microservices using Kubernetes identities Service Account Token Volume projection allows you to associate non-global, time-bound and audience bound service tokens to your Kubernetes workloads
Role Based Access Control Good Practices Principles and practices for good RBAC design for cluster operators

Privilege Escalation

Threat Description
Horizontal privilege escalation via cluster nodes (multi-tenancy)
  • Configure a role allowed to create and access pods in its own namespace only
  • Since this role can create arbitrary pods, the users bound to that role can access other namespaces by creating a privileged pod and accessing the host through that pod
  • Once on the host, other namespaces' pods can be accessed and compromised (e.g. by reading out service account tokens from victim pods)
Vertical privilege escalation via create pod privilege
  • Users with the permission to create pods can escalate privileges
  • This is because any service account can be provided in the pod specification
  • So, the create pod privilege implicitly allows to impersonate any service account within the same namespace
Privilege escalation via impersonate permissions
  • kubectl –as=system:admin get secrets
Privilege escalation via bind or escalate permissions
  • For the bind verb on (cluster)rolebindings or the escalate verb on (cluster)roles
  • Having modify and escalate permission on role resources allows users to add arbitrary permissions to their roles
  • Writeups:
    • Getting into a bind with Kubernetes: The bind verb is a useful piece of Kubernetes RBAC configuration, but it's also one of the lesser known. As it can enable privilege escalation, it's an important thing to check for when creating or auditing roles
Privilege escalation via list
  • With list you can actually access resources (e.g., secrets)
  • Writeups:
    • When LIST is a Lie in Kubernetes: For the Secrets resource, the "list" verb is a lie. When you "list" a secret, it goes out to the Kubernetes API, pulls down all the secrets including individual secret values themselves. This is a known and documented issue but I see lots of environments that continue to rely on LIST to prevent access to secrets, compared to the GET verb