Custom RBAC Roles and Scope Inheritance

Implement Custom RBAC Roles and Assignment Conditions

Azure Role-Based Access Control (RBAC) is the system that controls who can do what in Azure. It works by assigning roles to users, groups, service principals, or managed identities. When built-in roles do not fit your needs, you can create custom RBAC roles that define exactly which permissions a person receives. A custom role lists the actions a user can perform using Actions, NotActions, DataActions, and NotDataActions. This precision matters because it follows the principle of least privilege—giving only the permissions needed for a specific job, which reduces risk if an account is compromised.

Assignment conditions add context-aware restrictions to role assignments. Instead of giving broad access to everything under a scope, you can limit access based on resource attributes like tags, names, or custom security attributes. For example, you can allow someone to read blobs only if those blobs have a specific tag. This approach is called attribute-based access control (ABAC) and makes access management more scalable. Rather than creating thousands of separate role assignments for each resource, you create one assignment at a higher scope with a condition that filters access dynamically.

To create and assign custom roles, you need the Microsoft.Authorization/roleAssignments/write permission, which typically comes with roles like Owner, User Access Administrator, or Role Based Access Control Administrator. Custom roles can be created through the Azure portal, PowerShell, CLI, or REST APIs. Always assign custom roles at the most restrictive scope possible—ideally a resource or resource group rather than a subscription or management group.

Define and Apply RBAC Roles at Various Scopes

In Azure, scope means the set of resources that access applies to. Scopes follow a hierarchy from broad to narrow: Management Groups sit at the top and can hold multiple subscriptions, which contain Resource Groups, which hold individual Resources like virtual machines or storage accounts. Understanding this hierarchy is essential because permissions assigned at a higher scope automatically flow down to everything below it.

Assigning a role involves selecting a scope, choosing a role definition (like Contributor for full resource management or Reader for view-only access), and then picking the security principal who receives it. The process works the same way whether you're working at the management group, subscription, resource group, or resource level—you search for the scope, open Access control (IAM), and add a role assignment. The key permission needed is Microsoft.Authorization/roleAssignments/write.

Azure RBAC uses an additive model, meaning a user's effective permissions are the sum of all their role assignments. If someone has the Contributor role at the subscription level and Reader role at the resource group level, they get all Contributor permissions across the entire subscription. This stacking behavior means you must carefully plan role assignments to avoid giving more access than intended. Azure evaluates access by first checking for any deny assignments (which always block access), then calculating permissions by combining all allow assignments.

Analyze Role Inheritance and Effective Permissions

Role inheritance is how Azure propagates permissions down through the scope hierarchy. When you assign a role at the subscription level, that permission automatically applies to every resource group and resource within that subscription. This works because the four scope levels—Management Groups, Subscriptions, Resource Groups, and Resources—form a parent-child relationship. Once a role is assigned at a higher level, child scopes cannot revoke or override those inherited permissions; they can only add more restrictive roles at their own level.

The effective permissions for a user come from combining all role assignments across all scopes where they have access. Azure calculates this by taking all allowed actions and subtracting any explicitly excluded actions, following the logic: Actions - NotActions = Effective management permissions and DataActions - NotDataActions = Effective data permissions. Deny assignments always take precedence over allow assignments, so even if a role grants certain permissions, a deny assignment at a higher scope will block them.

Role assignments are also transitive through group membership. If a user belongs to a group that has a role assignment, the user receives those permissions—even if that group is nested inside another group. This transitive behavior means administrators must track not just direct role assignments but also group memberships to understand who truly has access to what. Following least privilege principles helps manage this complexity by ensuring users receive only the minimum access required for their tasks, which limits the potential impact of a security breach.