What is Role-Based Access Control (RBAC)?
Role-Based Access Control (RBAC) is an access control model where permissions are granted to roles (e.g., "admin", "editor", "viewer"), and users are assigned roles. Instead of granting permissions to each user individually, you grant them to roles, then put users into roles. New employees just get the right role; permissions follow automatically.
RBAC is the foundation of modern IAM. AWS IAM, Kubernetes RBAC, GitHub teams, Slack roles, and most SaaS apps use it. It scales better than per-user permissions and is easier to audit.
RBAC core concepts
| Concept | Description |
|---|---|
| User | An identity (person or service) |
| Role | A named collection of permissions |
| Permission | An action allowed on a resource |
| Role assignment | Linking a user to a role |
| Role hierarchy | Roles can inherit from other roles |
| Constraints | Rules limiting role assignment (e.g., separation of duties) |
Example: SaaS app RBAC
# Roles
admin: [users.create, users.delete, billing.view, billing.edit, settings.edit]
editor: [content.create, content.edit, content.publish]
viewer: [content.view]
billing-manager: [billing.view, billing.edit]
# User assignments
alice@example.com: [admin]
bob@example.com: [editor, billing-manager]
carol@example.com: [viewer]RBAC vs ABAC vs ACL
| Model | Decision basis | Best for |
|---|---|---|
| RBAC | User's role(s) | Most apps; well-defined roles |
| ABAC | Attributes (user, resource, env) | Fine-grained, dynamic policies |
| ACL | Per-resource user permissions | Few resources, ad-hoc access |
| PBAC | Centralized policy engine | Modern, decoupled from app |
RBAC in major systems
| System | RBAC implementation |
|---|---|
| AWS IAM | Roles + managed policies |
| Kubernetes | Roles, ClusterRoles, RoleBindings |
| Azure RBAC | Built-in + custom roles |
| Google Cloud IAM | Predefined roles + custom roles |
| GitHub | Org/repo roles + teams |
| Slack | Workspace roles + channel roles |
| Salesforce | Profiles + permission sets |
Kubernetes RBAC example
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: alice-pod-reader
namespace: production
subjects:
- kind: User
name: alice@example.com
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioRBAC best practices
- Least privilege. Roles grant only what's needed for the job function.
- Separation of duties. Sensitive actions require multiple roles (e.g., approver vs requester).
- Limit role count. 10-30 roles is manageable; 200+ becomes ABAC-in-disguise.
- Use role hierarchy carefully. Inheritance is powerful but easy to misuse.
- Audit role assignments quarterly. Revoke unused; right-size over-privileged.
- Document each role. What it's for; who should have it; review owner.
- Avoid "super admin" sprawl. Many people with full access = high risk.
- Use groups for assignment. Manage role assignments via groups, not individual users.
- Just-in-Time elevation. Grant admin temporarily; auto-revoke after task.
- Log role changes. Audit trail of who got what role and when.
Common RBAC pitfalls
- Role explosion. Org grows; roles proliferate; no one knows what they all do. Audit + consolidate.
- Permission creep. Roles accumulate permissions over time. Strip unused.
- Too few roles. One "user" role; everyone is over-privileged or under-privileged.
- Roles tied to job titles. Job titles change; roles should map to function not title.
- Forgotten role assignments. Former employee still has admin; offboarding broken.
- Role-based but using ACLs underneath. Half-RBAC = confusing; pick one.
- No audit trail. Don't know who granted what role to whom.
- Hardcoded role checks.
if user.role == 'admin'spread across code; refactor when role changes.
RBAC vs other authorization patterns
When RBAC is enough
- Predictable roles (admin/editor/viewer)
- Permissions don't depend on resource attributes
- 10-50 distinct roles fit your org
When you need ABAC instead (or in addition)
- Permissions depend on attributes (department, region, time-of-day)
- Multi-tenant SaaS where users belong to specific orgs
- Fine-grained: "Alice can edit docs in her department"
- Need to express conditional access ("only during business hours")
FAQ: RBAC
RBAC vs ABAC: which to use?
RBAC for clear, stable roles (most apps). ABAC for fine-grained, attribute-dependent permissions. Many systems combine both.
How many roles is too many?
If you can't list them all from memory, you have too many. Aim for 10-30; 200+ usually means RBAC isn't the right fit and ABAC would help.
Should I use Kubernetes RBAC or a service mesh?
Both. K8s RBAC controls API access. Service mesh (Istio) controls service-to-service traffic.
What's role hierarchy?
Roles can inherit from other roles. "Senior Editor" inherits from "Editor" + adds permissions. Powerful but complex; use sparingly.
How do I migrate from ACLs to RBAC?
Identify common access patterns; group them into roles; assign users to roles; deprecate ACLs gradually.
Are roles same as groups?
Sometimes used interchangeably. Strictly: groups = collections of users; roles = collections of permissions. RBAC links them.
How does RBAC relate to SSO?
SSO authenticates (proves identity); RBAC authorizes (decides what authenticated users can do). Independent but complementary.
Test RBAC-protected APIs with LoadFocus
LoadFocus runs JMeter and k6 scripts that simulate users with different roles, helping verify RBAC + rate limits work under load. Sign up free at loadfocus.com/signup.
Related LoadFocus Tools
Put this concept into practice with LoadFocus — the same platform that powers everything you just read about.