Azure built-in roles explained: Owner, Contributor, Reader and what to use instead

Azure has hundreds of built-in roles, but most tenants lean on three: Owner, Contributor and Reader. They're easy to assign and they always work, which is exactly the problem. This guide explains how Azure roles fit together, so you can pick the smallest one that does the job.

Azure roles aren't Entra roles

There are two separate role systems, and mixing them up causes a lot of confusion:

• Azure roles (Azure RBAC) control access to Azure resources: subscriptions, resource groups, VMs, storage accounts, key vaults.
• Microsoft Entra roles control access to the directory: users, groups, apps, Conditional Access. Global Administrator is an Entra role.

Being Global Administrator doesn't give you access to Azure resources by default, and being Owner of a subscription doesn't let you manage users. This site has pages for both: Azure roles and Entra roles.

Three things decide what a role assignment can do

1. The role: a list of allowed actions and not actions, such as Microsoft.Compute/virtualMachines/start/action.
2. The scope: where it applies. That can be a management group, subscription, resource group or single resource. Access is inherited downwards, so Owner on a subscription is Owner on everything in it.
3. The principal: who gets it, whether a user, group, service principal or managed identity.

Roles also separate the control plane (managing the resource, through Actions) from the data plane (the data inside it, through DataActions). Contributor can manage a storage account but can't read the blobs inside it through Entra ID authentication. That needs a data role such as Storage Blob Data Reader or Contributor.

The five privileged roles

Microsoft groups five built-in roles as privileged administrator roles. In Microsoft's words:

The ones that can grant access (Owner, User Access Administrator and Role Based Access Control Administrator) are the most dangerous, because anyone holding them can give themselves or anyone else any other role.

Owner, Contributor, Reader: the differences

• Owner can do everything, including assigning roles. Keep it to a handful of people per subscription, ideally as eligible assignments in PIM. See Owner vs Contributor.
• Contributor can create, change and delete any resource but can't grant access. It's still very broad: a Contributor can delete production. See Contributor vs Reader.
• Reader can view everything but change nothing. It's fine for auditors and dashboards. Monitoring Reader is smaller if they only need monitoring data.

If someone needs to assign roles but shouldn't be Owner, use Role Based Access Control Administrator instead of User Access Administrator. Its description says it manages access "by assigning roles using Azure RBAC" only, and Microsoft lets you add conditions to role assignments to limit which roles it can assign.

Pick a smaller role

For most jobs there's a built-in role far smaller than Contributor:

• Managing networks: Network Contributor
• Logging in to VMs: Virtual Machine User Login or Administrator Login
• Reading secrets from a key vault: Key Vault Secrets User
• Log Analytics: Log Analytics Reader or Contributor

The least-privilege role finder searches every built-in role for the actions you need and suggests the smallest match.

Find who has the big roles

With Azure PowerShell, list every Owner and User Access Administrator on a subscription, including inherited assignments:

1
2
3
4
5
6Connect-AzAccount
$sub = "/subscriptions/00000000-0000-0000-0000-000000000000"
foreach ($role in "Owner", "User Access Administrator", "Role Based Access Control Administrator") {
    Get-AzRoleAssignment -Scope $sub -RoleDefinitionName $role |
        Select-Object @{ n = "Role"; e = { $role } }, DisplayName, SignInName, ObjectType, Scope
}

Or with the Azure CLI, across every subscription you can see:

1
2az role assignment list --all --role Owner --include-inherited \
    --query "[].{who:principalName, type:principalType, scope:scope}" -o table

Checklist

• Keep Owner and the access-granting roles to as few people as possible, and make them eligible in PIM.
• Assign roles to groups, not individuals, so access is reviewed in one place.
• Assign at the smallest scope that works: a resource group, not the subscription.
• Replace Contributor with a resource-specific role wherever one exists.
• Remember data roles: control-plane roles don't automatically give access to the data inside.