Granular RBAC Permissions for Azure Local VMs: Moving Beyond Built-in Roles

If you’ve been working with Azure Local VMs (those Arc-enabled virtual machines running on your on-premises Azure Local clusters), you’ll know that managing user access is an important task. Microsoft provides some good built-in roles, but they often don’t give you the fine-grained control many organisations need. That’s where custom RBAC roles come in handy – letting you tailor permissions exactly to what your users or teams require.

In this post, I’ll walk through the built-in options, why you might want to go custom, and how to set it up step by step. This is especially useful in delegated admin scenarios or when you want to limit visibility and actions to specific VMs only.

Built-in Roles for Azure Local VMs

Microsoft offers three main built-in roles specifically for managing VMs on Azure Local (Azure Stack HCI). Here’s a quick breakdown:

• Azure Stack HCI Administrator Full power on VMs: create, list, delete. Plus start, stop, restart. On the resource side: create, list, delete everything – logical networks, VM images, storage paths, you name it.
• Azure Stack HCI VM Contributor Same VM-level actions: create, list, delete, start/stop/restart. But restricted on resources – can create/list/delete VM-related items except logical networks, VM images, and storage paths.
• Azure Stack HCI VM Reader Read-only access. List all VMs and list all related VM resources. No modifications allowed.

These roles work great for broad access (like full admins or read-only monitoring), but what if you want someone to only restart certain VMs? Or manage just one VM without seeing the rest of the cluster resources? Built-ins fall short there.

Why Create Custom Roles?

Custom roles give you that extra flexibility. You can pick and choose specific Microsoft.Authorization operations (like Microsoft.Compute/virtualMachines/start/action for starting a VM) and scope them precisely. This is perfect for:

• Delegating VM operations to application teams without exposing the full infrastructure.
• Ensuring users only see and interact with the VMs they’ve been assigned.
• Meeting strict least-privilege security requirements in hybrid environments.

Full details on custom roles are in the official docs: Azure custom roles – Azure RBAC.

How to Create and Use a Custom Role

The process uses JSON definitions and PowerShell (or Azure CLI if you prefer).

1. Export an existing role as a template
   Start by dumping one of the built-ins to see the available actions:
   
   $roleDefinitionName = "Azure Stack HCI VM Contributor"
Get-AzRoleDefinition -Name $roleDefinitionName | ConvertTo-Json | Out-File C:\Temp\CustomRoles\customrole-$roleDefinitionName.json
   
   Open the JSON file – you’ll see sections like “actions” and “notActions”. This is your shopping list.
   
2. Edit the JSON for your needs
   Strip it down to only the operations you want. For example, a “VM Operator” role might allow start/stop/restart and read access, but no create/delete. Save it as something like customrole-Azure_Stack_HCI_VM_Operator.json. (Pro tip: Keep “assignableScopes” broad initially – like “/” for subscription level, or target a specific resource group).
   
3. Create the custom role
   In this example, for the VM Operator role, I exported the JSON defintions for the ‘Azure Stack HCI Contrbitor’ built-in role and removed all the ‘write’ and ‘delete’ actions. I then used the below command to create the ‘VM Operator’ custom role.
   
   New-AzRoleDefinition -InputFile "C:\Temp\CustomRoles\customrole-Azure_Stack_HCI_VM_Operator.json"
   
4. Update if needed later
   If you need to update the role you can amend the JSON file and use the below command:
   
   Set-AzRoleDefinition -InputFile "C:\Temp\CustomRoles\customrole-Azure_Stack_HCI_VM_Operator.json"
   
5. Assign the role
   To use the role, head to the Azure Portal → your Azure Local cluster/resource group → select the VM from the Resources section → Access control (IAM) → Add role assignment. Pick your custom role, assign it to a user (or group), and scope it to the specific VM resource if needed.
   Result? In the portal, they only see that VM – nothing else clutters their view. Furthermore, the user will only be able to perform the operations as per the definitions in the custom role.
   
   *Ensure to assign at least ‘Reader’ permissions on the Resource Group where the Azure Local VM resources are located to be able to view the Resource Group in the portal
   

Conclusion

I hope the above is useful and helps you to define your own custom roles for Azure Local VMs. I expect Microsoft will introduce more built-on roles in future, but for now this should bridge the gap.