Role-Based Access Control (RBAC)
RBAC is like a keycard system in an office building. Instead of giving each employee individual access to specific doors, you assign them a role (engineer, manager, security guard) and each role has predefined access. All engineers can enter the lab; all managers can enter the conference rooms; only security guards can enter the server room. When someone changes jobs, you change their role instead of updating dozens of individual permissions.
Role-Based Access Control (RBAC) assigns permissions to roles rather than individual users. Users are assigned one or more roles, and inherit all permissions associated with those roles. Defined in NIST INCITS 359-2004.
RBAC components:
- User: a person or service account
- Role: a named collection of permissions (e.g., “admin”, “editor”, “viewer”)
- Permission: an allowed action on a resource (e.g., “read:documents”, “write:users”, “delete:logs”)
- Session: the active mapping of a user to their current roles
RBAC principles:
- Least privilege: assign the minimum role necessary for the job function
- Separation of duties: no single role should have permissions that create a conflict of interest (e.g., the person who approves expenses should not also process payments)
- Role hierarchy: senior roles inherit permissions from junior roles (admin inherits viewer permissions)
RBAC vs. other models:
| Model | Approach | Best for |
|---|---|---|
| RBAC | Roles with fixed permissions | Organizations with defined job functions |
| ABAC (Attribute-based) | Dynamic rules based on user/resource/environment attributes | Complex, context-dependent policies |
| ACL (Access Control List) | Per-resource lists of allowed users | Simple systems, file systems |
| ReBAC (Relationship-based) | Permissions based on object relationships | Document sharing (Google Docs model) |
RBAC implementation patterns
# Kubernetes RBAC: define a role and bind it to a user
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: production
name: read-pods
subjects:
- kind: User
name: mokey
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io# AWS IAM: check what permissions a role has
$ aws iam list-attached-role-policies --role-name WebServerRole
{
"AttachedPolicies": [
{ "PolicyName": "AmazonS3ReadOnlyAccess" },
{ "PolicyName": "CloudWatchLogsFullAccess" }
]
}RBAC is the dominant access control model in enterprise IT. AWS IAM, Kubernetes, Azure AD, GitHub, and every major SaaS product implement RBAC. A typical organization defines roles like: viewer (read-only), editor (read-write), admin (full access), and security-auditor (read all, modify nothing). The most common RBAC mistake is role explosion: creating too many fine-grained roles that become unmanageable. The second most common is overly permissive defaults: giving everyone admin because “it is easier.” Compliance frameworks (SOC 2, HIPAA, PCI-DSS) require documented access control policies, regular access reviews, and least-privilege enforcement, all of which RBAC enables. When onboarding or offboarding employees, RBAC reduces the process to adding or removing role assignments rather than auditing individual permissions.