Kubernetes RBAC pitfalls that grant cluster-admin by accident
Kubernetes RBAC looks simple: roles list verbs on resources, bindings attach roles to subjects. The trouble is that several ordinary-looking grants are equivalent to cluster-admin once you follow what they allow. None of the six patterns below is exotic, and each one is easy to miss in a review that reads roles one at a time.
1. A ClusterRoleBinding where a RoleBinding was meant
A ClusterRole can be bound in two ways. A RoleBinding grants its rules inside one namespace; a ClusterRoleBinding grants them in every namespace and on cluster-scoped resources. Teams often reuse a ClusterRole such as edit and bind it with a ClusterRoleBinding by habit, turning "can edit the payments namespace" into "can edit every namespace".
Audit: list every ClusterRoleBinding and ask, for each, whether the subject genuinely needs cluster-wide scope.
2. Bindings to broad groups
Subjects such as system:authenticated (every authenticated identity) or system:serviceaccounts (every service account) appear in bindings created for convenience during setup. Anything granted to them is granted to every workload and user in the cluster.
Audit: search bindings for group subjects that start with system: and justify each one.
3. Wildcards
verbs: ["*"] or resources: ["*"] in a custom role grants everything that exists today and everything a future CRD adds tomorrow. A wildcard on resources in the core API group includes secrets.
Audit: treat any wildcard outside the built-in cluster-admin role as a finding until proven necessary.
4. "Can create pods" is not a small permission
A subject that can create pods in a namespace can run a pod that mounts the node's filesystem through a hostPath volume, runs privileged, or uses any service account in that namespace — and so inherits that service account's permissions. Unless Pod Security admission (or an equivalent policy) blocks privileged and host-path pods in that namespace, "create pods" is a path to the node and from there, often, to the cluster.
Audit: list who can create pods, deployments, jobs and other workload controllers, and confirm the namespace enforces the restricted or baseline Pod Security standard.
5. Verbs that grant more verbs
Some permissions exist to manage permissions. escalate lets a subject create roles with rules it does not hold; bind lets it bind roles it does not hold; impersonate lets it act as another user, group or service account. create on serviceaccounts/token mints tokens for other identities, and read access to secrets exposes whatever credentials the namespace stores.
Audit: search every role for escalate, bind, impersonate, serviceaccounts/token and secrets, and treat each as admin-adjacent.
6. Aggregated roles that grow on their own
ClusterRoles with an aggregationRule collect the rules of every ClusterRole carrying a matching label. The built-in admin, edit and view roles work this way, so installing an operator whose ClusterRoles carry those labels quietly widens what everyone bound to edit can do.
Audit: after installing an operator or CRD, diff the effective rules of admin, edit and view against what they held before.
A habit that catches most of this
Review RBAC as effective access per subject, not as a list of roles. For each service account and group, ask what it can do across the whole cluster once every binding is counted. The six patterns above are the usual reasons the answer is "more than anyone intended".
Onam's container security checks Kubernetes clusters against posture rules, including RBAC and Pod Security settings, alongside the cloud accounts the clusters run in.