Custom RBAC Roles in Azure

Custom RBAC roles are user-defined sets of permissions that you create to meet specific access control requirements that built-in roles cannot satisfy. In Azure, every action a user or service principal can perform is governed by role-based access control (RBAC). Built-in roles like Owner, Contributor, and Reader cover common scenarios, but they are often too broad. For example, the Contributor role allows full management of all resources in a scope, but you might want a role that only allows restarting virtual machines and nothing else. Custom roles let you define exactly which actions are allowed and denied.

A custom role is a JSON document that defines a set of permissions. When a user attempts an action, Azure Resource Manager (ARM) evaluates the effective permissions by checking all role assignments at the relevant scope. The role definition contains:

Azure computes effective permissions as: (Actions - NotActions) + (DataActions - NotDataActions). The subtraction means if an action is allowed in Actions but denied in NotActions, it is denied. For example, if Actions includes Microsoft.Compute/virtualMachines/* and NotActions includes Microsoft.Compute/virtualMachines/delete, the role allows all VM operations except delete.

You can create custom roles using the Azure portal, Azure CLI, Azure PowerShell, or ARM templates.

Azure CLI example:

az role definition create --role-definition '{
  "Name": "Virtual Machine Operator",
  "Description": "Can start, stop, and restart virtual machines",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/12345678-1234-1234-1234-123456789abc"]
}'

Azure PowerShell example:

$roleDefinition = @{
    Name = "Virtual Machine Operator"
    Description = "Can start, stop, and restart virtual machines"
    Actions = @(
        "Microsoft.Compute/virtualMachines/start/action",
        "Microsoft.Compute/virtualMachines/powerOff/action",
        "Microsoft.Compute/virtualMachines/restart/action",
        "Microsoft.Compute/virtualMachines/read"
    )
    NotActions = @()
    DataActions = @()
    NotDataActions = @()
    AssignableScopes = @("/subscriptions/12345678-1234-1234-1234-123456789abc")
}
New-AzRoleDefinition @roleDefinition

Verification:

Custom roles interact with:

Role assignments are inherited from the scope they are assigned at down to child scopes. For example, if you assign a custom role at the subscription scope, it applies to all resource groups and resources in that subscription. However, the role definition itself must have the assignable scope set to that subscription or above. If you try to assign a custom role at a resource group scope but the role's AssignableScopes only includes the subscription, the assignment will fail.

A critical distinction on the exam: Actions control management plane operations (Azure Resource Manager API), while DataActions control data plane operations (service-specific APIs). For example:

If you assign a role with only Microsoft.Storage/storageAccounts/read (Action), the user can see storage account properties but cannot read blobs. To read blobs, you need the DataAction. Built-in roles like Storage Blob Data Reader include DataActions. Custom roles must explicitly include DataActions for data plane access.

The exam loves to test understanding of wildcards and NotActions. For example, a role that includes Microsoft.Compute/virtualMachines/* and Microsoft.Compute/virtualMachines/delete in NotActions allows all VM operations except delete. However, if a new VM operation is added by Microsoft (e.g., Microsoft.Compute/virtualMachines/evacuate), the role automatically allows it because of the wildcard. If you want to deny all future operations except a specific set, you would use Microsoft.Compute/* in Actions and then list specific NotActions, but that can become unmanageable. The exam expects you to know that wildcards expand to all current and future actions under that resource type.

A large enterprise gives developers access to a sandbox subscription where they can create and manage resources but cannot delete resource groups or modify networking components. Built-in Contributor allows deletion, which is too risky. The security team creates a custom role called "Sandbox Developer" with actions like Microsoft.Compute/*, Microsoft.Storage/*, Microsoft.Network/networkInterfaces/*, but with NotActions including Microsoft.Resources/subscriptions/resourceGroups/delete and Microsoft.Network/virtualNetworks/*. The role is assigned at the subscription scope with AssignableScopes limited to that sandbox subscription. This prevents the role from being used in production. Common misconfiguration: forgetting to add Microsoft.Resources/subscriptions/resourceGroups/write which is needed to create resources in a resource group. Without it, developers cannot create VMs because creating a VM requires writing to the resource group.

External auditors need read-only access to specific storage account containers for a compliance review. Built-in Storage Blob Data Reader gives read access to all blobs in the storage account, but the auditors should only access a specific container. The team creates a custom role with DataAction Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read and restricts the AssignableScopes to the specific container resource ID: /subscriptions/.../resourceGroups/rg1/providers/Microsoft.Storage/storageAccounts/account1/blobServices/default/containers/audit-container. However, the role assignment must be at the container scope, not the storage account. This granularity is only possible with custom roles. A common pitfall: the role definition must include the container scope in AssignableScopes, and the assignment must be made at that scope. If the assignment scope is the storage account, the role will not work because the role's AssignableScopes does not include the storage account.

A service principal needs to perform automated backups of virtual machines and SQL databases. It requires permissions to list VMs, read disk snapshots, and write to a backup storage account. The team creates a custom role "Backup Operator" with actions: Microsoft.Compute/virtualMachines/read, Microsoft.Compute/disks/read, Microsoft.Compute/snapshots/beginGetAccess/action, Microsoft.Storage/storageAccounts/listKeys/action, and DataAction Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write. They assign the role to the service principal at the resource group scope containing the VMs and storage account. They also ensure the storage account firewall allows access from the service principal's IP or uses a managed identity. Misconfiguration: forgetting the listKeys action, which is needed to get the storage account key for backup tools that use key-based authentication.