Custom RBAC Role Definitions

Azure Role-Based Access Control (RBAC) uses role definitions to determine what actions a security principal (user, group, or service principal) can perform on a resource. Azure provides over 70 built-in roles like Owner, Contributor, and Reader. However, these roles often grant more permissions than necessary. Custom RBAC roles allow you to define a precise set of permissions tailored to your organization's needs. A custom role is defined by a JSON document that specifies: - Name: A user-friendly name for the role. - Description: A brief explanation of the role's purpose. - Actions: A list of allowed control plane operations (e.g., Microsoft.Compute/virtualMachines/start/action). - NotActions: A list of operations explicitly excluded from the allowed actions. - DataActions: A list of allowed data plane operations (e.g., reading blob data). - NotDataActions: A list of data operations explicitly excluded. - AssignableScopes: The scopes (management groups, subscriptions, or resource groups) where the role can be assigned.

The primary reason for custom roles is the principle of least privilege. Built-in roles are often too broad. For example, the Contributor role allows full management of all resources but cannot grant access to the Azure RBAC permissions themselves. If you need a role that can only start and stop virtual machines but not delete them, you must create a custom role. Custom roles also allow you to combine permissions from multiple built-in roles or restrict specific actions.

When a user attempts an operation (e.g., creating a virtual machine), Azure’s authorization engine checks all role assignments that include the user (directly or via group membership). For each assigned role, the engine evaluates the role definition's actions and notActions. The engine computes the effective permissions as:

Effective Actions = (All Actions) - (All NotActions)

Similarly for DataActions and NotDataActions. If the requested operation matches any effective action, access is granted; otherwise, it is denied. Note that NotActions are subtracted from Actions, so they can only restrict permissions, not grant them.

#### Using Azure Portal 1. Navigate to Azure Active Directory > Roles and administrators (for Azure AD roles) or Subscriptions > Access control (IAM) > Roles (for Azure RBAC roles). Note: Custom Azure RBAC roles are managed at the subscription or management group scope. 2. Click "Add" > "Add custom role". 3. Provide a name and description. 4. Under "Permissions", click "Add permissions" and select the desired actions. You can also add exclusions via NotActions. 5. Under "Assignable scopes", specify the management group, subscription, or resource group where the role can be assigned. 6. Review and create.

#### Using Azure PowerShell

$roleDefinition = @{
    Name = "Virtual Machine Operator"
    Description = "Can start and stop VMs but not delete"
    Actions = @(
        "Microsoft.Compute/virtualMachines/start/action",
        "Microsoft.Compute/virtualMachines/restart/action",
        "Microsoft.Compute/virtualMachines/deallocate/action",
        "Microsoft.Compute/virtualMachines/read"
    )
    NotActions = @()
    AssignableScopes = @("/subscriptions/00000000-0000-0000-0000-000000000000")
}
New-AzRoleDefinition @roleDefinition

#### Using Azure CLI

az role definition create --role-definition '{
  "Name": "Virtual Machine Operator",
  "Description": "Can start and stop VMs but not delete",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}'

A large enterprise has a dedicated team of database administrators (DBAs) who need to manage Azure SQL databases but should not have access to other resources like virtual machines or storage accounts. The built-in Contributor role gives too much access. The solution is to create a custom role named 'SQL DB Administrator' that includes actions such as Microsoft.Sql/servers/databases/read, Microsoft.Sql/servers/databases/write, Microsoft.Sql/servers/databases/delete, and Microsoft.Sql/servers/databases/backupLongTermRetentionPolicies/action. The role is assigned at the subscription scope, but only to the DBAs group. This ensures DBAs can fully manage SQL databases but cannot touch compute or network resources. In production, the role definition is stored in a Git repository for version control. A common issue is forgetting to include read permissions for the server itself (Microsoft.Sql/servers/read), which prevents DBAs from seeing the server in the portal.

A microservices application running on Azure Kubernetes Service (AKS) needs to access an Azure Key Vault to retrieve secrets. The application uses a managed identity. Instead of assigning the built-in Key Vault Contributor role (which allows full management of the vault), a custom role is created with only Microsoft.KeyVault/vaults/secrets/getSecret/action in DataActions. The assignable scope is the specific Key Vault resource group. This follows least privilege. In production, the role is assigned to the managed identity using Azure CLI. A common misconfiguration is using Actions instead of DataActions for secret retrieval, which does not work because secret access is a data plane operation.

External auditors need read-only access to all resources in a subscription but must not see certain cost data or security policies. The built-in Reader role includes read access to everything. To exclude specific areas, a custom role is created with Actions = */read and NotActions = Microsoft.CostManagement/*/read and Microsoft.Security/*/read. This gives broad read access but hides cost and security information. The role is assigned at the subscription scope. A common pitfall is that NotActions only subtract from Actions; if the built-in Reader has additional permissions like Microsoft.Authorization/*/read, those are not included unless explicitly added. So the custom role must include all desired read actions explicitly or use wildcards carefully.