Ask any penetration tester which part of a Kubernetes assessment reliably produces a finding, and RBAC comes up almost every time. Not because Kubernetes’ permission model is poorly designed — it’s genuinely thorough — but because it’s flexible enough that teams misconfigure it in the same handful of ways, over and over, across completely unrelated organizations.

Cryptojacking campaigns targeting exposed Docker and Kubernetes infrastructure have been a recurring theme in 2026 threat reporting, and container escape and Docker-in-Docker risks keep showing up in cloud-native security roundups. Almost none of these incidents involve a novel Kubernetes vulnerability. Most of them involve a role binding someone created eighteen months ago to “just get something working,” that no one ever revisited.

The Misconfigurations That Show Up Constantly

• cluster-admin bound to a service account for convenience. Somewhere in most clusters is a service account bound to cluster-admin because a deployment kept failing on a permissions error and the fastest fix was the broadest one. That service account’s token, if it ends up in a compromised pod, is functionally the keys to the entire cluster.
• Wildcard verbs and resources in custom roles. A Role or ClusterRole with resources: ["*"] and verbs: ["*"] technically satisfies whatever access problem prompted it, and it also grants far more than intended — often including the ability to read every Secret in the namespace or cluster.
• Secrets read access granted more broadly than the workload needs. get and list on Secrets are among the most consequential permissions in the entire RBAC model, because Secrets frequently contain credentials for other systems entirely — cloud provider keys, database passwords, other clusters’ service account tokens. They’re also among the most casually over-granted.
• Bindings that outlive the project they were created for. RoleBindings and ClusterRoleBindings don’t expire. A binding created for a three-week migration project frequently outlives the project by years, because nothing forces a review the way a certificate expiration or a patch cycle does.
• Default service account tokens mounted into pods that never use them. Unless explicitly disabled, every pod gets a service account token mounted automatically. If that pod is compromised through an application vulnerability, the attacker inherits whatever that service account can do — which, per the points above, is often more than anyone intended.

Why These Keep Happening

RBAC misconfigurations aren’t usually a knowledge gap. Most platform teams know least privilege is the goal. The problem is that RBAC is easy to over-grant under time pressure and hard to audit after the fact — there’s no single kubectl command that answers “what can everything in this cluster actually do, in aggregate,” and permissions accumulate the same way file-share access does: quietly, and in the direction of more.

What Closes the Gap

• Run kubectl auth can-i --list against real workload identities, not just admin accounts. This surfaces what a specific service account can actually do, which is usually more revealing — and more alarming — than reviewing the RoleBindings in isolation.
• Use an RBAC visualization tool before every access review, not just during an incident. Tools like rbac-lookup or kubectl-who-can turn “who can read Secrets in this namespace” from a multi-hour manual audit into a single query. If nobody runs that query quarterly, the sprawl compounds silently.
• Disable automatic service account token mounting by default. Set automountServiceAccountToken: false at the pod or ServiceAccount level unless a workload specifically needs the Kubernetes API, and grant it explicitly when it does.
• Ban wildcard verbs and resources in custom Roles via policy, not convention. Admission controllers like Kyverno or OPA Gatekeeper can reject a Role or ClusterRole that uses resources: ["*"] or verbs: ["*"] before it’s ever applied, closing off the most common shortcut before it becomes a standing risk.
• Put an expiration discipline on bindings tied to temporary projects. If a RoleBinding exists to support a migration or a proof of concept, put a calendar reminder or a labeled review date on it. Nothing else will force the cleanup once the project ships.

The Bottom Line

Kubernetes RBAC gives you every tool you need to enforce least privilege precisely. It doesn’t enforce it for you, and it doesn’t tell you when a shortcut from eighteen months ago has quietly become the easiest path to cluster-admin in your environment. That gap between capability and default state is exactly where most of these findings live — and exactly why it keeps showing up in assessment after assessment.