Azure supports a Role Based Access Control (RBAC) system.  This system links identity (users & groups) to roles.

RBAC is enforced at the REST API access level, which is the fundamental access in Azure:  it can’t be bypassed.

In this article, we’ll look at how we can automate the role assignation procedure.

This is useful if you routinely create resource groups for different people, e.g. each time a department request some Azure environment or even if you routinely create new subscriptions.

We’re going to do this in PowerShell.  So let’s prep a PowerShell environment with Azure SDK & execute the Add-AzureRmAccount (login) command.

Exploring roles

A role is an aggregation of actions.

Let’s look at the available roles.

Get-AzureRmRoleDefinition | select Name | sort -Property Name

This gives us the rather long list of roles:

• API Management Service Contributor
• API Management Service Operator Role
• API Management Service Reader Role
• Application Insights Component Contributor
• Application Insights Snapshot Debugger
• Automation Job Operator
• Automation Operator
• Automation Runbook Operator
• Azure Service Deploy Release Management Contributor
• Backup Contributor
• Backup Operator
• Backup Reader
• Billing Reader
• BizTalk Contributor
• CDN Endpoint Contributor
• CDN Endpoint Reader
• CDN Profile Contributor
• CDN Profile Reader
• Classic Network Contributor
• Classic Storage Account Contributor
• Classic Storage Account Key Operator Service Role
• Classic Virtual Machine Contributor
• ClearDB MySQL DB Contributor
• Contributor
• Data Factory Contributor
• Data Lake Analytics Developer
• DevTest Labs User
• DNS Zone Contributor
• DocumentDB Account Contributor
• GenevaWarmPathResourceContributor
• Intelligent Systems Account Contributor
• Key Vault Contributor
• Log Analytics Contributor
• Log Analytics Reader
• Logic App Contributor
• Logic App Operator
• Monitoring Contributor Service Role
• Monitoring Reader Service Role
• Network Contributor
• New Relic APM Account Contributor
• Office DevOps
• Owner
• Reader
• Redis Cache Contributor
• Scheduler Job Collections Contributor
• Search Service Contributor
• Security Admin
• Security Manager
• Security Reader
• SQL DB Contributor
• SQL Security Manager
• SQL Server Contributor
• Storage Account Contributor
• Storage Account Key Operator Service Role
• Traffic Manager Contributor
• User Access Administrator
• Virtual Machine Contributor
• Web Plan Contributor
• Website Contributor

Some roles are specific, e.g. Virtual Machine Contributor, while others are much broader, e.g. Contributor.

Let’s look at a specific role:

Get-AzureRmRoleDefinition "Virtual Machine Contributor"

This gives us a role definition object:

Name             : Virtual Machine Contributor
Id               : 9980e02c-c2be-4d73-94e8-173b1dc7cf3c
IsCustom         : False
Description      : Lets you manage virtual machines, but not access to them, and not the virtual network or storage account
they�re connected to.
Actions          : {Microsoft.Authorization/*/read, Microsoft.Compute/availabilitySets/*, Microsoft.Compute/locations/*,
Microsoft.Compute/virtualMachines/*...}
NotActions       : {}
AssignableScopes : {/}

Of particular interest are the actions allowed by that role:

(Get-AzureRmRoleDefinition "Virtual Machine Contributor").Actions

This returns the 34 actions (as of the time of this writing) the role enables:

• Microsoft.Authorization/*/read
• Microsoft.Compute/availabilitySets/*
• Microsoft.Compute/locations/*
• Microsoft.Compute/virtualMachines/*
• Microsoft.Compute/virtualMachineScaleSets/*
• Microsoft.Insights/alertRules/*
• …

We see that wildcards are used to allow multiple actions.  Therefore there are actually much more than 34 actions allowed by this role.

Let’s look at a more generic role:

Get-AzureRmRoleDefinition "Contributor"

This role definition object is:

Name             : Contributor
Id               : b24988ac-6180-42a0-ab88-20f7382dd24c
IsCustom         : False
Description      : Lets you manage everything except access to resources.
Actions          : {*}
NotActions       : {Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write,
Microsoft.Authorization/elevateAccess/Action}
AssignableScopes : {/}

We notice that all actions (*) are allowed but that some actions are explicitly disallowed via the NotActions property.

(Get-AzureRmRoleDefinition "Contributor").NotActions

• Microsoft.Authorization/*/Delete
• Microsoft.Authorization/*/Write
• Microsoft.Authorization/elevateAccess/Action

We could create custom roles aggregating arbitrary groups of actions together but we won’t cover that here.

Users & Groups

Now that we know about role, let’s look at users & groups.

Users & groups will come from the Azure AD managing our Azure subscription.

We can grab a user with Get-AzureRmADUser.  This will list all the users in the tenant.  If you are part of a large organization, this is likely a long list.  We can grab a specific user with the following command:

Get-AzureRmADUser -UserPrincipalName john.smith@contoso.com

We need to specify the domain of the user since we could have users coming from different domains inside the same tenant.

Let’s grab the object ID of the user:

$userID = (Get-AzureRmADUser -UserPrincipalName john.smith@contoso.com).Id

Similarly, we could grab the object ID of a group:

$groupID = (Get-AzureRmADGroup -SearchString "Azure Team").Id

Scope

Next thing to determine is the scope where we want to apply a role.

The scope can be either a subscription, a resource group or a resource.

To use our subscription as the scope, let’s run:

$scope = "/subscriptions/" + (Get-AzureRmSubscription)[0].SubscriptionId

To use a resource group as the scope, let’s run:

$scope = (Get-AzureRmResourceGroup -Name MyGroup).ResourceId

Finally, to use a specific resource as the scope, let’s run:

$scope = (Get-AzureRmResource -ResourceGroupName MyGroup -ResourceName MyResource).ResourceId

Assigning a role

Ok, let’s do this:  let’s put it all together:

New-AzureRmRoleAssignment -ObjectId $userID -Scope $scope -RoleDefinitionName "Contributor"

We can double check in the portal the assignation occurred.

Summary

We simply automate the role assignation using PowerShell.

As with everything that can be done in PowerShell, it can be done using Azure Command Line Interface CLI.  Commands are quite similar.

Also, like every automation, it can be bundled in an Azure Automation Runbook.  So if we have routine operations consisting in provisioning subscriptions or resource groups to group of users, we could package it in a Runbook to ensure consistency.