Per-Resource RBAC

Expanded Definition

Per-resource RBAC narrows authorization to a specific object, namespace, or API resource instead of applying broad permissions across an entire cluster. In Kubernetes and adjacent platform tooling, that usually means pairing verbs such as get, list, watch, create, update, patch, or delete with narrowly defined resource targets so access matches the operational task rather than the whole environment.

Definitions vary across vendors and platform teams on how granular this should be, especially when custom resources, aggregated APIs, or controller-owned objects are involved. The practical distinction is that per-resource RBAC aims to reduce lateral movement and accidental overreach without replacing identity, workload authentication, or secrets controls. It is a permission design pattern, not a substitute for lifecycle governance or privileged access management. For a control baseline, NIST SP 800-53 Rev. 5 links privilege management to least privilege and controlled access expectations, which maps well to this model. The most common misapplication is treating namespace-wide access as “resource-level” control, which occurs when a team scopes roles to a namespace but leaves broad verbs and wildcard resources in place.

Where resource-level exposure contributes to secret abuse or API misuse, the same weaknesses often appear in NHI incidents such as ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation, where overly broad access or embedded credentials amplified impact.

Examples and Use Cases

Implementing per-resource RBAC rigorously often introduces policy complexity, requiring organisations to weigh tighter blast-radius control against more role definitions, reviews, and troubleshooting overhead.

• A platform team grants a CI/CD service account permission to update only one deployment object, not every workload in the namespace.
• A controller can read a custom resource definition and reconcile only its owned resources, while being denied access to unrelated workloads.
• An operator gets patch access to a single secret-backed configuration object needed for rotation, without listing or modifying all secrets.
• A cluster admin separates read access for observability tooling from write access for deployment automation, limiting accidental changes.

In practice, this model is most valuable where a single service account needs one narrow action path and nothing else. It is especially relevant for Kubernetes environments with many controllers, custom resources, and automation identities because coarse roles quickly become unmaintainable. NIST’s control language around least privilege and access enforcement supports this pattern as a governance choice, even when the implementation details are platform-specific. Per-resource RBAC also helps teams avoid the “just give cluster-admin temporarily” habit that often becomes permanent through drift and exception handling.

Why It Matters in NHI Security

Per-resource RBAC matters because non-human identities fail differently from humans: they operate at machine speed, repeat mistakes consistently, and often carry credentials that remain valid long after the original task ends. NHIMG notes that 97% of NHIs carry excessive privileges, which makes authorization scope one of the fastest ways to reduce attack surface. For NHI governance, this is not only a Kubernetes concern; it is a pattern for constraining the effective power of service accounts, agents, and automation identities that can otherwise pivot across resources once compromised.

When per-resource RBAC is absent, a single leaked token can expose entire namespaces, configuration layers, or sensitive operational objects. That risk compounds in incident response because responders must untangle whether the breach came from credential theft, policy mis-scoping, or both. Good RBAC design also supports auditability, since each permission should map to a documented operational need. Organisations typically encounter the true cost of weak resource scoping only after a service account is abused to modify objects outside its intended boundary, at which point per-resource RBAC becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why does RBAC break down in multi-tenant products with per-resource permissions?
• What is the difference between org-wide RBAC and resource-scoped authorization?
• How should security teams govern cloud RBAC across subscriptions and resource groups?
• Why does resource-based authorization reduce over-provisioning compared with RBAC?