Role-Based Access Control (RBAC): Definition, Examples, Best Practices

RBAC grants permissions to roles, then assigns users to roles. Scales better than per-user permissions; foundational to modern IAM (AWS, K8s, SaaS apps).

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

ConceptDescription
UserAn identity (person or service)
RoleA named collection of permissions
PermissionAn action allowed on a resource
Role assignmentLinking a user to a role
Role hierarchyRoles can inherit from other roles
ConstraintsRules 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

ModelDecision basisBest for
RBACUser's role(s)Most apps; well-defined roles
ABACAttributes (user, resource, env)Fine-grained, dynamic policies
ACLPer-resource user permissionsFew resources, ad-hoc access
PBACCentralized policy engineModern, decoupled from app

RBAC in major systems

SystemRBAC implementation
AWS IAMRoles + managed policies
KubernetesRoles, ClusterRoles, RoleBindings
Azure RBACBuilt-in + custom roles
Google Cloud IAMPredefined roles + custom roles
GitHubOrg/repo roles + teams
SlackWorkspace roles + channel roles
SalesforceProfiles + 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.io

RBAC 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.

How fast is your website?

Elevate its speed and SEO seamlessly with our Free Speed Test.

Free Website Speed Test

Analyze your website's load speed and improve its performance with our free page speed checker.

×