The introduction of the Azure Resource Manager platform in Azure continues to expose new possibilities for managing your deployed resources.
One scenario that you may not be aware of is the ability to use scoped RBAC role assignments to grant limited rights to Azure AD-based users and groups.
We know Azure provides us with many built-in RBAC roles, but it may not be immediately obvious that you can control their assignment scope.
What do I mean by this?
Simply that each RBAC role (including custom ones you create) can be used at various levels within Azure starting at the Subscription level (i.e. applies to anything in the Subscription) down to a Resource (i.e. applies just to one particular resource such as a Storage Account). Role assignments are also cascading – if I assign “Owner” rights to a User or Group at the Subscription level then they have that role for anything contained in the Subscription.
When we view a Role’s definition via PowerShell we can see the assignable scopes it has available. In the sample below we can see that the built-in “Owner” role can be used in any scope (including any Subscription).
[code language=”PowerShell”]
Get-AzureRmRoleDefinition -Name "Owner"
[/code]
Name : Owner Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635 IsCustom : False Description : Lets you manage everything, including access to resources. Actions : {*} NotActions : {} AssignableScopes : {/}
If we look at the definition for a custom role I built you will see that I provided a Subscription-limited scope for this role, which means it can be used only within the Subscription I’ve specified.
All good so far? Great!
What we need to realise is that I could do the following using RBAC roles and assignment scopes:
- Provide “Reader” access to an AD Security Group which allows them to access a Subscription’s properties in read-only mode.
- Assign the same AD Security Group the “Owner” for a specific Resource Group which allows them to perform Owner-level actions on any Resource the Group contains.
In the old Azure platform this simply wasn’t possible.
I developed a simple PowerShell script (see below) which allows us to implement the secondary point from above. You can specify any Security Group, Role and Resource Group you want.
The pre-requisites for this script to work are:
- You have installed the “Azure Active Directory Module for Windows PowerShell“.
- You have a user account in the target Azure AD environment (a “Microsoft Account” won’t work). The user doesn’t have to hold any special roles as you are simply reading details from the Directory.
- You have installed the most recent Microsoft Azure PowerShell Cmdlets.
- You have a user that can log in to your Azure Subscription as an “Owner”.
Once you have those items squared away you’re ready to go ahead and assign away!
As an example let’s assign a Security Group the Owner Role for a specific Resource Group.
[code language=”PowerShell”]
Set-ADGroupRoleForResourceGroup.ps1 -SecurityGroupName "Application Support" -RequiredAzureRoleName "Owner" -ResourceGroupName "rg-app-01"
[/code]
RoleAssignmentId : /subscriptions/c25b1234-xxx-yyy-2390-1a12d7012dd3/resourceGroups/rg-app-01/providers/Microsoft.A uthorization/roleAssignments/1dfcd615-a305-4a2b-a463-3db8d67e5112 Scope : /subscriptions/c25b1234-xxx-yyy-2390-1a12d7012dd3/resourceGroups/rg-app-01 DisplayName : Application Support Team SignInName : RoleDefinitionName : Owner RoleDefinitionId : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635 ObjectId : 13a9c31c-8457-49be-8cea-db1b50594e90 ObjectType : Group
Happy Days!
Reblogged this on siliconvalve.
Great post, Simon. Not only on hybrid integration but also on the importance for organisations to immediately start embracing ARM regardless of where they are in their kloud journey.