Once we know who someone is (AuthN), we need to decide what they can do (AuthZ). The most widely deployed model for this is RBAC — Role-Based Access Control.
The Core Idea: Permissions Belong to Roles, Not People
Imagine you're managing access for 500 engineers. If you assign permissions directly to each person, you have 500 individual permission sets to maintain. When someone changes teams, you have to manually find and update their specific permissions. When a new permission needs to be granted to all senior engineers, you have to touch hundreds of records.
RBAC solves this by introducing an indirection layer: Roles.
A Role is a named collection of permissions. You define the role once, then assign users to roles. The permission management problem collapses from "N users × M permissions" to "R roles × M permissions" — a much smaller surface.
Role Definition (what the role can do):
Role: junior_dba
Permissions:
- SELECT on schema.non_sensitive_tables
- EXECUTE on stored_procedure.run_explain_plan
- VIEW PROCESSLIST
Role Binding (who has the role):
User: alice@company.com → Role: junior_dba
User: bob@company.com → Role: junior_dba
If Alice gets promoted, you change her binding to senior_dba. If the junior_dba role needs a new permission, you update the role definition once and both Alice and Bob immediately inherit it.
RBAC in Practice: Kubernetes Example
Kubernetes uses RBAC natively, and its object model mirrors the definition/binding split directly: a Role object lists the resources (e.g., pods) and verbs (get, watch, list) it grants within a namespace, and a separate RoleBinding object attaches that Role to a specific subject — a user, group, or service account. Alice, bound to a pod-reader Role scoped to the production namespace, can get, watch, and list pods there — nothing more.
The Limits of RBAC: Role Explosion
RBAC's weakness emerges when business requirements become dynamic. Consider: "Junior DBAs can only access the database during business hours." There's no "time" concept in RBAC. The workaround is to create a new role: junior_dba_business_hours. Then you need junior_dba_weekend_oncall, junior_dba_us_region_only, and so on. This is called role explosion — the number of roles grows combinatorially to handle every edge case, and the system becomes as hard to manage as direct permission assignment.
Pros: Simple to understand, easy to audit ("Who has admin access?" is a single query), well-supported by virtually every platform.
Cons: Rigid. Struggles with dynamic, context-sensitive requirements. Prone to role explosion in complex organizations.