Automating Role Assignment in Subscriptions & Resource Groups

Solution  · 

keys-unlock[1]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.

[code language=”PowerShell”]

Get-AzureRmRoleDefinition select Name sort -Property Name

[/code]

This gives us the rather long list of roles:

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

Let’s look at a specific role:

[code language=”PowerShell”]

Get-AzureRmRoleDefinition "Virtual Machine Contributor"

[/code]

This gives us a role definition object:

[code language=”PowerShell”]

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 : {/}

[/code]

Of particular interest are the actions allowed by that role:

[code language=”PowerShell”]

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

[/code]

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

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:

[code language=”PowerShell”]

Get-AzureRmRoleDefinition "Contributor"

[/code]

This role definition object is:

[code language=”PowerShell”]

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 : {/}

[/code]

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

[code language=”PowerShell”]

(Get-AzureRmRoleDefinition "Contributor").NotActions

[/code]

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

Users & Groups

Groups-Meeting-Dark-icon[1]

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:

[code language=”PowerShell”]

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

[/code]

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:

[code language=”PowerShell”]

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

[/code]

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

[code language=”PowerShell”]

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

[/code]

Scope

Apps-Brackets-B-icon[1]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:

[code language=”PowerShell”]

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

[/code]

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

[code language=”PowerShell”]

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

[/code]

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

[code language=”PowerShell”]

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

[/code]

Assigning a role

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

[code language=”PowerShell”]

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

[/code]

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.

Leave a comment