Custom RBAC Roles in Azure

Importantly, NotActions are subtractive, not additive. For example, if a role includes Microsoft.Compute/virtualMachines/* and NotActions includes Microsoft.Compute/virtualMachines/delete, the principal can perform all VM operations except delete. This is useful for creating roles that are almost like a built-in role but with specific exclusions.

Using Azure CLI: 1. Create a JSON file, e.g., CustomRole.json:

{
  "Name": "VM Restart Operator",
  "Description": "Can restart VMs but not delete or create them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/12345678-1234-1234-1234-123456789abc"
  ]
}

az role definition create --role-definition @CustomRole.json

Using Azure PowerShell:

$roleDefinition = @{
    Name = "VM Restart Operator"
    Description = "Can restart VMs but not delete or create them"
    Actions = @(
        "Microsoft.Compute/virtualMachines/restart/action",
        "Microsoft.Compute/virtualMachines/read"
    )
    AssignableScopes = @("/subscriptions/12345678-1234-1234-1234-123456789abc")
}
New-AzRoleDefinition @roleDefinition

Important: When creating a custom role that includes data actions, you must explicitly specify DataActions and NotDataActions. The * wildcard in Actions does NOT cover data actions. For example, Microsoft.Storage/storageAccounts/* does not include Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. You must list data actions separately.

You cannot assign a custom role at a scope smaller than its assignable scopes. For example, if a custom role's assignable scope is a subscription, you can assign it at that subscription, any resource group within it, or any resource. But you cannot assign it at a management group above the subscription.

Permissions are inherited through the scope hierarchy. If you assign a role at a subscription, the permissions apply to all resource groups and resources within that subscription. Assigning at a resource group applies only to that group and its resources. Assigning at a resource applies only to that specific resource.

Scenario 1: Microservices with Managed Identities A company deploys a microservices application on Azure Kubernetes Service (AKS). Each microservice uses a managed identity to access Azure resources. For example, the 'order-service' needs to write to an Azure SQL database and read from a storage queue. Instead of assigning the built-in Contributor role (which grants excessive permissions), the team creates a custom role named 'OrderServiceRole' with only the necessary actions: Microsoft.Sql/servers/databases/write and Microsoft.Storage/storageAccounts/queueServices/queues/messages/read. The role is assigned to the managed identity at the resource group scope. This limits blast radius if the identity is compromised. The team uses infrastructure-as-code (Terraform) to define the role JSON and assignment, ensuring consistency across environments. A common pitfall is forgetting to include DataActions for storage queue read; they initially used Actions only, which didn't work. After adding DataActions, the microservice functioned correctly.

Scenario 2: External Auditors with Read-Only Access A financial institution needs to grant external auditors read-only access to specific Azure resources (e.g., storage accounts, SQL databases) but no write access. Built-in Reader role provides read access to control plane but not data plane. The team creates a custom role with Actions: ["Microsoft.Storage/storageAccounts/read", "Microsoft.Sql/servers/databases/read"] and DataActions: ["Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read", "Microsoft.Sql/servers/databases/data/read"]. However, they must be careful: DataActions for SQL require the data/read permission, which is not covered by the wildcard. They assign the role to a guest user from the auditing firm at the subscription scope. The auditors can now view blob data and query SQL databases but cannot modify anything. A common mistake is assigning the role at a resource group instead of subscription, causing auditors to miss resources in other groups.

Scenario 3: DevOps Pipeline with Least Privilege A DevOps team uses Azure Pipelines to deploy infrastructure. The service principal used by the pipeline needs to create and manage resources but not delete them. They create a custom role 'DeployOperator' with actions like Microsoft.Resources/deployments/*, Microsoft.Compute/virtualMachines/write (but not delete), and Microsoft.Network/networkInterfaces/write. They also add NotActions: ["Microsoft.Compute/virtualMachines/delete", "Microsoft.Network/networkInterfaces/delete"]. This ensures the pipeline can deploy but not destroy resources. They assign the role to the service principal at the resource group scope. A challenge is that some resource providers have different action names for delete; they must verify each one. Misconfiguration could allow accidental deletion if a delete action is not covered by NotActions.