Role-Based Access Control (RBAC): access follows the job

“Same access as David”

When Daniel moves from support to the billing team, his new manager opens a ticket with one line: “Please give Daniel the same access as David.” It’s the most common access request in the world, and it’s quietly terrible. The administrator copies every permission David has accumulated over six years, including access to two systems David only used for a project in 2021 and a shared drive from a team that no longer exists. Nobody removes Daniel’s support access, because the ticket didn’t ask. Six months later, an audit finds that Daniel can both raise a refund in the support tool and approve it in billing.

The previous two articles set up a gap. DAC lets owners share freely, which doesn’t scale and can’t be governed. MAC imposes rigid labels, too inflexible to run a company day to day. Neither answers the question a real organization actually asks: “this person works in billing, so give them what billing people get.” Access should follow what people do, not who owns a file or how a document is classified. The model that does that, and that governs access in the vast majority of companies, is role-based access control (RBAC).

The core idea is one powerful layer of indirection. Instead of granting permissions to users, you grant permissions to roles and assign users to roles. A role is a named bundle of permissions that corresponds to a job: “Support Agent,” “Auditor,” “Warehouse Clerk,” “Billing Admin.” When Daniel joins billing, he’s assigned the Billing Admin role and has exactly what billing needs, nothing copied from anyone. When he moves again, the role is swapped. Nobody edits thousands of individual grants; you manage the much smaller set of role memberships. That indirection is why RBAC scales where DAC doesn’t.

RBAC isn’t folklore; it’s a formal standard. Grouping access by job is old, but RBAC as a model was set out in a 1992 paper by David Ferraiolo and Richard Kuhn at NIST, who argued that most non-military organizations were doing neither pure DAC nor MAC but something in between, assigning access by organizational role, and that this deserved to be a model in its own right. The idea matured through the 1990s into the 2000 NIST reference model and the INCITS 359 American national standard. Because it’s standardized, “RBAC” means something specific, and you can hold a vendor’s “role-based” claim up against a real definition.

Three elements, two assignments

Strip RBAC to its bones and there are three kinds of thing and two relationships between them. Users are the people, and more and more often workloads. Permissions are what you can do to objects, such as “read invoice,” “delete user,” or “approve refund,” and a permission is itself a pair: an operation (read, delete, approve) applied to an object (invoice, user, refund). Getting that granularity right is subtle. Too coarse, like “access billing,” and roles can’t enforce least privilege; too fine, like “read field 7 of invoice 402,” and the permission set becomes unmanageable. Roles sit between users and permissions. Two assignments connect them: user-to-role, as in “Daniel is a Billing Admin,” and permission-to-role, as in “Billing Admin can edit invoices.” A user’s effective access is the union of the permissions of all their roles.

The right-hand column is why any organization bigger than a handful of people ends up with RBAC. It turns access management from a problem the size of users times resources into one the size of the role catalog, and roles change far more slowly than users or resources do.

There’s a subtler benefit in that last row. Because a job’s access is defined in one place, RBAC makes access describable. You can hand a new manager the list of roles their team holds and they can actually understand it, which no pile of per-object ACLs allows. That legibility is what makes access reviews, audits, and least-privilege decisions possible for people to carry out. A model whose state someone can hold in their head is a model whose mistakes someone can catch.

People often equate roles with directory groups, and in practice Active Directory and LDAP groups are the most common way to implement them. Conceptually, though, a group is a set of users, while a role is a set of permissions that users are then assigned to. A well-designed role is named for a job and owns a curated set of permissions; groups often just accumulate. When groups are named for jobs and map cleanly to permissions, they are RBAC. When they’re named “temp-access-projectX-2019,” they’re DAC sprawl dressed as a group.

The NIST model: four levels

The standard defines RBAC as nested capabilities, each adding power, and the levels give you vocabulary for saying how sophisticated a system’s RBAC really is.

Core RBAC is the baseline just described: users, roles, permissions, the two assignments, and sessions, which we’ll come to. Hierarchical RBAC adds role hierarchies, in which senior roles inherit the permissions of junior ones. Define “Employee” with what everyone needs, let “Engineer” inherit Employee and add engineering permissions, let “Senior Engineer” inherit Engineer. Shared access is specified once and the hierarchy mirrors the org chart. Two cautions keep hierarchies safe. Inheritance runs upward, so a permission added to a junior role reaches every role above it, and the base Employee role has to stay deliberately minimal, because it’s the blast radius for the whole company. And don’t model seniority and function on the same axis: a Senior Engineer inheriting Engineer is clean, but making Engineer inherit Support Agent because both are “staff” mixes unrelated permissions and leads straight to role explosion. Hierarchies should express “a more privileged version of,” not organizational closeness.

Constrained RBAC adds separation-of-duties constraints and often cardinality constraints, limits such as “at most two people may hold Domain Admin.” Capping the membership of your most dangerous roles limits blast radius directly and forces a deliberate decision every time someone new needs that power. Symmetric RBAC adds permission-role review, the ability to ask efficiently “who has this permission, and through which roles?”, which is the auditability that makes RBAC governable. Most enterprise systems implement core and hierarchical RBAC plus some constraints; full symmetric review is the mark of a mature identity governance program.

flowchart LR
  accTitle: Role-Based Access Control structure with a role hierarchy
  accDescr: On the left are users Sara, Daniel, and David. Each user is assigned to one or more roles in the middle: Sara to Senior Engineer, Daniel to Support Agent, David to Billing Admin. A role hierarchy is shown where Senior Engineer inherits from Engineer, which inherits from a base Employee role that all roles include. On the right are permissions. Each role is connected to the permissions it holds: Employee to read-directory, Engineer to deploy-service, Support Agent to read-ticket and issue-refund, Billing Admin to edit-invoice. Arrows flow from users through roles to permissions, illustrating that access is granted indirectly through role membership rather than directly to users.
  U1[Sara] --> R3[Senior Engineer]
  U2[Daniel] --> R4[Support Agent]
  U3[David] --> R5[Billing Admin]
  R3 -->|inherits| R2[Engineer]
  R2 -->|inherits| R1[Employee]
  R1 --> P1[read-directory]
  R2 --> P2[deploy-service]
  R4 --> P3[read-ticket]
  R4 --> P4[issue-refund]
  R5 --> P5[edit-invoice]

Separation of duties: “not the same person”

Some combinations of access are dangerous not on their own but together. The person who can create a payment shouldn’t also approve it; the person who requests a change shouldn’t also deploy it. This is separation of duties (SoD), the centuries-old accounting principle that critical actions need more than one pair of hands, and RBAC is where identity systems encode it. It’s also exactly what Daniel’s copied access broke: issuing a refund and approving it ended up in the same hands.

Static SoD forbids the conflicting assignment. A user simply can’t be given both the Create Payment and Approve Payment roles; it’s checked when roles are assigned, and it’s the stronger, cleaner control. Dynamic SoD is more permissive: a user may hold both roles but may not activate both in the same session, so someone who legitimately wears two hats has to switch context deliberately. It’s useful in small teams where one person really does cover two functions but must never do both to a single transaction.

For regulated processes, financial reporting under SOX, payments under PCI DSS, healthcare under HIPAA, separation of duties is mandatory, and auditors test it. “Show me that no single person can both initiate and approve a wire transfer” is a routine audit question, and the clean answer is a static SoD constraint in your RBAC. Organizations that keep SoD as tribal knowledge instead of a system constraint fail those audits the moment someone quietly collects both roles, as Daniel did.

Sessions and least privilege

RBAC’s session bridges the roles a user has and the roles they’re using. When Sara starts a session she can activate some or all of her assigned roles, and only the activated roles’ permissions are available. That lets a powerful user work most of the time with a minimal role and activate an administrative role only when it’s needed, which is least privilege in time and not only in scope. It’s the same instinct behind “don’t browse the web as root” and behind just-in-time elevation in privileged access management: hold the power, but don’t carry it switched on all the time. A role you aren’t using is a role an attacker who lands in your session can’t immediately abuse.

RBAC in practice

RBAC isn’t one product; it’s the shape of access in nearly every serious system. Active Directory and LDAP groups are the classic enterprise implementation, with a user’s group memberships acting as their roles and resources granting access to groups. Cloud IAM is RBAC to the core: AWS IAM roles and managed policies, Azure role assignments over scopes, and Google Cloud IAM roles all bundle permissions and assign them to identities. Kubernetes governs the cluster with Role and ClusterRole objects bound to subjects through RoleBindings. And nearly every SaaS application ships an Admin, Member, and Viewer model, which is RBAC at its most minimal. Once you see users, roles, and permissions, a Kubernetes binding, an Azure role assignment, and an AD group stop being three unrelated systems and become three dialects of a language you already speak.

The Kubernetes dialect reads almost like the model spelled out:

# A Role = a bundle of permissions (verbs on resources)
kind: Role
metadata: { namespace: support, name: ticket-reader }
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]      # the operations
---
# A RoleBinding = a user-to-role assignment
kind: RoleBinding
metadata: { namespace: support, name: daniel-ticket-reader }
subjects:
  - kind: User
    name: daniel               # the user
roleRef:
  kind: Role
  name: ticket-reader          # the role

The Role is the permission-to-role assignment, verbs on resources, and the RoleBinding is the user-to-role assignment, a subject bound to a role. There’s deliberately no way to grant a verb directly to Daniel; Kubernetes forces every grant through a role, which is core RBAC enforced by the platform. Read an AWS IAM role or an Azure role assignment and you’ll find the same two joins under different names.

RBAC says access flows through roles, but it doesn’t say how a user gets a role. In small systems an administrator assigns roles by hand. At scale, assignment is automated by birthright rules, such as “everyone in the Sales department automatically gets the Sales Base role,” evaluated from HR attributes like department, location, and job code. Entra ID calls these dynamic groups; other platforms call them assignment rules or access policies. Attributes decide role membership here while roles still carry the permissions, which keeps the auditable role layer intact, you can still ask who’s in Sales Base and why, and removes the manual work. It’s the first place attributes and roles cooperate, and a preview of the hybrid model later in this article.

Role engineering: where the difficulty lives

The RBAC mechanism is simple; deciding what the roles should be is hard, and the discipline has a name, role engineering. There are two broad approaches, usually combined. Top-down starts from the business: interview departments, model job functions, and define roles that mirror how the organization actually works. It produces meaningful, well-named roles but is slow and can miss the messy reality of who really needs what. Bottom-up, also called role mining, starts from existing access data, analyzing the permissions people hold today and clustering them statistically into candidate roles. It’s fast and grounded in reality, but it can codify existing mistakes, as in “everyone already has this, so it must be a role,” and its roles need business names attached. Mature programs do both: mine current access to find candidates, then refine them top-down so each role maps to a real job with an owner accountable for its contents. The IGA domain has a full article on role engineering that goes into this in depth.

Role explosion: RBAC’s characteristic failure

RBAC’s great weakness follows directly from its great strength. Because a role is a fixed bundle of permissions, any variation in need tempts you to create another role. Sara needs everything an Engineer has plus read access to one finance report; do you create “Engineer plus finance report”? Do that often enough and you get role explosion: more roles than users, a catalog nobody understands, and access reviews that mean nothing because the roles no longer match understandable jobs. You’ve recreated DAC’s per-user sprawl one level up.

The root cause is that roles are blind to context. A role can’t say “read finance reports, but only for your own region, during working hours.” The moment access depends on a condition, time, location, the relationship between this user and this resource, a risk score, RBAC’s only tool is another role for each combination, and the combinations multiply. That isn’t a bug you can configure away; it’s the boundary of the model. Access that depends on attributes and context wants a different model, the subject of the next article.

Role explosion doesn’t just create clutter; it actively weakens security. When there are too many roles to understand, administrators assign the one that “definitely includes what’s needed,” which is usually broader than necessary, and reviewers approve renewals they can’t evaluate. The result is quiet, widespread over-privilege, the opposite of the least privilege RBAC was supposed to deliver.

Anti-patterns to spot

Role explosion is the famous failure, but a few others turn up so often they deserve names. The god role is a single Admin role that has accumulated every powerful permission because adding to it was easier than designing properly, the opposite of least privilege and the first thing an attacker inherits from any of its holders. The personal role has exactly one member, which means nothing was abstracted; it’s a direct grant with a new label, and a catalog full of them is DAC in disguise. Deep nesting stacks hierarchies so many layers deep that nobody can trace why a user has a permission, quietly defeating the auditability that was the point. Orphaned roles linger after the job they modeled disappears. And the copy-user request, “same access as David,” is how all of these spread: it copies one person’s accumulated history onto another instead of assigning the roles the job actually needs.

The remedy is ownership and review: every role has a named owner accountable for its contents, a clear name based on a job function rather than a project code or a person, and a periodic review that prunes it. A role catalog is a living thing, and left alone every one of these patterns grows back. Naming the smell is often what unblocks the fix, because “that’s a god role” starts a conversation that “the permissions feel off” never does.

Governance: roles across the lifecycle

RBAC is where access management meets governance, because roles are the natural unit for the joiner-mover-leaver cycle. A joiner gets a birthright bundle of roles for their department automatically. A mover has old roles removed and new ones added, the step organizations most often get wrong, producing the accumulated over-access called privilege creep, which is exactly what happened to Daniel. A leaver has all roles revoked in one action, the clean offboarding DAC couldn’t offer. Periodic access certification asks role and resource owners to confirm that each assignment is still justified, and role lifecycle management keeps the catalog itself pruned as the business changes.

That’s why RBAC and identity governance are inseparable in practice: roles are only as good as the processes that assign, review, and retire them. A perfect role model with no certification decays into privilege creep within a year, and a mediocre one with disciplined governance stays safer. Certification has its own trap, review fatigue. Hand a manager a quarterly list of hundreds of entitlements and they’ll approve the page in one click, turning the control into theater. Mature programs review roles rather than raw permissions, a handful of meaningful items instead of hundreds of cryptic ones, flag only what changed since the last review, and route each role to the owner who understands it. The point of RBAC’s indirection is fewer, more meaningful things to review, and you lose that entirely if you certify raw permissions.

The hybrid reality: roles plus rules

Very few large systems are pure RBAC, or pure anything. The dominant real-world pattern is RBAC as the baseline with attribute-based rules on top for the conditions roles can’t express. Roles establish what class of thing you may do, “Support Agent may read tickets,” and a thin layer of rules narrows it to which instances and when, “but only tickets in your queue, during your shift.” You get the auditability and org-chart legibility of roles for the coarse decision and the flexibility of attributes for the fine one, without the role explosion of pure RBAC or the opacity of pure attribute rules.

The hybrid is so common that modern access control is often described as “RBAC plus context.” AWS pairs IAM roles with condition keys and tags; Azure adds ABAC conditions to role assignments; Kubernetes complements RBAC with admission controllers. Understanding RBAC deeply isn’t superseded by the next model; it’s the foundation the next model refines. Roles answer who you are, roughly, and attributes answer whether this exact request is appropriate.

Back to the research folder

Return once more to Sara’s /research/roadmap. Under DAC she gave Daniel a per-file ACL that stayed behind when he left. Under MAC a classification blocked an unauthorized flow but said nothing about jobs. Under RBAC, access to the roadmap comes from a “Product, Roadmap Reader” role. Daniel doesn’t get a personal grant; if his job genuinely needs the roadmap, he’s assigned the role, and when he leaves support the joiner-mover-leaver process removes it automatically. “Who can read the roadmap?” now has one authoritative answer: everyone in that role. Onboarding, offboarding, and audit all come down to role membership.

But watch the boundary appear. Suppose the real rule is that support agents may read the roadmap only for the region they support, and only while they have an open ticket that refers to it. RBAC can’t express that. It would need a role per region, and it can’t represent “has an open ticket referring to this document” at all, because that depends on live data about this user and this resource right now. RBAC decides from a static fact, the set of roles you hold, which changes only when an administrator reassigns them. The region rule depends on dynamic facts, your region, the time, whether a particular ticket is open, which change constantly and belong to you and this resource, not to a role anyone could assign in advance. No amount of role design bridges a static mechanism to a dynamic question; you need a model that evaluates facts at the moment of the request.

Recap

Role-based access control is the pragmatic backbone of enterprise authorization. Access follows the job through indirection: permissions attach to roles, users are assigned roles, and effective access is the union of a user’s role permissions, which shrinks the management problem to the size of the role catalog. It’s a real standard, the NIST and INCITS 359 model with core, hierarchical, constrained, and symmetric levels. Separation of duties and sessions encode least privilege, with SoD blocking toxic combinations statically or dynamically and sessions limiting access to the roles in use right now. It’s everywhere, in AD and LDAP groups, AWS, Azure, and Google Cloud IAM, Kubernetes, and every SaaS Admin, Member, and Viewer model. And its limits are role explosion and blindness to context, so conditional access forces either an unmanageable catalog or a move to attribute-based control, and RBAC lives or dies by governance.

Three questions to test yourself

1. A startup has 30 people and 400 discretionary grants spread across its tools. Using the two RBAC assignments, explain exactly how introducing roles changes what an administrator does when the 31st employee joins and when the 5th leaves.
2. Your auditor requires that nobody can both submit and approve an expense over a threshold. Describe how you’d encode this with static and with dynamic separation of duties, and give one case where a small team would specifically need the dynamic form.
3. Give a concrete access rule RBAC can’t express without a combinatorial number of roles. Identify precisely which part of the rule is the context roles can’t capture, and name the model that can.

Hands-on exercises

1. Read real roles. In any cloud console, or a local Kubernetes cluster with kubectl get roles,rolebindings -A, find a role, list the permissions it bundles, and trace one identity through a binding to what it can actually do. Write the user-role-permission triangle for that one example.
2. Design a small role model. For a team you know, define four to six roles top-down, each named for a job, and assign permissions to them. Then introduce one requirement that tempts you toward a seventh, oddly specific role, and notice the pull toward role explosion. Decide whether to add the role or flag the requirement as a case for attribute-based rules.
3. Test a separation-of-duties constraint. Write down two roles in your environment that should never be held together, then check whether any real user holds both today. If your system supports SoD constraints, add one; if not, note how you’d detect a violation now, and how that gap would look to an auditor.