Role-Based Access Control (RBAC)
Permissions granted through roles rather than to individuals — the access model that scales to thousands of users, until role explosion sends you toward ABAC.
What is RBAC?
Role-Based Access Control decouples permissions from people: you define roles (billing-admin, read-only-analyst), attach permissions to roles, and assign users to roles. Nobody gets permissions directly — they inherit them via role membership. The payoff is operational sanity at scale: onboarding is “add to roles,” offboarding is “remove from roles,” and audits ask the tractable question “who is in the admin role?” instead of inspecting thousands of individual grants. It’s the default in Kubernetes, cloud IAM, and virtually every enterprise app.
The failure mode: role explosion
RBAC’s clean model degrades predictably. Reality needs “editor, but only for the EU region, only for marketing content, only during business hours” — dimensions roles can’t express, so teams mint hyper-specific roles for each combination. Soon there are more roles than users, role assignment is its own confusing job, and nobody can say what a role actually grants. This is the signal to introduce attributes: ABAC evaluates policies over user/resource/context attributes (department == resource.owner_dept AND time in business_hours), collapsing a combinatorial role sprawl into a handful of rules. Mature systems run hybrid — RBAC for coarse structure, ABAC for fine-grained conditions.
Implementation discipline
Design permissions, not just roles — a well-factored permission set makes roles composable. Enforce least privilege within RBAC (roles drift toward over-provisioning exactly like individual grants). And separate the model from the enforcement point: policy engines (OPA, Cedar) increasingly externalize authorization so RBAC/ABAC logic lives in one auditable place rather than scattered across services.
What people get wrong
- A role per user — that’s individual permissions wearing a costume; roles must be shared to pay off.
- Never pruning roles: dead roles and their orphaned permissions are standing risk.
- Forcing contextual rules into roles until the role count explodes, when the answer was attributes.
Primary source: NIST — Role-Based Access Control
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.