A mid-sized fintech we spoke with last year had 214 ClusterRoleBindings across a single production cluster. Nobody could tell us, without running a script, which ones were still needed. Three were bound to cluster-admin. Two belonged to service accounts for engineers who'd left the company eight months earlier. One was a leftover from a Helm chart install that had since been uninstalled — the binding survived, the workload didn't.
This is not an unusual cluster. It's a typical one. Kubernetes RBAC (Role-Based Access Control) is designed to be granular, which is exactly why it sprawls: every controller, CI pipeline, operator, and developer namespace tends to accumulate its own Roles and RoleBindings, and almost nothing in the default tooling forces anyone to clean them up. Unlike IAM in AWS or Azure, which gets swept into quarterly access reviews almost by habit, Kubernetes RBAC usually isn't part of any audit cycle at all — even at organizations with mature cloud security programs. Here's why that gap exists, and what closing it actually requires.
What Counts as "RBAC Sprawl," Exactly?
RBAC sprawl is the accumulation of Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings that grant more access than any current workload or user actually needs — and that nobody has reviewed since they were created. It shows up in a few predictable patterns: service accounts bound to cluster-admin "just to get something working" during a deploy, then never scoped down; wildcard verbs ("*") on wildcard resources, which the CIS Kubernetes Benchmark (control 5.1.3) flags explicitly as a finding; default service accounts in a namespace picking up permissions because a binding targeted the whole namespace instead of a specific identity; and orphaned bindings pointing at ServiceAccounts, users, or groups that no longer exist. A cluster we reviewed with roughly 60 namespaces had just under 900 role bindings in total — and fewer than 40% of them mapped to a workload that had made an API call in the previous 90 days.
Why Doesn't Anyone Audit Kubernetes RBAC?
Nobody audits it because kubectl get rolebindings -A gives you a wall of YAML, not a risk answer. RBAC objects don't compose visually — a ClusterRole grants permissions, a RoleBinding or ClusterRoleBinding attaches it to a subject, and the effective access for a given ServiceAccount is the union of every binding that touches it, direct or aggregated. There's no built-in kubectl who-can-do-what command; the closest official tool, kubectl auth can-i --list, only tells you about one subject at a time, and you have to already know which subject to ask about. Compare that to AWS, where IAM Access Analyzer, Access Advisor, and CloudTrail-based last-used data ship as native console features. Kubernetes has no equivalent baked in, so RBAC review becomes a scripting exercise that only happens when someone has a reason to go looking — usually after an incident, not before one.
How Fast Does RBAC Actually Sprawl in Practice?
Faster than headcount, because bindings are created by automation, not just people. Every Helm chart, Argo CD Application, Crossplane provider, and CI/CD pipeline that touches the cluster tends to install its own ServiceAccount and RoleBinding as part of its manifest — and almost none of them are removed automatically when the chart is uninstalled or the pipeline is decommissioned, because Kubernetes garbage collection only cleans up objects with an owner reference, and most RBAC objects installed via kubectl apply or Terraform don't have one. In one review of a cluster that had been running for 14 months, we found the RBAC object count had grown by roughly 6x while the number of active workloads had grown by less than 2x. The gap was almost entirely dead bindings from decommissioned tooling and old CI jobs.
What's the Actual Blast Radius If This Goes Unaudited?
The blast radius is usually a lateral move from a low-value pod to full cluster control, not a direct external breach. The canonical example is the December 2018 Tesla incident, where an unauthenticated, internet-exposed Kubernetes dashboard let attackers pivot into the cluster and run cryptomining workloads — the entry point wasn't RBAC directly, but the pattern it illustrates is the one RBAC sprawl enables everywhere: once any pod is compromised (via a vulnerable dependency, an exposed dashboard, or a supply-chain injection in a CI job), the attacker's next move is to check what that pod's ServiceAccount token can do. If that ServiceAccount is bound — directly or via an over-broad namespace-level RoleBinding — to secrets: get/list, pods/exec, or cluster-admin, a single compromised container becomes a path to reading every Secret in the namespace or cluster, minting new tokens, and deploying arbitrary workloads. Red Hat's 2023 State of Kubernetes Security report found that a majority of surveyed organizations had experienced at least one security incident in their Kubernetes environment in the prior 12 months, with misconfigurations — RBAC among the most common — cited as a leading root cause. Unaudited RBAC is what turns a contained container-level compromise into a cluster-wide one.
What Does a Real RBAC Audit Actually Check?
A real audit checks three things: what's granted, what's used, and what's reachable — not just what's configured. That means enumerating every ClusterRole and Role for wildcard verbs or resources and dangerous verb combinations (create on pods, bind on roles, escalate on clusterroles — all of which allow privilege escalation per Kubernetes' own documented escalation paths); resolving every RoleBinding and ClusterRoleBinding to its effective subject and confirming that subject (user, group, or ServiceAccount) still exists and is still attached to a live workload; cross-referencing binding grants against actual API server audit logs to flag permissions that have gone unused for a defined window (30, 60, 90 days); and specifically checking for cluster-admin bindings outside a short allowlist of platform-team identities, since CIS Benchmark 5.1.1 treats any non-essential cluster-admin binding as a finding on its own. Manually, this takes a skilled engineer with kubectl, jq, and tools like rbac-tool or kubectl-who-can the better part of a day per cluster — which is exactly why, at multi-cluster scale, it doesn't happen on any recurring cadence without dedicated tooling.
How Safeguard Helps
Safeguard treats Kubernetes RBAC as a first-class part of the software supply chain surface, not a separate compliance checkbox. Instead of asking your team to script through kubectl get rolebindings -A output across every cluster, Safeguard continuously inventories every Role, ClusterRole, RoleBinding, and ClusterRoleBinding across your fleet, resolves each one to its effective subject, and correlates that against real workload activity — so you see not just what's granted, but what's actually being used.
Concretely, Safeguard flags cluster-admin bindings outside your approved allowlist, surfaces wildcard verb/resource grants and known privilege-escalation combinations (create on pods, bind/escalate on roles) automatically, identifies orphaned bindings left behind by decommissioned Helm releases or CI pipelines, and maps RBAC grants alongside the container images and dependencies those ServiceAccounts are attached to — so a compromised base image and an over-permissioned ServiceAccount show up as one connected risk, not two disconnected findings in two different tools. Every finding maps to the relevant CIS Kubernetes Benchmark control, so the audit trail your security team needs for SOC 2 or internal review is generated as a byproduct of continuous monitoring, not a quarterly fire drill.
If your last Kubernetes RBAC audit was "whenever we set the cluster up," that's the gap Safeguard is built to close — turning RBAC sprawl from an invisible, growing liability into a tracked, continuously reviewed part of your security posture.