Skip to main content
If you need to manage permissions and access across your Azure estate, Azure Role-Based Access Control (RBAC) is the primary mechanism to enforce who can do what and where. RBAC gives you fine-grained control to help enforce security best practices and organizational policies.
Always follow the principle of least privilege: grant only the permissions a principal needs to perform their job, and no more.
What RBAC controls
  • Who — the security principal requesting access (user, group, service principal, or managed identity).
  • What — the actions the principal can perform, defined in a role definition (JSON).
  • Where — the scope where the role applies (management group, subscription, resource group, resource).
When a role definition is assigned to a security principal at a given scope, you create a role assignment. Note: there is a limit of up to 2,000 role assignments per subscription.
Be careful with scope and assignment counts — a subscription can have up to 2,000 role assignments. Excess or overly broad assignments can complicate management and auditability.
Below is a conceptual diagram illustrating these RBAC building blocks.
An infographic titled "Role-Based Access Control" that shows colored blocks labeled "Who?", "What?", and "Where?" combining to form an "Assignment" under the banner "The Principle of Least Privilege." Below are labeled elements like Security Principal, Role Definition, Scope, and Role Assignment.
Key RBAC terms and concepts
  • Security principal — identity requesting access (user, group, service principal, managed identity).
  • Role definition — collection of permissions (Actions, NotActions, DataActions, NotDataActions) expressed in JSON.
  • Scope — where the role applies (management group → subscription → resource group → resource).
  • Role assignment — binding of a role definition to a principal at a scope.
Role definitions Azure provides many built-in roles (Owner, Contributor, Reader, etc.) and numerous service-specific roles (e.g., Virtual Machine Contributor, Storage Blob Data Contributor). If built-ins don’t meet your requirements, create a custom role. A role definition is a JSON object. Here is a simplified snippet of the built-in Contributor role showing its key properties:
Notes on the JSON properties:
  • Actions — allowed management-plane operations. "*" means all actions.
  • NotActions — explicitly excluded operations (e.g., role assignment).
  • AssignableScopes — where the role can be assigned; "/" refers to the tenant root.
  • Additional properties: dataActions / notDataActions (data plane permissions), and other optional attributes for specific services.
Built-in roles you should know
A presentation slide titled "Built-in Roles" showing a four-petal colorful graphic that represents Azure roles: Owner, Contributor, Reader, and User Access Administrator. Each role has a short description of its permissions (e.g., Owner = full access and can delegate, Contributor = manage resources but not grant access, Reader = read-only).
Scope and inheritance Azure scope hierarchy (top → down):
  • Management group
  • Subscription
  • Resource group
  • Resource
Assignments at a higher scope are inherited by lower scopes. For example, a role assigned at a management group propagates down to all subscriptions, resource groups, and resources under that management group. Because inheritance can broaden access quickly, avoid assigning high-privilege roles at high-level scopes unless necessary.
A colorful stepped diagram showing a hierarchy: Management Group → Subscription → Resource Group → Resources. The slide is titled "Scope" with a © KodeKloud credit at the bottom.
Assigning roles in the Azure portal Use the Access control (IAM) blade at any supported scope to view and manage role assignments. The following walkthrough covers the common portal flows.
  1. Select the desired scope (management group, subscription, resource group, or a resource).
    • Open the resource or resource group in the portal and choose “Access control (IAM)”.
  2. View Role assignments to review effective assignments and inheritance (direct vs inherited assignments are shown).
    • Assignments created at the subscription level appear as inherited on resource groups and resources.
A screenshot of the Microsoft Azure portal showing the "Resource groups" page with a list of four resource groups (aad-connect-demo, az-demo-rbac, az-demo-vm, NetworkWatcherRG) and their subscriptions/locations. A notification in the top-right says a resource group was created.
A screenshot of the Microsoft Azure portal showing the Access control (IAM) page for the "az-demo-rbac" resource group with the Role assignments tab open. The list shows one user assigned the Owner role at the subscription scope.
How to add a role assignment (portal)
  • Click Add → Role assignment.
  • Choose a role from the list of built-in and custom roles. Built-ins include job- or service-specific roles for least-privilege assignment.
  • Click Next → Members to select users, groups, or service principals.
  • Review and click Assign.
The portal helps you choose precise service permissions (e.g., Azure Container Registry or Automation account roles) to avoid overly broad privileges.
A screenshot of the Microsoft Azure portal showing the "Add role assignment" workflow with the Members tab active. A right-side "Select members" pane lists user accounts to choose for assigning the Reader role.
When you assign a role (for example, Reader) at a resource-group scope, all resources inside that group inherit the Reader access unless a more specific role assignment overrides it.
A screenshot of the Microsoft Azure portal showing the Access control (IAM) page for a resource group with role assignments. It lists users and their assigned roles (e.g., Owner, Reader) along with scope and filter options.
Creating a custom role (portal) If none of the built-in roles match your needs, create a custom role to narrowly define permissions. Steps:
  1. Navigate to the desired scope (management group, subscription, or resource group).
  2. In Access control (IAM) choose Add → Add custom role.
  3. Provide a name and description. You can:
    • Start from scratch
    • Clone an existing role
    • Upload a JSON role definition
  4. On the Permissions tab, add only the precise actions you want the role to allow (for example, specific Virtual Machine actions).
  5. Set Assignable scopes and create the role.
The Permissions tab lists available management operations so you can construct least-privilege roles.
A screenshot of the Microsoft Azure portal on the "Create a custom role" page, open to the Permissions tab showing a list of virtual machine-related permissions. The right side shows a Definitions panel and navigation buttons like "Review + create," "Previous," and "Next" at the bottom.
After creating a custom role, propagation across the portal and APIs may take a few minutes. The example below shows a scope identifier used during role creation:
A screenshot of the Microsoft Azure portal showing a confirmation dialog that a custom role named "CR-VM App Operator" was successfully created. The page also displays the role's permissions (virtual machine actions) and its assignable scope.
Once created, assign custom roles the same way as built-in roles. Use filters in the Role list to show custom roles, then select members to grant the role.
A screenshot of the Microsoft Azure portal open to the "IT | Access control (IAM)" Role assignments tab. It shows a list of users and groups with assigned roles (for example CR-VM App Operator and Owner) and filter controls for assignment type, role, and scope.
Entra ID roles vs Azure RBAC These two role systems control different planes and are commonly confused. Distinguish them clearly: In short:
  • Use Azure RBAC to control resource operations (create VMs, manage storage, etc.).
  • Use Entra ID roles for identity and directory tasks (user management, tenant configuration).
Best practices and recommendations
  • Principle of least privilege: assign only the permissions necessary.
  • Prefer role assignments at the lowest practical scope to reduce blast radius.
  • Use Privileged Identity Management (PIM) for just-in-time elevation rather than permanent high-privilege assignments.
  • Audit role assignments regularly and consolidate or remove redundant grants.
  • Use custom roles only when built-ins are insufficient; keep custom role definitions minimal and well-documented.
Further reading and references Summary
  • RBAC is built around Who (security principal), What (role definition), and Where (scope).
  • Use built-in roles where they meet requirements; create custom roles for precise permission needs.
  • Understand inheritance across scopes and avoid assigning broad privileges at high-level scopes.
  • Use PIM for just-in-time elevation and separate Azure RBAC (resource management) from Entra ID roles (identity management).

Watch Video