Assigning Azure RBAC roles is how you grant permissions to users and services to manage resources in Azure.
Let’s see this in action. Imagine you have a virtual machine and you want a specific service principal to be able to restart it.
# First, get the resource ID of the VM
$vmId = "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUP/providers/Microsoft.Compute/virtualMachines/YOUR_VM_NAME"
# Get the object ID of the service principal
$spObjectId = "YOUR_SERVICE_PRINCIPAL_OBJECT_ID"
# Define the role assignment
$roleAssignment = @{
"properties" = @{
"roleDefinitionId" = "/subscriptions/YOUR_SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635" # Virtual Machine Contributor role
"principalId" = $spObjectId
"scope" = $vmId
}
}
# Create the role assignment
New-AzRoleAssignment -ObjectId $spObjectId -RoleDefinitionName "Virtual Machine Contributor" -Scope $vmId
This command grants the service principal the "Virtual Machine Contributor" role, allowing it to manage the specified virtual machine. The roleDefinitionId is a unique identifier for the role, and principalId is the identifier for the user or service. The scope defines the level at which the role assignment applies – in this case, a single virtual machine.
The core problem Azure RBAC solves is granular access control in a multi-tenant cloud environment. Instead of giving broad administrative access, you can assign specific permissions for specific tasks on specific resources. This is crucial for security and compliance, ensuring that users and applications only have the access they absolutely need.
Internally, Azure RBAC works by associating "role definitions" with "security principals" at a given "scope." A security principal can be a user, a group, a service principal (representing an application or service), or a managed identity. Role definitions are collections of permissions. Scopes can be at the management group, subscription, resource group, or individual resource level. When a principal attempts an action, Azure checks if any of their assigned roles grant permission for that action at that scope.
The exact levers you control are the scope and the role definition. You can assign the "Reader" role at the subscription level to give someone read-only access to everything, or you can assign the "Virtual Machine Operator" role at a specific resource group level to allow someone to start and stop VMs within that group but not modify their configuration. You can also create custom roles if the built-in ones don’t meet your needs, defining very specific sets of permissions.
Many people think of RBAC as just assigning roles to users. However, the most powerful use case, and often overlooked, is assigning roles to managed identities. When you assign a managed identity a role, the Azure resource that the managed identity represents (like a VM or an App Service) can then authenticate to other Azure services using its identity, without needing to embed credentials in code or configuration. For example, you can assign a managed identity the "Key Vault Secrets Officer" role, and then configure your application running on that VM to retrieve secrets from Key Vault using its managed identity. This removes the need for storing secrets like Key Vault access keys.
The next concept you’ll typically encounter is understanding the difference between built-in roles and custom roles.