Loading...
Permissions assigned to roles, roles assigned to people. Simple, auditable, scalable.
Quick Definition
Role-based access control (RBAC) grants permissions based on a user's role rather than to individuals directly. Common in Kubernetes and cloud IAM, RBAC simplifies access management, enforces least privilege, and supports security and compliance at scale.
Role-Based Access Control, or RBAC, is the model where permissions attach to roles, developer, auditor, billing administrator, and people or services receive roles rather than individual permissions. Managing access becomes managing a short list of roles instead of thousands of one-off grants.
RBAC is how IAM stays sane at scale. When someone joins a team, they get the team's role; when they leave, it is removed; when the role itself changes, everyone holding it updates at once. Audits become tractable: instead of reviewing every user's unique permission soup, you review a dozen role definitions.
Example. An auditor asks who can modify production billing settings. With RBAC, the answer is one role with four members, produced in a minute. Without it, the answer is a week of spreadsheet archaeology across individual grants.
RBAC also scopes spending power: roles define who can create expensive resources and where, making it a quiet cost guardrail. Keep roles few and reviewed; role sprawl recreates the original mess. The cloud security overview places RBAC in the broader control picture.
As few as reflect real job functions, often a dozen or two. Hundreds of micro-roles defeat the purpose.
Uncontrolled growth of overlapping roles until nobody knows what grants what. Scheduled review and consolidation prevent it.
Roles are the vehicle: each role carries the minimum permissions its function needs, and people hold only the roles they need.