The Kubernetes Security Hole Most Teams Already Have
Ask any penetration tester which part of a Kubernetes assessment reliably turns up a finding, and the answer is almost always the same. Not a novel exploit. Not a zero-day. A role binding someone created eighteen months ago to get a deployment working, that nobody ever went back to clean up.
Kubernetes RBAC misconfigurations are not rare. They show up across organizations of every size, in every industry, on almost every assessment. The pattern is consistent enough that security researchers now treat it as a baseline expectation rather than a surprising discovery.
What RBAC Is and Why It Goes Wrong
RBAC stands for Role-Based Access Control, which is Kubernetes’ built-in permission system. It governs what every user, application, and automated process is allowed to do inside the cluster. The design is thorough. The problem is that RBAC is easy to over-grant under deadline pressure and genuinely hard to audit afterward. Permissions accumulate quietly, in the direction of more access, because nothing forces a review the way a certificate expiration or a scheduled patch cycle does.
The Five Mistakes That Show Up Every Time
The most dangerous pattern is binding cluster-admin to a service account for convenience. Cluster-admin is the highest permission level in Kubernetes, functionally equivalent to root on a Linux system. Service accounts are the identities that automated processes run under. When a deployment keeps failing on a permissions error, the fastest fix is often the broadest one. Nobody wants to spend an hour debugging granular access at the end of a sprint. That service account token, once it ends up inside a compromised pod, hands an attacker complete control of the cluster.
Close behind that are wildcard permissions in custom roles. A role with resources: ["*"] and verbs: ["*"] grants that identity the ability to do anything inside the scope it covers. Teams write these to satisfy an error and ship. Nobody audits them. They persist for years.
Overly broad access to Secrets is arguably the most consequential misconfiguration of the group. Secrets in Kubernetes frequently hold cloud provider keys, database passwords, and authentication tokens for external systems. Granting get and list on Secrets is among the most common shortcuts, and it is also the first place an attacker with a foothold in your cluster will look.
Two more patterns round out the list. Role bindings tied to temporary projects almost never get deleted when the project ends, because nothing forces it. And by default, every pod in Kubernetes gets a service account token mounted automatically, even when the pod never needs to talk to the Kubernetes API. An application vulnerability in that pod becomes a cluster permissions problem instantly.
What Closes the Gap
Running kubectl auth can-i --list against actual workload service accounts, not just admin identities, reveals what each process can really do. The results are usually more alarming than anyone expects. Tools like rbac-lookup and kubectl-who-can turn a question like “who can read Secrets in this namespace” from a multi-hour manual review into a single command. Policy enforcement tools like Kyverno or OPA Gatekeeper can reject wildcard roles before they are ever applied to the cluster, removing the most common shortcut before it becomes a standing risk.
Setting automountServiceAccountToken: false by default and granting token access explicitly to workloads that need it is a low-effort change with meaningful security payoff.
The underlying issue is that Kubernetes gives you every tool needed to enforce least privilege precisely. It does not enforce it for you, and it does not alert you when a shortcut from a year ago has quietly become the easiest path to full cluster access. That gap between what the system enables and what it enforces by default is exactly where most of these findings live.
Want to explore how your Kubernetes security posture could be strengthened? Let’s talk.