RBAC & Security
RBAC — Roles, ClusterRoles, Bindings
Granting fine-grained access to cluster resources.
Introduction
In a multi-tenant or multi-developer Kubernetes cluster, securing access to the control plane is essential. Role-Based Access Control (RBAC) allows administrators to regulate who can access what resources in the cluster, and what operations they are permitted to perform.
Kubernetes RBAC evaluates request permissions by mapping a Subject (a User, Group, or ServiceAccount) to a set of Rules (APIGroups, Resources, and Verbs) using Bindings.
Why It Matters
Without RBAC boundaries, every authenticated user or process has administrator rights. A developer trying to list logs in a dev namespace could accidentally delete production namespaces or leak sensitive ConfigMaps, creating operational hazards.
Real-World Analogy
Think of RBAC like an office building keycard security registry. A receptionist gets a keycard programmed to access the lobby and photocopy room in their local floor department (Role & RoleBinding). They cannot enter the research department on floor 5. However, a fire warden gets a master keycard programmed to access all corridors and doors across all floors in the entire building (ClusterRole & ClusterRoleBinding).
How It Works
When a subject presents credentials to the API Server, the request goes through the authentication phase. Once identified, the API Server's authorization loop checks the request context. It verifies if the subject has a RoleBinding or ClusterRoleBinding referencing a Role or ClusterRole containing rule matches for the requested API group, resource, and verb. If no match is found, the API Server returns a HTTP 403 Forbidden error.
Internal Architecture
Kubernetes RBAC rules are structured around API Groups. Every resource belongs to an API group (such as apps for Deployments or "" for core resources like Pods). In-memory caching stores active bindings. When an API call is made, the authorization controller performs rapid lookup against these rules:
- apiGroups: The API categories matching the resource.
- resources: The target objects (e.g.
pods) and subresources (e.g.pods/logorpods/status). - verbs: The permitted actions: read-only (
get,list,watch) or write-modify (create,update,patch,delete).
Visual Explanation
Practical Example
Here is how to create a Role that allows reading pods, and a RoleBinding to bind it to a developer named alice inside the development namespace:
1. The Role definition (role.yaml)
2. The RoleBinding definition (rolebinding.yaml)
Common Mistakes
- Wildcard Abuse: Using
"*"in production roles instead of specifying exact API groups and resources. - Scoping Errors: Binding a Role instead of a ClusterRole for cluster-wide objects like
nodesorpersistentvolumes. - Namespace Mismatch: Creating a RoleBinding in namespace A referencing a Role in namespace B, which fails to grant any permissions.
Quick Quiz
Q1: What is the effect of binding a ClusterRole to a User using a standard RoleBinding instead of a ClusterRoleBinding?
A) The user gets administrator rights over the entire cluster.
B) The user is granted the permissions defined in the ClusterRole, but only within the specific namespace where the RoleBinding is created.
C) The binding is ignored and rejected by the API Server.
D) The user's namespace is deleted.
Answer: B — Binding a ClusterRole via a RoleBinding allows reusing global pre-configured roles (like 'view') inside individual namespaces without duplicating Role manifests.
Q2: Which verb in Kubernetes RBAC rules grants the ability to modify resource specifications (spec) imperatively?
A) list
B) create
C) update
D) watch
Answer: C — The 'update' and 'patch' verbs allow modifications to existing resource specifications, whereas 'create' is restricted to adding new resource instances.
Scenario-Based Challenge
Production Scenario:
A developer tries to run kubectl get configmaps -n staging but receives: Error from server (Forbidden): configmaps is forbidden: User "bob" cannot list resource "configmaps" in API group "" in the namespace "staging". You want to give Bob access to view configmaps in staging. How do you resolve this using the least-privilege principle?
To grant read-only access to configmaps for Bob:
1. Create a Role in the staging namespace that defines the permission to get and list configmaps:
2. Create a
RoleBinding in the staging namespace linking Bob to this Role:
Debugging Exercise
Broken Configuration:
A developer wants to run kubectl logs my-pod but receives a permission error. The Role configured for them is:
Reason: Log retrieval is a subresource of pods. Accessing the log endpoint requires permissions on the resource pods/log.
The Fix: Update the Role's resources array to include pods/log:
Interview Questions
1. Conceptual: What are the risks of granting the "bind" verb in a Role definition?
Granting the "bind" verb on roles allows a subject to associate roles with other users or service accounts. If not restricted, a user with limited namespace permissions can bind the "admin" ClusterRole to themselves or to a service account they control, elevating their own privileges to cluster administrator (privilege escalation).
2. Technical: How do you verify if a specific service account has permission to perform a command without running it?
Use the kubectl auth can-i command, specifying the resource, verb, and using the --as flag to impersonate the user or service account: kubectl auth can-i create deployments --as=system:serviceaccount:default:my-sa -n production.
Production Considerations
Avoid using the wildcard character ("*") for resources or verbs in production roles. Declare exact permissions explicitly. Conduct regular audits of ClusterRoleBindings to detect stale accounts with broad permissions.