Manage Access to Azure Resources: Azure RBAC (AZ-104)

Azure role-based access control (Azure RBAC) is the authorization system built on Azure Resource Manager that controls access to Azure resources — virtual machines, storage accounts, virtual networks, resource groups, subscriptions, and everything else you manage. Authentication (proving who you are) is handled by Microsoft Entra ID; authorization (deciding what you are allowed to do) is handled by Azure RBAC. The two work together every time someone opens the portal or calls the Azure API.

RBAC follows the principle of least privilege: you grant each person, group, or application only the permissions they need, at only the scope they need, rather than making everyone an administrator. You do this by creating role assignments, and you manage them from the Access control (IAM) blade that appears on every management group, subscription, resource group, and resource.

The mechanism is deliberately simple to reason about: a role is a named bundle of allowed actions, and assigning that role to someone at a scope grants them those actions across everything in that scope. Because assignments are additive and inherited, most access questions are really questions about which roles apply at which scope — the subject of the rest of this lesson.

Every Azure role assignment is built from three required elements — security principal, role definition and scope — plus an optional condition. Together they answer who can do what and where.

• Security principal (the who) — the identity being granted access: a user, a group, a service principal (an application identity, for example an external CI/CD pipeline), or a managed identity (an identity Azure manages for a resource such as a VM or function app, so no credential is stored in code). Assigning to a group is best practice, so access follows group membership.
• Role definition (the what) — a named collection of permissions: Actions and NotActions for management (control-plane) operations, and DataActions and NotDataActions for operations on data, such as reading a blob.
• Scope (the where) — one of four levels: management group, subscription, resource group, or a single resource.
• Condition (optional) — an attribute-based rule that narrows the assignment further, for example limiting which roles a delegate may assign.

One assignment binds one principal to one role at one scope. If a group needs the same role on two unrelated resource groups, that is two assignments (or one assignment at a common parent, if granting the whole parent is acceptable). You create assignments on the Access control (IAM) blade with Add role assignment: pick the role, pick the members, and the scope is wherever you started.

Managed identities as principals

Either type is a security principal you grant roles to like any user. With a user-assigned identity you make the role assignment once and every resource that uses the identity gets it, so recreating resources does not mean recreating assignments.

Five core built-in roles decide who can manage resources and who can manage access to them. Microsoft classes all of them except Reader as privileged administrator roles, because they can manage resources or grant access broadly. The dividing line is permission to write to Microsoft.Authorization, the provider that holds role assignments, role definitions, resource locks and policy assignments.

Owner versus Contributor is the classic distinction. Both can fully create, change and delete resources, but only Owner can grant roles to others. Because Contributor's exclusion covers every write and delete under Microsoft.Authorization, a Contributor also cannot create or remove resource locks or policy assignments — those are authorization objects too, not ordinary resources.

User Access Administrator and Role Based Access Control Administrator both manage access without touching workloads. The difference is breadth: User Access Administrator holds Microsoft.Authorization/* (so it can also manage custom role definitions), while Role Based Access Control Administrator can only create and delete role assignments, which makes it the least-privileged built-in role for managing assignments. It is also the role you constrain with a condition (see Delegating access management). Reader grants view-only access with no changes at all.

Job-function built-in roles grant management of one service area, and they are the least-privilege choice whenever someone's work is limited to that area. Contributor covers every resource type; a job-function role covers only its own.

Keep two separate questions apart. Managing the VM resource (an Azure control-plane operation) is Virtual Machine Contributor or broader. Signing in to the VM's operating system with Entra ID is a login role, which is a data action — Virtual Machine Contributor and even Owner do not include it. A help-desk engineer who must restart VMs but never touch networking needs Virtual Machine Contributor; a developer who must only log on needs Virtual Machine User Login.

Before reaching for a custom role, search the built-in list for a near match and read its actions: a role whose name sounds right can carry extra permissions. For example, Desktop Virtualization Power On Off Contributor can start and stop VMs, but it also writes Azure Virtual Desktop host pool settings, alert rules and deployments — fine for its intended job, too broad if the requirement is "start and stop VMs and nothing else".

Azure RBAC has two separate permission planes. Actions govern the control plane — managing the resource itself (create a storage account, change a firewall rule). DataActions govern the data plane — the contents (read a blob, get a secret value). Owner, Contributor and Reader contain no DataActions, so none of them, on their own, lets a user read data through Microsoft Entra ID.

Blob storage

• Storage Blob Data Reader / Contributor / Owner grant read, read-write and full (including POSIX ACL) access to blob data through Entra ID.
• Tools that call the blob data plane directly with Entra sign-in — AzCopy, the Azure CLI with --auth-mode login, SDKs — need only the Storage Blob Data role.
• In the Azure portal, a user also needs a management role such as Reader at the storage account (or higher) just to navigate to the account; the data role then lets the portal read the blobs with Entra ID.
• Roles that include Microsoft.Storage/storageAccounts/listkeys/action — Owner, Contributor, Storage Account Contributor and Reader and Data Access — reach data a different way: the portal reads the account keys. A key is a full-access credential that keeps working after the role assignment is removed, until the key is rotated. If shared key authorization is disabled on the account, that path closes, and an Owner is refused blob listing like anyone else until given a Storage Blob Data role.
• Blob data roles can be scoped as narrowly as a single container. Individual blobs are not an Azure RBAC scope.

Key Vault (Azure RBAC permission model)

The rule of thumb: an application that must read a secret gets Key Vault Secrets User on that vault (or that secret), usually through its managed identity; someone who only needs to audit what exists gets Key Vault Reader.

To let someone grant access without giving them unlimited power to grant any role, assign Role Based Access Control Administrator with a condition. This is called constrained delegation.

A condition on the assignment can restrict:

• Which roles the delegate may assign or remove — for example only Storage Blob Data Reader and Virtual Machine User Login, never Owner.
• Which principal types or specific principals they may assign them to — for example only to groups, or only to a named set of users.

Without a condition, a Role Based Access Control Administrator could assign themselves Owner at their scope, so the condition is what turns the role into least privilege. User Access Administrator is the broader alternative and is only needed when the delegate must also manage custom role definitions.

Some built-in roles ship with a condition already. Key Vault Data Access Administrator can add and remove role assignments, but only for the Key Vault data roles — useful when a vault owner should manage who reads secrets without being able to hand out general Azure roles.

Scope is where a role assignment applies, and Azure scopes form a hierarchy of four levels, from broadest to narrowest: management group > subscription > resource group > resource. A role assigned at a higher scope is inherited by every child scope beneath it, including children created later.

Admin scenario. Auditors need read-only visibility across a subscription with twelve resource groups. Rather than create twelve assignments, you assign Reader to the auditors' group once at the subscription. Every resource group and resource — including ones created next month — inherits it.

Rules worth knowing:

• Downward only. An assignment on one resource group grants nothing at the subscription or in sibling resource groups.
• Parent resources pass access to child resources. A role assigned on a logical SQL server applies to every database on it; a role on a storage account applies to its containers. To cover one database only, assign on the database.
• Inheritance cannot be removed at the child. An inherited assignment is changed or deleted only at the scope where it was made. If one child resource group must be excluded, re-scope the broad assignment to the children that should have it (or, where Azure manages it, rely on a deny assignment) — another allow at the child cannot cancel it.
• Inheritance follows the current hierarchy. Moving a subscription to a different management group drops the assignments it inherited from the old management group and picks up the new parent's; assignments made directly on the subscription stay.
• Pick the narrowest scope that covers the need, now and later. If a team will keep creating resources in one resource group, assign at that resource group rather than on each resource; if it needs one container of blob data, assign on that container.

Create a custom role when no built-in role grants exactly the required actions — for example "start, restart and stop VMs, nothing else". First check the near matches (see the job-function section); a custom role is for the gap that remains.

A custom role is defined in JSON (or in the portal under Access control (IAM) > Add > Add custom role, PowerShell, CLI or ARM/Bicep) with the same structure as a built-in role:

• Actions / NotActions — control-plane permissions granted, and those subtracted from a wildcard in Actions.
• DataActions / NotDataActions — the same for data-plane permissions.
• AssignableScopes — the management group, subscriptions or resource groups where the role may be assigned.

Rules to remember:

• Built-in roles cannot be edited. To adjust one, clone it into a custom role. Removing only delete from a cloned Virtual Machine Contributor still leaves create, write and disk actions — subtracting one verb rarely produces a narrow role; listing exactly the needed actions does.
• Role names are unique per tenant. A custom role is defined once; to use it in another subscription, edit its AssignableScopes to add that scope rather than creating a second role with the same name.
• AssignableScopes can include only one management group, and cannot be the root scope (/).
• A custom role with DataActions cannot be assigned at management group scope. You may list the management group in AssignableScopes, but you assign the role at the subscriptions (or lower) beneath it.
• A tenant can hold up to 5,000 custom roles.

A principal's effective permissions are the union of every role assignment that applies to them — direct or inherited, personal or through a group — minus anything a deny assignment blocks.

• Allows add up. Reader inherited from the subscription plus Contributor on one resource group makes the user a Contributor there and a Reader elsewhere. No role assignment ever reduces another.
• NotActions is not a deny. NotActions only subtracts actions from its own role definition. If another role assignment grants the action, the principal has it. A custom role with NotActions: Microsoft.Compute/virtualMachines/delete does not stop a user who is also Contributor from deleting VMs.
• Deny assignments win. A deny assignment blocks specific actions for specific principals at a scope even when a role grants them.

Deny assignments are created and managed by Azure, not by administrators: you cannot create one directly in IAM, the CLI or PowerShell (customer-managed deny assignments are only in private preview). In generally available scenarios the source is a deployment stack with deny settings (Azure Blueprints, which used to create them, is retired). Every deny assignment is system protected — it cannot be edited or deleted on its own; you change it by changing the stack. You can view them on the Deny assignments tab of Access control (IAM), with the denied actions and any excluded principals. Unlike a role assignment, a deny assignment can exclude principals and can be set not to apply to child scopes.

A deployment stack manages a set of resources from one Bicep or ARM template, and its deny settings are how you protect those resources from change by anyone, including Owners.

• Exceptions are made on the stack, not with more roles. Use excluded principals (up to five; any principal type, and Microsoft Entra groups are recommended so you can change membership instead of the stack) and excluded actions (up to 200 management operations). Granting someone Owner does not get past the deny.
• Control plane only. Deny settings block management operations on the resources the stack created explicitly. They do not block data-plane operations — blobs, secrets and other data remain governed by data roles.
• applyToChildScopes extends the setting to child resources of the managed resources.
• Changing deny settings needs permission on the stack itself (the Azure Deployment Stack Owner role); Azure Deployment Stack Contributor can manage a stack but not its deny assignments. Place the stack at a parent scope so the teams using the resources cannot edit it.

Azure RBAC controls access to Azure resources; Microsoft Entra roles control access to Microsoft Entra ID itself — users, groups, applications, devices and directory settings. They are separate systems with separate scopes.

Entra user-management roles

Do not confuse User Administrator (Entra — manages user accounts) with User Access Administrator (Azure RBAC — manages access to Azure resources). Assign Entra roles at an administrative unit when an admin should manage only one department's users.

Elevate access

A Global Administrator has no Azure resource access by default. To recover control of subscriptions (for example when every Owner has left), they can elevate access: in Microsoft Entra ID > Properties, set Access management for Azure resources to Yes. Azure then assigns that user User Access Administrator at root scope (/), which is inherited by every management group and subscription in the tenant. They can then grant themselves or others the roles needed. Elevation is per user and persists until removed, so turn the toggle back to No as soon as the task is done.

To find out what a principal can do and where that access comes from, use Access control (IAM) on the scope in question, or the CLI and PowerShell.

• Check access — select a user, group, service principal or managed identity and see its role assignments at this scope, including those inherited from parent scopes and those received through groups, with where each comes from. Deny assignments that apply are shown too.
• Role assignments tab — lists every assignment at this scope. The Scope column reads This resource for a direct assignment or names the parent scope with (Inherited). An inherited entry can only be removed or changed at the scope it names.
• Deny assignments tab — lists deny assignments at or inherited to this scope.
• Roles tab — every role definition, with its permissions.

From the command line

az role assignment list --assignee user@contoso.com --all --include-groups --include-inherited

By default, az role assignment list shows only assignments made directly to the principal at the subscription scope. Each flag widens it:

In PowerShell, Get-AzRoleAssignment -SignInName user@contoso.com -ExpandPrincipalGroups includes assignments received through groups. When access looks wrong, the cause is almost always an inherited assignment or a group membership — check both before concluding a permission is missing.