Last reviewed: November 2, 2026 (Asia/Shanghai).
Direct answer
Review Kubernetes RBAC in a coding-agent patch as an authorization change, not as YAML cleanup. For every Role, ClusterRole, and binding, identify the subject, API group, resource, verbs, resource names, namespace, and workload that uses the identity. Approve only the smallest rule set that satisfies the named operation. Keep service-account binding separate from permission definition, and prove a permitted action and a nearby denied action with a disposable cluster or server-side dry run.
Kubernetes documents RBAC as an additive model: permissions are not deny rules. A broad ClusterRole or a binding in the wrong namespace therefore expands the effective authority even when the manifest looks tidy. The Kubernetes RBAC reference also distinguishes Role and RoleBinding from cluster-scoped objects, and explains that a RoleBinding can reference a ClusterRole while granting its rules only in the binding’s namespace.
The review should trace the runtime service account from the workload’s serviceAccountName to its bindings and then to the API requests made by the container. A role that permits get on pods does not automatically permit logs, secrets, custom resources, or subresources. The Kubernetes authorization overview
describes the authorization decision at the API server; the RBAC reference
defines the objects and rule fields; and the OWASP Authorization Cheat Sheet
supports least privilege, deny-by-default, and authorization tests as review principles.
Who this is for
Use this guide when an agent edits Helm values, Kustomize overlays, Kubernetes manifests, operators, admission helpers, or deployment charts that change a workload identity or its permissions. It applies to application service accounts and automation identities. It does not replace a cluster administrator’s organization-wide policy, admission controls, or provider-specific identity review.
Start with a named operation such as reading ConfigMaps in one namespace, listing a custom resource, or updating one deployment. Do not begin with a role name like app-reader; names hide the actual authority. Record the namespace and API group, and decide whether the operation needs a collection verb (list or watch) or only a named object (get on a resourceNames entry).
Key takeaways
- Bind the workload’s actual service account, namespace, and deployment to the reviewed rules.
- Prefer a namespaced
RoleandRoleBindingwhen the operation is namespaced; use cluster-scoped objects only for a documented cluster-wide need. - List exact API groups, resources, subresources, verbs, and resource names. Avoid
*unless an explicit exception is approved. - Remember that permissions are additive and that a
RoleBindingto aClusterRoleremains namespace-scoped. - Check every overlay and generated manifest for effective bindings, including default service accounts and controllers.
- Prove a required action and a forbidden neighboring action with an authorized test identity.
- Keep credentials and token values out of agent prompts, manifests, logs, and review evidence.
Sources checked
Three primary public references were fetched at their canonical URLs on November 1, 2026 UTC:
- Kubernetes RBAC authorization
documents additive permissions,
Role,ClusterRole,RoleBinding,ClusterRoleBinding, rule fields, subresources,resourceNames, and the namespace scope of bindings. - Kubernetes authorization overview documents API-server authorization modes and the subject, verb, resource, namespace, and API-group dimensions used in an authorization decision.
- OWASP Authorization Cheat Sheet supports least privilege, deny-by-default, centralized policy, and tests that verify both allowed and denied behavior.
These maintained technical references support an evergreen patch-review task. The examples and acceptance matrix are review recommendations; no cluster deployment, authorization decision, or production test result is claimed.
Contract details to verify
Write the caller-to-rule map first
Before reading a diff, write a table for each workload identity:
| Decision | Required value |
|---|---|
| Workload | Deployment, Job, or controller and its namespace |
| Subject | Exact ServiceAccount name and namespace |
| Operation | Concrete API request, including subresource |
| Scope | Namespace or cluster; exact resource names where practical |
| Allowed rules | Smallest verbs and resources that satisfy the operation |
| Denial | Stable failure and no secret, write, or queued side effect |
| Owner | Team that approves future permission changes |
Trace serviceAccountName in the rendered workload, not only the base YAML. If it is omitted, Kubernetes may use the namespace’s default service account; treat that implicit subject as a review finding when the patch assumes a dedicated identity. Follow Helm values, Kustomize patches, generated files, and namespace substitutions until the effective manifest is known.
Keep scope and subjects explicit
Use a namespaced Role for namespaced resources whenever possible. A RoleBinding can grant a ClusterRole’s rules in one namespace, which can be useful for sharing a reviewed rule set without granting cluster-wide access. A ClusterRoleBinding grants the referenced rules across the cluster and needs a stated cluster-wide requirement.
Check binding subjects exactly. A service account is identified by both name and namespace; a typo or an unintended namespace can leave the intended workload without access while granting another subject. Review user and group subjects as configuration-sensitive identities, especially when a chart exposes them as values.
Keep permission definition and subject assignment in separate review sections. An agent can add a harmless rule but bind it to a powerful controller, or preserve a narrow rule while broadening the binding. Both changes alter effective authority.
Make each rule narrow
Specify the API group and resource rather than using wildcards. Include subresources such as pods/log, deployments/scale, or nodes/proxy deliberately. Separate read verbs from write verbs, and ask whether list or watch is required at all. Kubernetes notes that resourceNames can restrict named resources for most verbs, but a request using list or watch with a field selector may be needed for that restriction to apply; verify the client behavior before relying on it.
Do not treat a role named view or reader as evidence of least privilege. Expand referenced ClusterRoles and aggregate labels in the effective cluster policy. Aggregated roles can change when another role is added, so include the aggregation policy in change review when the identity depends on it.
Happy-path operator workflow
- Freeze the agent revision. Render every affected overlay or chart with the production-like namespace and service-account values.
- Inventory operations. List each workload identity and the API operations it performs. Use application code, controller configuration, and client logs from a disposable environment to identify verbs and subresources.
- Expand effective rules. Follow all bindings and referenced roles. Record namespace scope, wildcard fields, aggregation labels, and resource names.
- Narrow the patch. Replace broad rules with explicit resources and verbs. Create a dedicated service account when the workload currently uses
default. - Inspect safely. Run a server-side dry run or policy inspection in a disposable cluster. Keep output bounded and sanitized.
- Exercise both decisions. Make one required request and one neighboring forbidden request as the exact service account. Inspect returned objects and state changes.
- Attach evidence. Keep the rendered manifest, policy table, test identities, and revision together, then recheck after any agent follow-up.
A useful read-only inspection can include kubectl auth can-i for the exact subject and namespace, but the command is an authorization query, not proof that the application invokes only that request. Pair it with an integration fixture that makes the real client call and verifies the response and state.
For a broader object-level authorization comparison, read Prevent IDOR in Coding-Agent API Patches . For deployment identity changes, compare Pin Container Images by Digest When Coding Agents Edit Deployments .
Error-path operator workflow
Block the patch when a workload can read another namespace, list secrets, write a resource it only needs to read, or use a cluster-wide binding without a documented requirement. Preserve the smallest rendered manifest and an authorized test identity that demonstrates the excess permission.
If a required action is denied, inspect the rendered subject, namespace, API group, subresource, and binding before adding a wildcard. The usual repair is a missing or mis-scoped rule, not a global role. If the policy engine or cluster is unavailable, leave the existing policy in place and mark the change unresolved.
When an agent proposes ClusterRoleBinding as a shortcut, ask which namespace and operation require it. A successful dry run under an administrator identity does not establish that the workload identity is correctly bound. Never paste service-account tokens or full Secret objects into agent evidence.
Prove effective permissions with a regression matrix
Use a disposable namespace with synthetic ConfigMaps, Pods, and a non-sensitive custom resource. Create an application service account and a separate test account. Run requests through the same client path the workload uses, then inspect both the response and any state change.
| Request | Required evidence |
|---|---|
| Read the named ConfigMap in the application namespace | Allowed; only approved fields are returned |
| Read a ConfigMap in another namespace | Denied; no data disclosed |
| List or watch a collection when only one named object is required | Denied unless the operation contract explicitly needs it |
Read pods/log when pod metadata is allowed | Matches the declared subresource policy |
| Create, update, or delete a resource under a read-only role | Denied; object and audit side effects absent |
| Read a Secret or list Secrets | Denied unless the named operation explicitly requires it |
| Use the same service-account name in a different namespace | No cross-namespace authority |
| Invoke a required custom-resource operation | Allowed only for the declared API group, resource, verb, and scope |
| Submit the request through a chart overlay or generated manifest | Effective permissions match the reviewed source |
| Remove or revoke the binding, then retry | Denial follows the documented rollout and cache behavior |
kubectl auth can-i results should be recorded with subject, namespace, verb, API group, resource, and timestamp, without tokens or object contents. For state-changing tests, assert that the object and downstream job or event remain unchanged after denial. These are acceptance criteria for a reader’s implementation; this article reports no executed cluster result.
Failure modes
A ClusterRole name is mistaken for cluster-wide access. Its scope depends on the binding. Expand the binding and namespace before deciding what the workload can do.
A namespaced role is bound to the wrong service account. Check both subject name and namespace in rendered output.
A wildcard fixes a missing subresource. Add the exact subresource and verb after confirming the client request.
The agent checks permissions as an administrator. Query and test as the workload identity; admin success proves little about the binding.
The default service account gains new rules. Create a dedicated identity and make serviceAccountName explicit.
A test checks only HTTP status. Inspect returned data, object state, audit events, and queued effects. A denied status after a write is still a failed boundary.
An aggregated role changes indirectly. Include aggregation labels and source roles in the review; effective permissions can expand through another manifest.
Tokens or Secrets enter evidence. Use synthetic values and record policy decisions, never credential material.
FAQ
Is RBAC deny-by-default?
Kubernetes RBAC rules are additive. A request is allowed when an authorizer grants it; there is no RBAC rule that subtracts a permission granted elsewhere. Review all bindings and authorizers that apply to the cluster.
Does a RoleBinding to a ClusterRole grant cluster-wide access?
No. The binding is namespaced, so the referenced role’s permissions apply in that namespace for that subject. A ClusterRoleBinding has cluster-wide scope and requires a separate justification.
Do service-account names identify one global identity?
No. Service accounts are namespaced. Bind the exact name and namespace, and verify the workload uses that subject.
Is kubectl auth can-i enough?
It is a useful policy query, but it does not prove the application makes only that request or that overlays render as expected. Combine it with the workload’s real client path and state assertions.
Can an agent apply RBAC changes directly?
Use a reviewed, least-privileged workflow. The agent can render and propose a patch; a human or trusted deployment control should approve permission changes and apply them under a separately audited identity.
Reader next step
Choose one agent-written RBAC change. Render the final manifest, write the caller-to-rule table, and run one permitted and one forbidden request as the workload’s exact service account. Approve the patch only when namespace scope, subject binding, API group, resource, subresource, and verb match the operation and denied requests leave no data or side effects.