Kubernetes RBAC Scoping

RBAC misconfigurations grant too much. The scoping pattern that produces tight, reviewable RBAC.

Namespace-scoped

Kubernetes RBAC is the system that controls who can do what in the cluster. Done well, RBAC produces a least-privilege environment where every workload and user has exactly the permissions they need. Done poorly, RBAC produces over-privileged grants that defeat the purpose. The discipline is in scoping: choosing the smallest permission grant that allows the workload to do its job.

What namespace-scoping looks like:

• Default: Roles, not ClusterRoles.: Roles are namespace-scoped; ClusterRoles span the entire cluster. The default choice should be Role unless there is a specific reason to span namespaces. The narrower scope limits blast radius.
• Bind in the namespace.: RoleBindings bind a Role to a ServiceAccount or user within a single namespace. The binding scope matches the Role scope. The pattern is: workload in namespace X gets a Role in namespace X via a RoleBinding in namespace X.
• ClusterRoles for cluster-wide concerns only.: Some resources (Nodes, PersistentVolumes, CustomResourceDefinitions) are cluster-scoped by nature. Workloads that legitimately need cluster-wide access (cert-manager, ingress controllers, monitoring agents) get ClusterRoles. Most workloads do not.
• Cross-namespace patterns are explicit.: When a workload needs access across namespaces, the access is explicit: multiple RoleBindings (one per namespace) or a ClusterRole with a documented justification. The default is the narrow case; the cross-namespace exception is documented.
• ServiceAccounts per workload.: Each workload has its own ServiceAccount. Permissions are bound to the ServiceAccount; permissions are not shared across workloads. The discipline limits accidental privilege escalation.

Namespace scoping is the foundation. Without it, every permission grant has cluster-wide reach.

Specific verbs

The verbs in an RBAC rule determine what actions are allowed. Wildcard verbs (*) grant every action; specific verbs grant only the actions actually needed. The discipline is the same as for AWS IAM: enumerate the necessary actions; refuse the wildcard.

• Avoid asterisk verbs.: Rules with verbs: ['*'] grant every possible verb. The wildcard is convenient but rarely accurate; most workloads need only specific verbs. Avoiding the wildcard forces specificity.
• List exactly: get, list, watch for read.: Workloads that only read resources need only get, list, and watch. The three verbs cover most read patterns. Anything beyond suggests the workload also needs write access; the audit catches over-grants.
• List exactly: create, update, delete for write.: Workloads that write need create, update, and delete (or a subset). The specific verbs document what the workload does. patch is sometimes also needed; include it when the workload needs partial updates.
• Audit grep: any rules with wildcards is suspect.: A grep across the cluster for rules with verbs: ['*'] or resources: ['*'] surfaces over-permissive grants. Each finding is investigated; most can be tightened to specific verbs and resources.
• Resource specificity.: Resources can also be specific. Rules that grant access to specific named resources (resourceNames) are tighter than rules that grant access to all resources of a type. The narrower scope reduces blast radius.

Specific verbs are where the principle of least privilege actually lives. Wildcards undermine the principle.

Quarterly review

RBAC drifts over time. New workloads add permissions; old workloads decommission but their bindings remain; team members change roles but their access stays the same. Without periodic review, the cluster accumulates permission cruft.

• Each role: who is bound?: The review enumerates each Role and ClusterRole and lists the principals bound to it. The list shows who has what access; comparison against the current organization shows what is appropriate.
• Are they still appropriate?: For each binding, the team asks whether the principal still needs the access. People who left the team; service accounts for workloads that no longer exist; integrations that are no longer used. Each is a candidate for removal.
• Stale bindings are common.: Almost every quarterly review finds stale bindings. The cleanup is routine; the discipline is what keeps the cluster healthy. Without the cleanup, the cluster's permission surface expands continuously.
• Clean up.: Stale bindings are removed. Unused Roles are deleted. The cluster's permission inventory matches reality after the cleanup. The next review starts from a clean baseline.
• Document the changes.: The review produces a report: what was reviewed, what was changed, what was kept and why. Audit conversations reference the report; future reviews build on it.

Cluster RBAC scoping is one of those security disciplines that requires sustained attention. Nova AI Ops integrates with Kubernetes RBAC inventory, surfaces over-permissive rules and stale bindings, and produces the per-cluster review report that the security team uses to drive cleanup.