Kubernetes RBAC
In cloud security, Kubernetes RBAC is the role-based access control model that governs what users and workloads may do inside a cluster. It is where a cluster’s excessive permissions concentrate and the shortest route to cluster administrator, and it is distinct enough from generic RBAC to warrant its own entry, because the model and the findings differ.
How it works
Kubernetes RBAC grants permissions by binding subjects (users, groups and service accounts) to roles that list allowed verbs on resources. Roles are namespaced; ClusterRoles apply cluster-wide. Every pod runs with a service account, and by default that account’s token is mounted inside the pod, so a workload has an identity in the cluster whether or not it needs one. Access is additive: a subject can do the union of everything its bindings allow. The model is the same shape as generic RBAC, but the resources are Kubernetes objects, and some verbs on some objects are effectively administrative, which is where the specific risk lives.
What goes wrong
Certain permissions are more powerful than they look, and this is what an attacker maps first. The ability to create pods, to exec into them, to read secrets, or to modify role bindings can each be escalated to full control of the cluster, because a pod can be scheduled to run privileged, mount the host, or use a more powerful service account. On the clusters we test, the recurring failure is over-broad grants: wildcard verbs, cluster-admin handed out for convenience, or a workload’s service account with permissions far beyond its job. A compromised pod then inherits that identity, and if the identity can read secrets or create privileged pods, the container escape barely matters, because the token alone is the escalation.
Where this shows up in an audit
We enumerate the RBAC graph the way an attacker would: from each reachable identity, what can it do, and does any path lead to cluster admin. We flag the dangerous verbs (create and exec on pods, read on secrets, modify on bindings) wherever they are granted more widely than least privilege requires, and we check whether an admission controller constrains what those permissions can actually schedule. The finding is the escalation path, demonstrated. This is part of how we review cluster permissions.