RBAC in Kubernetes: Who Can Do What, Where, and Why
Kubernetes RBAC is easiest to understand as an authorization decision about an API request. An identity asks the API server to perform a verb on a resource in a scope. RBAC rules and bindings determine whether that request is allowed. The important words are not the object names by themselves; they are who, can do what, to which resources, and where.
That framing separates several ideas that are often blurred together. Authentication establishes who the caller is. Authorization determines what that identity may do. Admission can then evaluate or modify an allowed request based on policy. RBAC belongs in the authorization stage, so giving someone a valid certificate or service-account token does not automatically give that identity useful permissions.
For Kubernetes administrators, RBAC is both a security control and an operations dependency. A workload can fail because it lacks permission to read a ConfigMap. A controller can appear broken because it cannot watch the resources it reconciles. An administrator can accidentally grant cluster-wide power when only one namespace was intended. The safest way to reason about these cases is to make scope explicit.
Identity and permission are different problems
Kubernetes has service accounts as API objects for non-human identities, while normal human users are generally represented by external identity systems rather than User objects stored in the cluster. Both kinds of identities can authenticate to the API and then be evaluated by the configured authorization mechanisms.
This matters because identity alone does not answer the access question. A service account token proves that a request is acting as a particular service account; it does not say whether that account may list Secrets or patch Deployments. The API server still has to authorize the requested action.
The distinction mirrors the broader practice of identity and access management: authentication establishes the principal, while authorization limits what the principal can do. Mixing the two leads to over-permissioned fixes because teams try to solve an authorization error by changing credentials rather than changing the minimum required access.
Role and ClusterRole describe permissions, not subjects
An RBAC Role contains permission rules within one namespace. A ClusterRole is cluster-scoped and can describe permissions on cluster-scoped resources such as Nodes, permissions across namespaced resources, or reusable namespaced permissions that can later be bound in selected namespaces. Neither object says who receives those permissions.
Rules are built from API groups, resources, verbs, and sometimes resource names or non-resource URLs. Kubernetes RBAC permissions are purely additive: there are no deny rules that subtract access granted elsewhere. That means the effective permission set is the union of all applicable grants.
This is why broad roles are dangerous even when a narrow role also exists. The narrow role does not override the broad one. If another binding grants the same identity powerful permissions, the identity keeps them. Least privilege therefore depends on understanding all bindings that affect a subject, not merely reviewing the role that looks most relevant.
Bindings answer who receives the rules and in which scope
RoleBinding and ClusterRoleBinding attach roles to subjects such as users, groups, or service accounts. A RoleBinding exists in a namespace and grants permissions within that namespace. It can reference a Role from the same namespace or a ClusterRole, but the resulting grant remains limited to the RoleBinding’s namespace.
A ClusterRoleBinding grants a ClusterRole across the cluster. That difference is small in YAML and enormous in effect. Replacing a RoleBinding with a ClusterRoleBinding can turn a namespace-limited permission into access across every namespace or to cluster-scoped resources, depending on the ClusterRole.
Kubernetes’ own RBAC guidance recommends namespace-level permissions where possible. The same principle appears in cloud identity and access design: make the administrative boundary as small as the job allows, then expand only when an operational need is demonstrated.
Verbs and subresources determine what “access” really means
Permissions are more specific than “access to Pods.” Reading Pods, deleting Pods, creating Pods, and updating Pods are different verbs. Some operations use subresources, so a user allowed to read a Pod may not automatically have permission to perform every action associated with that Pod.
This is important for sensitive resources. Listing Secrets can expose secret data, and permissions that let an identity create workloads can sometimes provide indirect paths to credentials or privileged execution. An apparently modest permission can therefore have larger consequences when combined with other capabilities.
Administrators should describe the actual task before writing the rule: “this controller needs to list and watch ConfigMaps in namespace X” is much safer than “this controller needs read access.” Specific verbs, resources, and namespaces make review possible and reduce the temptation to reach for cluster-admin whenever an application receives a Forbidden response.
Service accounts should represent workloads deliberately
Every namespace has a default service account, and Pods that do not specify another service account use it. That convenience can become risky if teams grant powerful permissions to the default account, because every Pod that falls back to that identity may inherit them.
A stronger pattern is to create an application-specific service account, grant only the required permissions, and assign it explicitly with serviceAccountName. Modern Kubernetes can issue time-bound projected service-account tokens, and applications that do not need API access can avoid unnecessary token exposure.
This workload-identity mindset is central to cloud security operations. The question is not only whether a person has excessive rights; controllers, jobs, agents, and applications are API clients too. Compromise of a Pod becomes more serious when its service account can modify unrelated workloads or read secrets across namespaces.
Namespaces help scope authorization, but they are not a complete security boundary
Many RBAC decisions are naturally scoped by namespace, which makes namespaces useful for separating teams and applications. But some Kubernetes resources are cluster-scoped, and shared components such as nodes, storage classes, custom resource definitions, and admission configuration sit outside a single namespace.
That means a namespace design must be paired with careful ClusterRole and ClusterRoleBinding review. A user who has limited rights in one namespace can still gain broad power through a separate cluster-wide grant. Similarly, a workload with permission to create certain privileged resources may be able to affect more than the namespace suggests.
The practical lesson is to treat namespace as one dimension of authorization. The other dimensions are the subject, the verbs, the resource types, and the bindings. Security comes from the combined decision, not from the namespace label alone.
RBAC design also has to account for privilege escalation paths. Permission to create Pods can be powerful if those Pods can mount service-account credentials, host paths, or other sensitive resources. Permission to modify Roles or Bindings can be more powerful than the individual verbs listed in an application role. Reviewing access therefore means asking what an identity can cause the cluster to do, not only which nouns appear in its rules.
Built-in ClusterRoles such as view, edit, and admin can be convenient building blocks, but convenience should not replace review. Their semantics are broader than a one-off custom Role, and aggregated ClusterRoles can change as labels add rules. Teams that rely on built-in roles should understand the effective permissions and test them against the actual responsibilities of the subject.
Troubleshoot Forbidden errors by asking what request was denied
A Forbidden message is useful evidence. It usually identifies the identity, the verb, the resource, and the scope that failed authorization. Instead of immediately granting a broad role, translate the error into the RBAC decision that needs to be evaluated.
Commands such as kubectl auth can-i can test whether an identity is authorized for a particular action. Administrators can also inspect RoleBindings and ClusterRoleBindings that reference the subject or relevant groups. The goal is to find the missing minimum permission or the unexpected grant, not to silence the error with a permanent super-user binding.
People who move beyond the CKA eventually discover that RBAC failures are often configuration-management failures. Permissions change over time, controllers evolve, and reusable ClusterRoles acquire new rules. Treating access as code that is reviewed and tested is safer than treating it as an emergency fix.
Access review should include groups as well as directly named users and service accounts. Human identities commonly arrive from an external identity provider with group claims, and a single ClusterRoleBinding to a broad group can explain permissions that do not appear in any user-specific object. When an administrator asks why someone can perform an action, the answer may be a chain from external group membership to a binding to a ClusterRole. Documenting that chain makes periodic access review and incident response much easier.
Periodic review should compare intended responsibilities with effective permissions, especially after teams move, namespaces are reorganized, or automation changes. Stale RoleBindings are easy to overlook because nothing fails when excess access remains. Removing an obsolete grant can therefore be as important as adding a missing one. Access that is never exercised is not automatically harmless; it is unused attack surface.
CKA practice should connect RBAC objects to real requests
A useful lab creates a namespace, a service account, a Role, and a RoleBinding, then verifies exactly which operations succeed and fail. Change the binding to reference a ClusterRole while keeping it namespaced. Then compare that behavior with a ClusterRoleBinding. The YAML looks similar, but the authorization scope changes dramatically.
That is the operational skill behind the CKA exam: reading the request, understanding the resource scope, and making a targeted change that preserves the rest of the cluster’s security model. Memorizing the four RBAC object names is not enough.
Within the wider set of CNCF certifications, RBAC also acts as a bridge between administration and security. The best design answers a simple sentence precisely: this identity needs these verbs on these resources in this scope, and nothing broader is required.