Role-Based Access Control (RBAC)

What is role-based access control (RBAC)?

Role-based access control (RBAC) is an access control model where permissions are attached to roles such as admin, editor or viewer, and people get access by being assigned a role. To change what a whole group can do, you edit one role instead of hundreds of accounts. NIST credits the formal model to Ferraiolo and Kuhn in 1992, and it became ANSI/INCITS 359-2004.

RBAC answers the authorization question, what may this identity do, after authentication has answered who it is. It is one of the models used inside identity and access management (IAM). Single sign-on (SSO) decides who signs in; RBAC decides what they can do afterwards.

Core concepts

Example: a SaaS app

# 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]

# Role assignments
alice@example.com: [admin]
bob@example.com: [editor, billing-manager]
carol@example.com: [viewer]

Bob can edit content and manage billing because he holds two roles. When a new editor joins, you assign one role and the permissions follow.

Example: Kubernetes

Kubernetes ships RBAC as an API group. A Role lists which verbs are allowed on which resources, and a RoleBinding grants that Role to users, groups or service accounts. This Role from the Kubernetes documentation allows reading pods in the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Two details from the docs matter in practice. A Role is always scoped to one namespace, while a ClusterRole is not. And permissions are purely additive: there are no deny rules, so a user's access is the union of every role they hold.

RBAC vs ABAC vs ACL

RBAC is enough while permissions depend on what someone does, not on the data in front of them. When rules depend on department, region or time of day, add attribute-based checks. An access control list (ACL) attaches permissions to each resource, which is flexible but hard to audit at scale.

RBAC best practices

• Least privilege. Give each role only what the job function needs.
• Separation of duties. Make sensitive actions require two roles, such as requester and approver.
• Assign through groups. Attach roles to groups, not individual users, so offboarding is one change.
• Name roles after functions. Job titles change, functions last longer.
• Document each role. Write down what it is for, who should hold it and who reviews it.
• Limit full-admin accounts. Many people with full access is a risk in itself.
• Grant elevated access temporarily. Remove it automatically when the task is done.
• Review and log. Audit assignments on a schedule and keep a record of who granted which role and when.

Common mistakes

• Role explosion. Roles multiply as the organization grows until nobody knows what they all do. Consolidate regularly.
• Permission creep. Roles collect permissions over time. Strip what is unused.
• Too few roles. One generic user role leaves everyone over- or under-privileged.
• Forgotten assignments. A former employee who still holds admin means offboarding is broken.
• Hard-coded role checks. if user.role == 'admin' scattered through the code is painful to change. Check permissions, not role names.
• Mixing roles with ad-hoc ACLs. Half RBAC is confusing to audit. Pick one model per resource.

RBAC in LoadFocus teams and API testing

LoadFocus teams use a small version of RBAC. When you invite a member, you choose between Admin, who can run, edit and view tests, and View-only, who can only view them, and you can limit an invitation to specific products such as load testing, JMeter or API monitoring. That covers the common split of engineers running tests and stakeholders reading results. See the teams guide for the steps.

When you test an API that has role-based permissions, test with a credential for each role. An admin token and a viewer token can reach different code paths and show different latency under load, and a failing permission check should return a clean 403, not a 500. Machine access usually goes through an API key; see API security and our guide to API performance testing with OAuth2 for authenticated runs, and API monitoring to keep checking protected endpoints after release.

FAQ

RBAC vs ABAC: which should I use?

Use RBAC when permissions follow stable job functions, which covers most applications. Use ABAC when access depends on attributes such as department, region or time. Many systems combine both: roles for the broad strokes, attributes for the exceptions.

Can a user have more than one role?

Yes. In most RBAC systems a user can hold several roles. In Kubernetes, permissions are additive, so the user gets the union of all roles with no way to subtract.

What is role explosion?

It is what happens when you create a new role for every exception until there are too many to understand or audit. It is usually a sign you need attribute-based rules for the exceptions or a cleanup of overlapping roles.

Does RBAC replace authentication?

No. Authentication proves who someone is, RBAC decides what that identity may do. You need both.

What roles do LoadFocus teams have?

Team members are invited as Admin, who can run, edit and view tests, or View-only, who can only view tests. You can also limit a member to specific LoadFocus products.