What Is Azure RBAC?
Azure role-based access control (RBAC) is an authorization system built on Azure Resource Manager that lets you grant precisely the permissions a user, group, service principal, or managed identity needs to perform a job — no more, no less — by combining a role definition (a set of allowed actions) with a security principal and a scope, forming a role assignment that Azure evaluates on every resource operation.
Cricket analogy: It's like the ICC granting a match referee authority to enforce rules only during matches they're officially assigned to, not every match happening worldwide — the role (referee), the person, and the scope (that specific fixture) together define what they can actually do.
Role Definitions and Scope
A role definition is a collection of permissions such as Microsoft.Compute/virtualMachines/start/action, expressed as Actions (management-plane permissions), DataActions (data-plane permissions like reading blob contents), and NotActions/NotDataActions (explicit exclusions); scope determines where that role applies and forms a hierarchy — management group, subscription, resource group, or individual resource — with permissions inherited downward from broader scopes to narrower ones.
Cricket analogy: Scope inheritance is like a national cricket board's authority cascading down: rules set at the country level (management group) apply to every state association (subscription), which apply to every district league (resource group), down to an individual club (resource), unless a narrower level adds its own specific rule.
Built-in Roles vs Custom Roles
Azure provides broad built-in roles like Owner (full access including granting access to others), Contributor (full access except granting access), and Reader (view-only), plus resource-specific built-in roles like Storage Blob Data Contributor; when built-in roles don't fit precisely, you can author a custom role in JSON defining exact allowed and denied actions and the scopes where it can be assigned.
Cricket analogy: Built-in roles are like standard cricket positions (captain, vice-captain, twelfth man) with well-understood responsibilities, while a custom role is like a team inventing a specialized 'death-overs specialist' contract with bespoke terms not covered by any standard designation.
{
"Name": "VM Operator",
"IsCustom": true,
"Description": "Can start and restart VMs but not delete them",
"Actions": [
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/read"
],
"NotActions": [],
"AssignableScopes": [
"/subscriptions/11111111-2222-3333-4444-555555555555"
]
}Azure RBAC assignments can target four kinds of security principals: users, groups, service principals (for apps), and managed identities (for Azure resources needing credential-free access) — assigning roles to groups rather than individual users is a best practice that simplifies access reviews at scale.
Least Privilege and Deny Assignments
The principle of least privilege means assigning the narrowest built-in or custom role at the narrowest necessary scope — for example, Storage Blob Data Reader on a single container rather than Contributor on the whole subscription — and Azure Blueprints or Azure Policy can enforce deny assignments that block specific actions even for users who would otherwise have permission through RBAC, which take precedence over any role assignment.
Cricket analogy: This is like giving a substitute fielder permission only to field in the deep, never to bowl or bat, rather than granting them full playing-XI privileges — and a ground rule banning short-pitched bowling overrides even the captain's tactical wishes.
Assigning the Owner role at the subscription scope grants the ability to modify RBAC assignments for everyone else in that subscription — a very common over-privileging mistake — always prefer Contributor plus a narrowly scoped custom role, or resource-group-level assignments, unless subscription-wide access management is genuinely required.
- Azure RBAC combines a role definition, a security principal, and a scope into a role assignment.
- Scope forms a hierarchy: management group, subscription, resource group, resource; permissions inherit downward.
- Built-in roles like Owner, Contributor, and Reader cover most common needs.
- Custom roles are authored in JSON with precise Actions, NotActions, and AssignableScopes.
- Roles can be assigned to users, groups, service principals, and managed identities.
- Least privilege means the narrowest role at the narrowest scope necessary.
- Deny assignments (via Blueprints/Policy) take precedence over any RBAC role assignment.
Practice what you learned
1. What three components make up an Azure RBAC role assignment?
2. Which built-in role grants full access to resources but NOT the ability to grant access to others?
3. How does scope inheritance work in Azure RBAC?
4. What takes precedence over any RBAC role assignment, even for a user with Owner permissions?
5. Which type of security principal allows an Azure resource to authenticate without storing credentials?
Was this page helpful?
You May Also Like
Azure Active Directory (Entra ID)
Microsoft's cloud-based identity and access management service, renamed Microsoft Entra ID, covering tenants, users, groups, app registrations, and conditional access.
Azure Key Vault Basics
Azure's managed service for securely storing and accessing secrets, keys, and certificates, covering access models, managed identities, and rotation.