From Identity to Permission
Once the API server knows who you are (authentication), it passes your identity — username and group memberships — to the authorization layer. Kubernetes supports multiple authorization modes, but RBAC (Role-Based Access Control) is the standard and the one you will use in every production cluster.
RBAC answers the question: "Is the entity identified as alice in group devs allowed to perform DELETE on pods in namespace production?"
The Four RBAC Objects
RBAC is built from four Kubernetes resource types:
| Object | Scope | Purpose |
|---|---|---|
Role |
Namespaced | Defines a set of permissions within one namespace |
ClusterRole |
Cluster-wide | Defines permissions across all namespaces or for cluster-scoped resources |
RoleBinding |
Namespaced | Grants a Role or ClusterRole to a user/group within one namespace |
ClusterRoleBinding |
Cluster-wide | Grants a ClusterRole to a user/group across the entire cluster |
A Role defines what can be done — a list of rules, each naming an API group, a set of resources (like pods), and a set of verbs (get, list, watch, and so on). A RoleBinding defines who can do it, linking that Role to one or more subjects (a User, Group, or ServiceAccount) — for example, binding a read-only pod-reader Role to the user [email protected], whose name must match the username claim extracted from her JWT.
The Additive (Allow-Only) Model
RBAC in Kubernetes is strictly additive. This is the single most important thing to understand about how it works:
- Default state: Deny everything. A user with no bindings can do nothing.
- Evaluation: The API server collects every
RoleandClusterRolebound to the requesting user (by username) and to every group the user belongs to. It takes the union of all permissions. - Decision: If any rule in the union permits the requested action, the request is allowed. Otherwise, it is denied.
- No Deny rules: Standard Kubernetes RBAC has no concept of an explicit
Deny. You cannot grant broad access and then carve out exceptions with a deny rule.
This has a critical architectural implication: you cannot use RBAC alone to restrict a subset of a broad permission. If a user has ClusterAdmin via one binding, a second binding granting only view does not reduce their access — it simply adds fewer permissions than they already have. The only way to restrict access is to remove the permissive binding.
A common interview question is: "How would you prevent a user with edit access from deleting secrets, while still allowing them to read and update them?" The correct answer is: you cannot do this with standard Kubernetes RBAC alone, because RBAC has no deny rules. The solution is to not grant the edit ClusterRole (which includes secret deletion) and instead create a custom Role with precisely the verbs you want to allow. This tests whether the candidate understands the additive-only model versus systems like AWS IAM that support explicit denies.