Kubernetes RBAC evaluates every API request by matching the user’s identity to a Role or ClusterRole, then checking if a RoleBinding or ClusterRoleBinding links that identity to the role. If no match exists, the request is denied by default. This mechanism controls access to API resources, not network traffic or file systems.
The Request Lifecycle
When a pod or a user interacts with the cluster, the request does not go directly to the resource. It hits the API server first. The API server acts as the gatekeeper for all operations within the cluster. It validates the request syntax and checks the identity of the requester. Only after these initial checks does the authorization engine engage.
This engine uses Role-Based Access Control, a method that grants permissions based on the role assigned to an identity. You define these roles in objects called Roles or ClusterRoles. These objects list specific verbs, such as get, list, or delete, and the resources they apply to, such as pods or services. The binding objects, RoleBindings and ClusterRoleBindings, connect the identity to the role. Without a binding, the role exists but grants no access to anyone.
Stage 1: Authentication and Identity Resolution
The process begins with authentication. The API server must determine who is making the request. For human users, this often involves certificates or tokens. For pods, the identity is derived from the service account mounted into the container. A service account is an identity for processes that run in a pod, distinct from a user account.
If the API server cannot verify the identity, the request is rejected immediately. No authorization check occurs because there is no subject to authorize. This stage is critical because RBAC relies entirely on the accuracy of the authenticated identity. If a pod uses a default service account, it inherits all bindings attached to that account. This creates a hidden attack surface where any compromised pod gains the permissions of the default account.
Stage 2: Role and Binding Lookup
Once the identity is established, the API server searches for roles that apply to the request. It looks for RoleBindings in the same namespace as the requested resource. If the resource is cluster-scoped, like nodes or persistent volumes, it looks for ClusterRoleBindings. The server collects all roles associated with the identity.
This lookup is additive. If an identity has multiple bindings, the permissions from all associated roles are combined. This means you cannot use a binding to restrict permissions granted by another binding. If one role allows deleting pods and another allows reading pods, the user can do both. There is no deny rule in Kubernetes RBAC. You can only grant permissions; you cannot explicitly forbid an action that another role allows.
Stage 3: Permission Evaluation
The API server compares the requested action against the aggregated permissions. It checks if the verb matches and if the resource type is included. It also checks the resource name if the role specifies a specific instance. For example, a role might allow getting only the config map named "app-settings".
If the request matches any of the aggregated permissions, the API server authorizes the action. If no match is found, the request is denied. This is the default deny posture. However, this evaluation only covers API calls. It does not control network traffic between pods. Two pods might have no RBAC permissions to interact, yet they can still communicate over the network if network policies do not block them. This separation of concerns often leads to confusion about what RBAC actually protects.
Stage 4: Audit and Execution
After authorization, the API server records the decision in the audit log. This log captures the user, the action, the resource, and the result. It does not capture the data payload. The API server then forwards the request to the appropriate backend component, such as the etcd database for storage or the scheduler for pod creation.
If the request modifies state, the change is written to etcd. Etcd is the distributed key-value store that holds all cluster data. RBAC does not protect the data at rest in etcd. If an attacker gains access to the etcd endpoints, they can read all secrets and configurations regardless of RBAC settings. This is why securing the control plane infrastructure is as important as configuring RBAC. See our guide on Kubernetes security basics for details on hardening the control plane.
See also: Cloud Ransomware Explained: How Attacks Reach Your Data · Secure file sharing for business: control access and prevent leaks
The Limits of API Authorization
RBAC is not a silver bullet. It only controls access to the Kubernetes API. It does not control access to the underlying cloud infrastructure. A pod with RBAC permissions to read secrets can still exfiltrate that data to an external server if the network allows it. RBAC also does not protect against vulnerabilities in the applications running inside the pods. If an application has a remote code execution flaw, RBAC cannot stop the attacker from exploiting it.
Furthermore, RBAC does not enforce least privilege automatically. Many administrators grant the "admin" or "edit" role to service accounts for convenience. This violates the principle of least privilege. Over time, these permissions accumulate. This leads to identity sprawl, where it becomes difficult to track which identities have access to which resources. Regularly auditing service account permissions is necessary to maintain security.
Stage 5: Dynamic Updates and Caching
Role and binding changes are not always instantaneous. The API server caches authorization decisions to improve performance. When you update a Role or a Binding, the cache may take a short time to invalidate. During this window, old permissions may still apply. This delay is usually minimal but can cause confusion during incident response.
Imagine a scenario where you revoke a compromised service account’s permissions. The API server may still allow requests from that account for a few seconds. This is a known behavior of the authorization cache. You cannot rely on immediate revocation for critical containment. For faster containment, you must stop the pods using the service account or block the network traffic. See our guide on cloud incident response for strategies on containing active threats.
Summary Table
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Authentication | Identity is verified via certs or tokens. | Invalid credentials or expired tokens. |
| Lookup | Bindings are found for the identity. | No binding exists for the identity. |
| Evaluation | Request is matched against role permissions. | Verb or resource not allowed by any role. |
| Execution | Request is processed and stored. | Backend failure or resource quota limits. |
| Audit | Action is logged for review. | Audit log storage failure or misconfiguration. |
Practical Implementation Strategy
To implement effective RBAC, start by auditing your current service accounts. Identify which pods use the default service account and replace them with dedicated accounts. Create Roles that grant only the specific permissions needed. Avoid using ClusterRoles for namespace-scoped resources unless necessary. ClusterRoles apply across all namespaces, which can lead to unintended access.
Use labels and annotations to document why a specific permission was granted. This helps during audits and reduces confusion. Test your policies in a non-production environment before applying them. Use tools that simulate RBAC decisions to verify that your configurations work as expected. This proactive approach prevents lockouts and ensures that security controls do not hinder operations. See our guide on immutable infrastructure for ways to manage configuration changes safely.
Key takeaways
- RBAC decisions happen at the API server layer before any workload executes.
- Service accounts are the primary identity for pods, making their binding configuration critical.
- A missing RoleBinding results in a denial, but a misconfigured binding allows excessive access.
RBAC controls API access but does not replace network segmentation or application security. Audit your service account bindings regularly to prevent permission creep.
Frequently asked questions
Does RBAC protect data at rest in etcd?
No, RBAC only controls API access. Etcd data must be protected by encrypting the storage layer and securing network access to the etcd endpoints.
Can I deny a specific action in RBAC?
No, Kubernetes RBAC only supports allow rules. If multiple roles grant different permissions, they are combined. You cannot create a deny rule to override an allow.
How long does it take for RBAC changes to take effect?
Changes are usually immediate, but the authorization cache may delay enforcement by a few seconds. For critical revocations, stop the affected pods immediately.
Does RBAC control network traffic between pods?
No, RBAC does not control network traffic. You must use network policies to restrict communication between pods at the network layer.
How this guide was produced: written by the SecOps Monitor editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
