iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To find what Kubernetes identities can actually do, inspect both sides of each access grant: the Role or ClusterRole rules that define permissions and the RoleBinding or ClusterRoleBinding that assigns them to subjects. Then check each grant’s scope, validate representative actions with kubectl auth can-i, and use audit records as context—not as proof that an unused permission is unnecessary. Kubernetes RBAC is additive, so removing unwanted access means changing the binding or rule that allows it.
What makes an RBAC permission a real grant?
A role definition by itself does not say who receives its permissions. A binding connects a role to one or more subjects, which can be users, groups, or service accounts. To understand an identity’s access, trace the binding to its referenced role and inspect the rules there. Reviewing role definitions without their bindings misses that subject-to-permission connection.
Kubernetes has four core RBAC object kinds. Their scope determines where the resulting grant applies:
| Object | What it does | Scope of the grant |
|---|---|---|
Role |
Defines permissions in rules | One namespace |
ClusterRole |
Defines permissions in rules | Can be used for cluster-wide or namespace-scoped grants, depending on the binding |
RoleBinding |
Assigns a Role or ClusterRole to subjects | One namespace, even when it references a ClusterRole |
ClusterRoleBinding |
Assigns a ClusterRole to subjects | Cluster-wide |
This distinction matters: a ClusterRoleBinding grants its referenced permissions across the cluster, while a RoleBinding that refers to a ClusterRole limits that grant to the RoleBinding’s namespace. See Kubernetes’ RBAC object model.
#1 Best Overall
How to audit effective access
1. Set the review boundary
Record the cluster, environment, review date, and namespaces in scope. Identify the authentication identities relevant to that environment, including individual users, groups, service accounts, and any external identity mapping that supplies Kubernetes subjects. Match the exact subject names used in authorization requests; a display name in an identity provider does not, by itself, establish that Kubernetes sees the same name.
2. Inventory all four object kinds
Collect namespaced Roles and RoleBindings across namespaces, along with ClusterRoles and ClusterRoleBindings. Preserve the full YAML or JSON so the namespace, subjects, role references, resources, and verbs remain available for review.
kubectl get roles,rolebindings -A -o yaml
kubectl get clusterroles,clusterrolebindings -o yamlThese are example read-only inventory commands, not a required Kubernetes-prescribed command sequence. Adapt output handling to your access controls and data-retention requirements. The Kubernetes RBAC documentation describes the four object kinds.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →3. Trace each binding to its subjects and rules
For each binding, record its namespace when applicable, every subject’s kind and exact name, and the roleRef kind and name. Follow that reference to the role’s rules, then group the resulting grants by subject. This lets you answer both “who receives this role?” and “what can this identity do?”
Do not infer the scope from the role’s name or kind alone. Use the binding to establish whether the permission applies in one namespace or cluster-wide, then consider the rules it connects to the subject.
4. Review sensitive permissions and escalation paths
Assess each grant against the workload or job it supports. Look for wildcard resources or verbs, permissions over sensitive resources such as Secrets, and rights to create or change roles and bindings. Pay particular attention to bind and escalate: Kubernetes uses these permissions in restrictions on granting rights beyond those a subject already holds. Review impersonation separately when present; Kubernetes authorization documentation covers impersonation of users, groups, and service accounts.
Also consider whether access to credentials or workload capabilities could broaden access. A broad-looking grant is not automatically unnecessary, and a narrowly named role is not automatically safe. Trace the full binding-and-rule chain and ask the owner to justify the resources, verbs, and scope against the actual operational need. Kubernetes’ RBAC good practices recommend specifying the resources and verbs a workload needs and using namespace scope where possible.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Check representative actions
Use kubectl auth can-i to ask whether an action is authorized in the current cluster context. For example:
kubectl auth can-i get pods -n payments --as=system:serviceaccount:payments:reporter
kubectl auth can-i list secrets -n payments --as=system:serviceaccount:payments:reporterThe documented command queries authorization through a SelfSubjectAccessReview. Impersonating another subject requires permission to impersonate that identity. If the impersonation attempt fails, that does not show whether the target identity would be allowed to perform the requested action. Keep checks within the review plan and record the tested identity, namespace, resource, verb, and result so another reviewer can reproduce them.
kubectl auth can-i --list can help explore permissions, but it is one validation view, not a substitute for tracing bindings, rules, and scope. Authorization can involve mechanisms beyond RBAC, so describe a result as the effective authorization outcome in the tested cluster context—not proof that a particular RBAC object caused it. See the Kubernetes authorization documentation.
6. Add audit-log context
Kubernetes auditing records security-relevant actions chronologically. If records are available for the review period, use them to see which actions occurred and to inform conversations with service or workload owners. The API server can be configured with an audit policy file through --audit-policy-file; the details depend on the cluster’s audit configuration. An action not observed during the selected period may still be needed later, so absence from the logs does not establish that a permission is safe to remove. See the Kubernetes auditing documentation.
Recommended Free Tools
How to turn the audit into a least-privilege change
For each finding, document the subject, binding, referenced role, scope, rules of concern, supporting evidence, owner, and smallest proposed safe change. Prefer namespace-scoped access when the workload needs only that namespace, and limit resources and verbs to the operational requirement.
RBAC has no negative deny rules: adding a narrower allow does not cancel a broader allow elsewhere. Find and change the binding or rule responsible for the unwanted permission. After the change, validate both the access the workload must retain and important actions it should no longer be able to perform.
The Kubernetes documentation pages linked above were consulted on October 7, 2026. Because the review does not establish behavior for a particular Kubernetes release, check the documentation for the cluster’s target version before relying on version-specific command or feature details.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
