2.1.2.1. Create Custom Roles

💡 First Principle: Azure custom roles enforce the principle of least privilege by allowing the creation of precise permission sets tailored to specific job functions when built-in roles are insufficient.

Scenario: Your organization needs a specific role for "VM Operators" that allows them to start, stop, and restart Virtual Machines but explicitly denies deletion of any VM. No built-in role exactly matches this requirement.

What It Is: Custom roles are user-defined Role-Based Access Control (RBAC) roles that provide fine-grained control over Azure resources.

Key components of a custom role definition:

• Actions: Management operations the role explicitly allows (e.g., Microsoft.Compute/virtualMachines/start/action, Microsoft.Network/virtualNetworks/read).
• NotActions: Management operations explicitly denied, even if included in Actions (e.g., Microsoft.Compute/virtualMachines/delete).
• DataActions: Allowed operations on data within resources (e.g., Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read).
• NotDataActions: Data operations explicitly denied.
• AssignableScopes: Where the role can be assigned (management group, subscription, resource group). This ensures the role can only be used in specific parts of your Azure hierarchy.

Practical Implementation: Creating a Custom Role with Azure CLI

1. Create the JSON definition file (vm-operator-role.json):

   {
     "Name": "VM Operator",
     "IsCustom": true,
     "Description": "Can start, stop, and restart VMs, but cannot delete them.",
     "Actions": [
       "Microsoft.Compute/virtualMachines/start/action",
       "Microsoft.Compute/virtualMachines/restart/action",
       "Microsoft.Compute/virtualMachines/read"
     ],
     "NotActions": [
       "Microsoft.Compute/virtualMachines/delete/action"
     ],
     "AssignableScopes": [
       "/subscriptions/your-subscription-id"
     ]
   }
   

2. Create the role using Azure CLI:

   az role definition create --role-definition @vm-operator-role.json
   

⚠️ Common Pitfall: Creating custom roles when a built-in role would suffice, leading to unnecessary complexity and management overhead.

Key Trade-Offs:

• Granularity of Control (Custom Roles) vs. Simplicity and Maintainability (Built-in Roles): Custom roles provide precise control but add management overhead. Built-in roles are simpler to manage but may be less granular.

Reflection Question: How does creating an Azure custom role fundamentally enforce the principle of least privilege by providing precise control over permissions, and why is this essential for granular, auditable access control?