RBAC - Role-Based Access Control
About 2 min read
RBAC (Role-Based Access Control) is an access control model that manages permissions through "roles" rather than granting permissions directly to users. It was proposed by David Ferraiolo and Richard Kuhn at NIST in 1992 and standardized as ANSI/INCITS 359 in 2004. By bundling permissions into roles such as "Sales Manager," "Developer," or "Auditor" and simply assigning roles to users, it dramatically simplifies permission management in large organizations. It is a core concept of IAM and the most widely adopted implementation method for access control.
The Three Levels of the NIST RBAC Model
NIST defines RBAC at three incrementally extensible levels. You choose which level to implement based on the organization's scale and requirements.
The basic model. It consists of four elements: users, roles, permissions, and sessions. Roles are assigned to users, and permissions are linked to roles. This level is sufficient for most systems.
Introduces parent-child relationships (inheritance) between roles. A "Department Head" role automatically inherits the permissions of a "Section Manager" role. The organizational hierarchy can be mapped directly onto the role hierarchy, eliminating redundant permission definitions.
Adds Separation of Duties (SoD) constraints. By defining exclusivity constraints, such as not allowing the same user to be assigned both "Accountant" and "Approver," it structurally prevents fraud and operational errors.
Comparing RBAC, ABAC, and PBAC
RBAC is not the only access control model. It is important to compare it with attribute-based (ABAC) and policy-based (PBAC) models and choose the one that fits your requirements.
| Aspect | RBAC | ABAC | PBAC |
|---|---|---|---|
| Decision criterion | Role | Attributes of users, resources, and environment | Policy (rule engine) |
| Granularity | Coarse (per role) | Fine (combinations of attributes) | Most flexible (arbitrary conditions) |
| Ease of adoption | Easy | Moderate | Complex |
| Management cost | Proportional to the number of roles | Maintaining attribute definitions | Maintaining policy consistency |
| Suitable cases | Companies with a clear organizational structure | When dynamic conditional decisions are required | Complex business rules |
| Representative implementations | AWS IAM roles, Kubernetes RBAC | AWS IAM policy conditions, Azure ABAC | OPA (Open Policy Agent) |
In real-world systems, hybrid approaches that combine RBAC and ABAC are increasingly common. AWS IAM is a typical hybrid implementation: it has a role-based core structure to which attribute-based conditions can be added via the Condition element.
Relationship with the Principle of Least Privilege
The principle of least privilege is a fundamental security principle that states you should "grant only the minimum permissions necessary for the task." RBAC can be seen as a mechanism for realizing this principle at an organizational level. If roles are designed appropriately, the risk of granting excessive permissions to individual users can be structurally eliminated. However, if role design is too coarse, excessive permissions can arise, such as "the developer role including deletion permissions for the production environment." The granularity of role design determines the effectiveness of least privilege.
The Problem of Role Explosion
The biggest challenge of RBAC is "role explosion," where the number of roles increases explosively as the organization grows more complex. If you create roles from combinations of department × position × project × environment, hundreds to thousands of roles emerge and management breaks down.
To prevent role explosion, a hybrid approach is effective: limit the granularity of roles to "job functions" and handle distinctions of department and project through ABAC attribute conditions. Regular role reviews (auditing how roles are used and consolidating or removing unnecessary ones) are also essential.
RBAC Implementations on Major Platforms
Attach policies (JSON) to IAM roles and have users or services assume the roles (AssumeRole). Roles are also used for cross-account access.
Define operation permissions on resources with Role / ClusterRole, and bind them to users or service accounts with RoleBinding / ClusterRoleBinding. Namespace-level isolation is possible.
Combine directory roles (Global Admin, User Admin, etc.) with application-specific custom roles. PIM (Privileged Identity Management) enables Just-In-Time granting of privileged roles.
RBAC is also the foundation of zero trust architecture and is an item that is always checked in compliance audits. Please also refer to corporate password policy, startup security checklist, and zero trust security.access control books on Amazon are recommended for learning design patterns in depth.
Was this article helpful?