Azure RBAC: Role-Based Access Control Explained

What is Azure RBAC?

Azure RBAC is an authorization system built into Azure Resource Manager. It answers one question at every API call: “Does this security principal have permission to perform this action on this resource?”

Before RBAC existed, Azure used a much cruder system — you were either a subscription co-administrator (which meant you could do almost anything) or you had no access at all. RBAC replaced that with fine-grained control. Today Azure has over 300 built-in roles, and you can define your own custom roles on top of those.

Every role assignment is made of exactly three things working together:

• Security principal — the identity that needs access (a user, a group, a service principal, or a managed identity)
• Role definition — the collection of permissions that specifies what actions are allowed or denied
• Scope — the boundary within which the role applies (a management group, subscription, resource group, or individual resource)

A role assignment is simply the binding of these three things: “This security principal has this role at this scope.” Nothing more, nothing less.

How Azure RBAC is enforced

Every request to Azure goes through Azure Resource Manager (ARM). Before ARM executes any request, it checks the requester’s identity, collects all of their role assignments across every applicable scope, and determines whether the requested action is in any of those role definitions.

The enforcement is additive for allow permissions — permissions from multiple role assignments stack together. However, explicit deny assignments override everything. If a deny assignment blocks an action, it wins regardless of any allow permissions the principal has. Deny assignments are uncommon and typically applied by Azure Blueprints or Azure Policy, but you should be aware they exist.

This enforcement happens at the ARM level, which means it applies to everything you do through the Azure portal, the Azure CLI, PowerShell, REST APIs, Terraform, and any other tool that talks to ARM. You cannot bypass RBAC by using a different tool.

Understanding scope in RBAC

Scope defines where a role assignment applies. Azure has four scope levels, from broadest to narrowest:

1. Management group — a container for multiple subscriptions, used in large organizations
2. Subscription — the billing boundary and the most common top-level scope for role assignments
3. Resource group — a logical container for related resources within a subscription
4. Resource — a single Azure resource, such as a specific VM or storage account

Assignments at a higher scope flow down to every scope beneath it. If you assign Contributor to a user at the subscription level, that user is a Contributor on every resource group and every resource in that subscription. If you only assign Contributor on a single resource group, the user can only act within that resource group.

This inheritance makes scope a powerful tool. For teams, assigning roles at the resource group level is generally the right choice — it gives them what they need without giving them access to unrelated parts of the subscription. See RBAC policy structure for a detailed look at how scope inheritance works in practice.

The three core built-in roles

Azure has over 300 built-in roles, but three of them form the foundation that most teams start with:

Owner

Owner has full control: they can create, modify, and delete any resource, and they can also manage access — meaning they can assign roles to other users. Owner is a powerful role that should be granted sparingly. In most organizations, only a handful of people should be Owners at the subscription level, and those should be accounts used for administration rather than day-to-day work.

Contributor

Contributor can create, modify, and delete resources, but they cannot manage access. A developer or DevOps engineer who needs to deploy and configure infrastructure typically gets Contributor on the resource group they work in. The key distinction from Owner: a Contributor cannot grant themselves or anyone else additional permissions.

Reader

Reader can view resources and their configurations but cannot make any changes. This is appropriate for auditors, security reviewers, or anyone who needs visibility without the ability to modify anything. Reader is also useful as a baseline role for on-call engineers who primarily need to see what is deployed.

For most real workloads, you will quickly move beyond these three roles. Azure provides service-specific roles like Storage Blob Data Reader, Key Vault Secrets User, and Virtual Machine Contributor that give precise access to specific services. See built-in vs custom roles for a deeper look at which roles to choose for different situations.

Worked example: assigning Reader to a team member

Here is a realistic scenario: a new security auditor has joined your organization and needs read-only access to the production-app resource group so they can review what is deployed. They should not be able to change anything.

Step 1: Get the user’s object ID

You need the user’s object ID from Microsoft Entra ID. If you know their email, you can look it up:

az ad user show \
  --id "auditor@yourcompany.com" \
  --query id \
  --output tsv

This returns something like a1b2c3d4-e5f6-7890-abcd-ef1234567890. Save this as the assignee object ID.

Step 2: Assign the Reader role at resource group scope

az role assignment create \
  --assignee "a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
  --role "Reader" \
  --scope "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/production-app"

The —scope parameter is the full ARM resource ID of the resource group. You can also use —resource-group production-app as a shorthand when working at resource group scope, which makes the command slightly shorter:

az role assignment create \
  --assignee "a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
  --role "Reader" \
  --resource-group "production-app"

Step 3: Verify the assignment was created

az role assignment list \
  --assignee "a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
  --resource-group "production-app" \
  --output table

You should see a table row showing the Reader role assigned to your auditor at the production-app scope.

What the auditor can and cannot do

With this assignment, the auditor can:

• List all resources inside production-app in the portal or with the CLI
• View configuration details for VMs, storage accounts, databases, and other resources
• Read resource tags and metadata
• View activity logs for resources in that resource group

The auditor cannot:

• Start, stop, or restart any VM
• Read the contents of blobs in a storage account (Reader is management-plane only — data-plane access requires a separate role like Storage Blob Data Reader)
• Read secret values from Key Vault (same data-plane limitation)
• See resources in any other resource group in the subscription
• Assign roles to anyone else

Security principals: users, groups, service principals, managed identities

Role assignments apply to any security principal, not just human users. Understanding the different types helps you design access correctly.

Users

Individual accounts in Microsoft Entra ID. Assigning roles directly to users is convenient but creates maintenance problems as people join and leave teams. Prefer groups where possible.

Groups

Microsoft Entra ID groups let you assign a role once and then control who gets it by managing group membership. This is much easier to maintain at scale — when a developer joins the team, you add them to the group rather than creating a new role assignment.

Service principals

Application identities used by software — CI/CD pipelines, automation scripts, and third-party applications. Service principals authenticate with a client secret or certificate. See service principals explained for the full details on creating and managing them.

Managed identities

Azure-managed identities for resources running inside Azure. When a VM or App Service has a managed identity, it can authenticate to other Azure services without any credentials in code or configuration. This is the preferred approach for any workload running in Azure. See managed identities overview for more.