Role-Based Access Control (RBAC)
Also known as:
1. Overview
Role-Based Access Control (RBAC) is a pattern for building resilient value creation systems.
Problem: Managing permissions for a large number of individual users is complex, error-prone, and does not scale. Granting permissions directly to users makes it difficult to have a clear overview of who has access to what, to enforce the principle of least privilege, and to update permissions when a user’s job function changes. This often leads to users accumulating excessive permissions over time.
Context: You are designing an authorization system for an application or infrastructure with multiple users and a variety of resources. You need a scalable and manageable way to control who can access which resources and perform which actions.
2. Core Principles
Implement Role-Based Access Control (RBAC), an access control model where permissions are assigned to roles, and users are then assigned to roles. Instead of managing individual user permissions, you manage a smaller and more stable set of roles.
The model consists of three main components:
- Permissions: The ability to perform a specific action on a specific resource (e.g., “read” access to “file_X”, “write” access to “database_Y”).
- Roles: A collection of permissions that represents a specific job function or level of authority (e.g., “database_administrator”, “marketing_analyst”, “read_only_viewer”).
- Users: Individuals who are assigned one or more roles.
A user’s effective permissions are the sum of all permissions granted to all the roles they are assigned.
3. Rationale
RBAC provides a more structured and scalable approach to authorization. It:
- Simplifies Administration: Administrators manage a small number of roles instead of a large number of individual user permissions.
- Enforces Least Privilege: Roles can be designed to grant only the permissions necessary for a specific job function.
- Improves Auditing: It is much easier to review and audit role definitions and assignments than to audit the permissions of every single user.
- Scales with the Organization: When a new user joins, you simply assign them the appropriate role. When a user changes jobs, you just change their role assignment.
4. Consequences
- Positive:
- A dramatic simplification of permission management.
- A more secure and auditable authorization system.
- A model that scales effectively as the number of users and resources grows.
- Negative:
- Can be inflexible for very fine-grained access control needs, which might require a more attribute-based model (ABAC).
- Requires a careful and well-planned design of the roles to be effective. Poorly designed roles can lead to “role explosion” or roles with excessive permissions.
5. Application Context
Best Used For:
- Value creation systems requiring strong privacy and security foundations
- Organizations operating in regulated environments
- Systems handling sensitive data or requiring high trust
6. Known Uses
- Kubernetes: Has a built-in RBAC API for controlling access to the Kubernetes API.
- Cloud Platforms: AWS IAM, Azure RBAC, and Google Cloud IAM all use RBAC as their primary authorization model.
- Databases: Most modern databases provide RBAC features for managing access to data.