RBAC
Definition
Role-Based Access Control - a security approach that assigns permissions based on job roles, enhancing security and simplifying management.
Use Cases
- Netflix: Controlling access to AWS resources for many engineering teams while reducing the risk of overly broad permissions. — Netflix uses AWS IAM with role-based permissions and federated access (SSO) so engineers assume roles aligned to job function (e.g., read-only, developer, admin) rather than receiving long-lived, user-specific permissions. (More consistent access management across teams, reduced operational overhead for onboarding/offboarding, and improved security posture by standardizing permissions through roles.)
- Spotify: Managing access to Google Cloud projects and resources across multiple squads and environments (dev/test/prod). — Spotify uses Google Cloud IAM to grant predefined and custom roles to groups at the project or resource level, aligning permissions to team responsibilities and separating production access from non-production access. (Faster access provisioning for teams, clearer separation of duties between environments, and easier auditing of who can do what via role bindings.)
- Adobe: Enforcing least-privilege access to Azure resources across large enterprise teams. — Adobe uses Azure RBAC to assign built-in and custom roles to Entra ID groups at subscription/resource-group scopes, combined with privileged access workflows for elevated roles. (Reduced standing administrative access, improved compliance reporting through centralized role assignments, and more scalable access governance as teams grow.)
Provider Equivalents
- AWS: AWS Identity and Access Management (IAM)
- Azure: Microsoft Entra ID (Azure AD) + Azure role-based access control (Azure RBAC)
- GCP: Google Cloud IAM
- OCI: OCI Identity and Access Management (IAM)
Frequently Asked Questions
- What's the difference between RBAC and ABAC (Attribute-Based Access Control)?
- RBAC grants access based on a user's role (for example, "Developer" or "Billing Admin"). ABAC grants access based on attributes and rules (for example, department=Engineering AND environment=Dev AND resourceTag=team-a). RBAC is usually simpler to manage; ABAC can be more flexible when you need fine-grained, policy-driven access at scale.
- When should I use RBAC?
- Use RBAC when you have repeatable job functions and want consistent, auditable permissions (for example, standard roles for developers, operators, and auditors). It’s especially useful for onboarding/offboarding, enforcing least privilege, and separating duties (e.g., read-only audit roles vs. admin roles). If you frequently need exceptions based on resource tags, time, or other conditions, consider combining RBAC with conditional policies (ABAC-style conditions) where your cloud supports it.
- How much does RBAC cost?
- RBAC itself is typically included as part of the cloud provider’s IAM service and does not have a separate per-role fee. Costs may come indirectly from related services such as identity providers/SSO licensing (e.g., enterprise identity features), privileged access management tools, audit logging (e.g., CloudTrail/Cloud Audit Logs), and the operational effort to design and maintain roles.
Category: security
Difficulty: intermediate
Related Terms
See Also