RBAC

RBAC is a way of answering one question: is this user allowed to do this action on this thing? Instead of writing a rule for every user, you define a small set of roles, attach permissions to each role, and then assign roles to users. A permission is usually a verb plus a resource, like read:invoices or delete:user.

The core relationship has three layers. Users are assigned to roles. Roles hold permissions. Permissions describe what can be done. A user inherits every permission of every role they hold, so the access check becomes: does any role this user has contain the permission being requested?

This indirection is the whole point. A company with 5,000 employees and 200 distinct permissions does not manage a million user-to-permission links. It manages maybe 30 roles, and each new hire gets one or two role assignments. The NIST RBAC standard formalized this in 1992 and it is still the default model in almost every enterprise system.

At its simplest, RBAC needs three tables: users, roles, and permissions, plus two join tables for user_roles and role_permissions. An authorization check joins through these: given a user id and a requested permission, the system asks whether a row exists linking that user to a role that holds that permission.

Many systems add role hierarchies so that a senior role inherits everything a junior role has. A Manager role might include the Employee role, so you define the manager permissions once and inherit the rest. This keeps role definitions small and avoids copy-pasting permission lists.

In practice the role assignments are encoded so the check is fast. After login the user's roles often get baked into a signed JWT or session, so most requests verify access in memory without a database round trip. Permission-to-role mappings are usually cached and refreshed on change, because they are read constantly and written rarely.

Use RBAC when access maps cleanly to job functions and the same access applies to everyone in that function. Internal tools, admin dashboards, SaaS team accounts, and Kubernetes clusters all fit this shape well. It is simple to reason about, easy to audit, and reviewers can answer who can do what by reading a short list of roles.

The classic failure mode is role explosion. The moment access depends on context, like region, department, or ownership of a specific record, teams start creating roles like editor_us_west_finance. You can end up with more roles than users, which defeats the purpose.

When you need per-record or contextual rules, RBAC alone is the wrong tool. Attribute-Based Access Control (ABAC) makes decisions from attributes such as the user's department and the document's owner, and policy engines like Open Policy Agent express this directly. A common production pattern is RBAC for the coarse layer (can this user reach the billing area at all) plus ABAC or ownership checks for the fine layer (can they see this specific invoice).

Take a publishing platform. You define three roles. Viewer can read:articles. Editor inherits Viewer and adds write:articles and submit:review. Admin inherits Editor and adds publish:articles, manage:users, and delete:articles.

A new writer joins and you assign them Editor. They can immediately read, write, and submit articles for review, with no individual permissions touched. When they get promoted to managing editor, you assign Admin and remove Editor, and their access changes in one step.

When the writer leaves, you delete their role assignments and every permission disappears at once. There is no hunting through scattered grants to make sure nothing was missed, which is exactly what auditors and SOC 2 reviewers want to see.