TL;DR: Kubernetes RBAC can limit access by namespace and role, but manual bindings, weak visibility, and shared service accounts make governance brittle as clusters scale, according to StrongDM. That gap matters because NHI controls must cover service accounts and tokens, not just human users, or privilege drift accumulates faster than teams can review it.
At a glance
What this is: This is StrongDM's explanation of Kubernetes RBAC at scale, and its key finding is that manual role bindings and shared service accounts create governance gaps as clusters grow.
Why it matters: IAM and NHI teams should care because Kubernetes access control often fails at the machine-identity layer first, where service accounts, tokens, and cluster bindings outgrow manual review.
Context
Kubernetes RBAC is the access-control layer that decides which subjects can perform which actions within a cluster or namespace. In this article, the governance problem is not the idea of RBAC itself, but the operational burden created when roles, bindings, service accounts, and tokens multiply faster than teams can track them.
The source argues that Kubernetes RBAC becomes brittle as environments scale because administrators must manually create, update, and revoke bindings while maintaining visibility across clusters. For identity programmes, that is an NHI governance problem, not just a platform administration problem, because service accounts and stored tokens behave like machine identities that need lifecycle control.
Key questions
Q: What breaks when Kubernetes security depends on RBAC alone?
A: RBAC can grant or deny actions, but it does not explain whether a connection is expected or whether a workload is moving laterally in a suspicious way. In Kubernetes, that creates a control gap because permissions may still look valid after the original task is complete. Teams need traffic context and containment controls, not authorization records alone.
Q: Why do Kubernetes service accounts create security and operational risk at scale?
A: Kubernetes service accounts become risky when teams rely on long-lived keys, manual rotation, and cluster-local trust. That model creates exposure to key leakage, inventory drift, and weak server authentication, especially across multiple clusters or regions. It also pushes security burden onto developers, who may not have the right controls for credential lifecycle management.
Q: How should teams govern Kubernetes RBAC for non-human identities?
A: Teams should govern Kubernetes RBAC as a lifecycle problem for non-human identities, not just a permissions problem. That means inventorying service accounts, reviewing bindings, revoking unused access, and tracking token-backed credentials as governed assets. The key is to make ownership and offboarding explicit.
Q: Should organisations centralise Kubernetes access review across clusters?
A: Yes, because cluster-by-cluster review misses duplicate grants, orphaned roles, and inconsistent bindings that appear only when you compare environments. Centralised review gives teams a reliable view of roles, role bindings, and service accounts before access drift becomes normal. Without that view, certification is mostly paperwork.
Technical breakdown
How Kubernetes Roles and bindings translate policy into access
Kubernetes RBAC uses Roles and ClusterRoles to define allowed verbs such as get, list, create, and delete, then attaches those permissions to subjects through RoleBindings or ClusterRoleBindings. A Role is namespaced, while a ClusterRole can span the whole cluster. That distinction matters because scope is encoded in the binding, not just in the subject. When teams rely on broad defaults like cluster-admin, they collapse fine-grained policy into broad standing privilege. In practice, the access model is only as precise as the bindings and the review process around them.
Practical implication: review where cluster-wide bindings exist and reduce them to the smallest namespace-scoped roles possible.
Why service accounts become the hidden governance gap
The article highlights that Kubernetes pods often share the default service account unless teams deliberately change that behaviour. Service accounts are NHI subjects: they authenticate pods to the API server and can inherit permissions through role bindings. When multiple workloads share the same account, accountability and blast-radius control both weaken, because one credential can represent many workloads. Tokens stored as Secrets also extend that risk if they are reused or left in place after the workload changes. This is where governance shifts from human access administration to machine identity lifecycle management.
Practical implication: assign workload-specific service accounts and revoke any default or shared account that persists across unrelated applications.
Why manual role management breaks at cluster scale
The article's central operational issue is not that RBAC lacks granularity, but that the surrounding administration is manual. New namespaces require new bindings, role changes require recreation, and revocation depends on deleting configuration objects correctly. That creates duplicate grants, stale permissions, and orphaned roles that no one uses but nobody removes. Visibility also fragments across clusters, so teams cannot easily answer who has what access or whether a role is still needed. At scale, the real failure mode is governance drift, not policy design.
Practical implication: centralize RBAC inventory and change tracking so revocation, duplication checks, and unused-role cleanup are not left to ad hoc review.
Threat narrative
Attacker objective: The attacker objective is to move from one over-privileged Kubernetes identity to wider cluster control through shared bindings and reusable tokens.
- Entry occurs when a Kubernetes subject receives a broad or shared role binding that grants more access than the workload or user needs.
- Credential access occurs when service account tokens or other Secrets-backed credentials are reused across pods or workloads.
- Escalation and lateral movement follow when a shared binding lets one compromised workload act with the permissions of several others inside the cluster.
- Impact is broader cluster exposure, because weak binding hygiene and shared identities expand the blast radius of a single mis-scoped account.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
NHI governance is the real scaling constraint in Kubernetes RBAC. The article is not really about whether RBAC exists, but about whether teams can govern service accounts, tokens, and bindings once the environment becomes operationally dense. Namespace scoping helps, but it does not solve ownership, revocation, or inventory quality. Practitioners should treat Kubernetes RBAC as an NHI lifecycle problem, not only an authorisation pattern.
Shared service accounts are an identity-design flaw, not a convenience. When multiple workloads authenticate through the same account, access review loses precision and incident containment loses scope. The cluster still looks governed on paper, but the effective identity boundary has already been flattened. That means the programme assumption being broken is simple: one workload, one accountable identity, one revocation path.
Manual RBAC administration creates privilege drift faster than teams can certify it. Recreating bindings, tracking subject lists, and reconciling orphaned roles all consume the same control capacity that access reviews depend on. The result is a control gap where drift accumulates between review cycles. Practitioners should read this as a governance capacity issue: if the inventory cannot keep up, the authorisation model cannot be trusted.
Identity blast radius becomes the decisive metric in clustered environments. Namespace roles, cluster-wide bindings, and service account reuse each change how far one credential can travel if abused. The relevant framework lens is OWASP-NHI, especially improper offboarding, overprivileged NHI, and long-lived secrets. The practitioner conclusion is to measure how much access any single Kubernetes identity can accumulate before revocation can realistically occur.
Kubernetes RBAC scale forces identity teams and platform teams into the same operating model. The article shows that access control, workload identity, and auditability cannot be separated once clusters are large enough to have many namespaces and teams. That convergence is where NHIs become enterprise governance objects rather than platform configuration details. Practitioners should align Kubernetes RBAC with a broader identity governance process instead of treating it as cluster-only administration.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Identity blast radius is the right mental model for Kubernetes RBAC. The practical question is no longer whether a role exists, but how far a single binding can travel across namespaces, workloads, and cluster operations before revocation catches up. That framing is more useful than generic least-privilege language because it exposes where a shared service account becomes an enterprise-wide problem.
Kubernetes teams should expect RBAC governance to converge with NHI lifecycle management as clusters expand. Roles, bindings, service accounts, and tokens are all subject to the same control logic: inventory, scope, ownership, and removal. If those controls are handled separately, drift will appear faster than platform teams can clean it up.
For practitioners
- Tighten namespace-scoped bindings Replace broad cluster-admin style assignments with namespace-scoped Roles and ClusterRoles only where the workload or team truly needs them.
- Separate workload service accounts Stop relying on the default service account for unrelated pods and assign application-specific serviceAccountName values instead.
- Inventory role bindings centrally Maintain a single view of Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, service accounts, and token locations across clusters.
- Revoke unused and duplicated grants Remove stale bindings, duplicate role grants, and roles that no longer map to any live subject after namespace or team changes.
- Track token-backed access as NHI lifecycle Treat service account tokens stored as Secrets as governed machine credentials that require ownership, renewal, and revocation handling.
Key takeaways
- Kubernetes RBAC can look precise on paper while still failing in practice when bindings, service accounts, and tokens are managed manually.
- The main risk is governance drift: shared identities, orphaned roles, and duplicated grants expand access faster than teams can review it.
- A usable control model requires workload-specific service accounts, centralized binding visibility, and disciplined revocation of stale machine identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unused bindings and shared service accounts persist after team or namespace changes. |
| NHI-05 — Overprivileged NHI | Cluster-admin style bindings and broad roles are the core scale risk in this article. | |
| NHI-07 — Long-Lived Secrets | Service account tokens stored as Secrets extend the lifetime of machine access. | |
| Recommendation — Remove stale Kubernetes identities and bindings as part of offboarding and workload retirement. Reduce Kubernetes subjects to the minimum verbs and namespaces they actually require. Shorten the usable life of Kubernetes tokens and rotate them under a governed lifecycle. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and credential handling for service accounts is central to Kubernetes RBAC governance. |
| Recommendation — Apply authenticator management controls to Kubernetes service account tokens and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on access permissions, bindings, and entitlement review across clusters. |
| Recommendation — Govern Kubernetes entitlements centrally and review cluster permissions on a recurring basis. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Kubernetes RBAC is fundamentally a cloud IAM governance problem at the cluster layer. |
| Recommendation — Align cluster role administration with cloud IAM governance and centralized review. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Shared service accounts and tokens can support credential abuse and cluster spread. |
| Recommendation — Map shared token exposure to credential-access and lateral-movement detections in the cluster. | ||
Key terms
- Kubernetes RoleBinding: A RoleBinding attaches permissions from a Role to a user, group, or service account within a namespace. It is the object that turns policy into effective access. In NHI terms, it is a lifecycle-managed authorization relationship and should be reviewed like any other identity entitlement.
- ClusterRole: A ClusterRole defines permissions that can apply across namespaces or to cluster-scoped resources. It creates wider blast radius than a namespace Role, so it needs tighter approval and review. For NHI governance, cluster-wide access should be rare, explicit, and continuously justified.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- Privilege Drift: Privilege drift is the gradual gap between the permissions an identity was meant to have and the permissions it actually retains. In AI agent environments, drift grows quickly because roles are reused, tasks change, and lifecycle reviews often lag behind deployment velocity.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 15, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org