Zero Trust alert: Secure your Azure resource access using constrained delegation

Did you know that you can now delegate Azure RBAC assignments to ease your own burden as administrator? There has always been a possibility to assign Owner or User Access Administrator role, but what if you wanted to delegate the assignment process to someone without them being able to delegate it further or being able to assign roles for just about anyone? Here’s where constrained delegation comes into play. Let’s take a look at it now!

Setting the goal

In this blog post let’s go over what problems or issues we’ve might have had before we could leverage constrained delegation and let’s see how it resolves those issues. I will walk through how to use constrained delegation first using Azure Portal and then using PowerShell.

What issues does constrained delegation solve?

Traditionally you haven’t had the chance to set any constraints for role assignments. You most likely had to assign Owner or User Access Administrator roles to a person which could then use that level of access however they wanted. In essence this was not aligned with Zero Trust’s principal of least privilege. In more detail, here are some things that are now possible due to constrained delegation:

• Constraint roles
  • Only roles you’ve picked out as admin are delegated to the user and can be assigned further
  • E.g. assigning Owner role with constrained permissions to role assignments (for example, to subscription scope)
• Constraint principal types
  • Requiring that assignments are only made for users, groups and/or service principals
• Constraint principals
  • Requiring that assignments are only made for identities that are selected by the admin
  • Possibility to prevent role assignments to delegate user themselves
• Exclude specific roles
  • Allow all role assignments, but exclude specific roles (e.g. Owner, User Access Administrator…)

There are of course more reasons to delegate role assignment management:

• Mitigating the burden on environment administrators by delegating the responsibility further to
• Delegating the responsibility to team leaders or project managers who know access needs better so only people who need access have correct role
• Delegating the responsibility to team leaders or project managers because they can deliver the access faster than centralized IT
• Allows better freedom for teams to manage their access within the specified scope

There is a role that is designed for delegated role assignment management called Role Based Access Control Administrator. With this role you can create and delete role assignments. It is a better alternative to User Access Administrator as it has fewer permissions to begin with.

Supported roles

Roles that allow the use of conditions are:

• Role Based Access Control Administrator
• Owner
• User Access Administrator
• Access Review Operator Service Role

Licensing and limitations

This is not a licensed feature, it is free for any organization to utilize

Note! Privileged Identity Management does not support delegate role assignment management with conditions

Assigning constrained delegation – Portal

Go to the desired scope and add new role assignment. We choose Role Based Access Control Administrator here. Press Next

Choose your desired security principal. We are going to choose a user Diego, and we write a short description. Press Next

Choose ‘What user can do’. We’re choosing to constrain roles and principals. Other options are:

• Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended) which excludes roles Owner, User Access Administrator, Role Based Access Control Administrator
• Allow user to assign all roles (highly privileged) which does not constrain anything and no conditions are created.

From role assignment condition view we’re choosing Constrain roles and principal types as we do not want to specify specific users, groups or service principals just the type.

Finally we are able to select the roles and principal type. We’re choosing to constrain principal types to only allow groups. Press Save

Configuration is done. Press Save again.

You can now review your conditions. Press Next

Finish the role assignment from Review + assign

Assigning constrained delegation – PowerShell

In order for us to delegate role assignment management with conditions using PowerShell we need to have those conditions as a code. As of now, the easiest way to generate the code is to create the configuration in Azure Portal and extract the code before creating the role assignment, save the condition code to a PowerShell variable and use it with New-AzRoleAssignment command. At least for me, the code for conditions is not intuitive and I want to avoid making errors and spending time troubleshooting. Maybe at some point you and I become proficient enough to generate the code on top of our heads.

To make sure that you don’t run into errors, remember to update your Azure PowerShell module to at least version 11.6.0

Advanced editor

When creating delegated role assignment with conditions, you also have an option to use an advanced editor. My suggestion is to first configure one of the conditions and then open the advanced editor

Now grab the code to clipboard and head to the PowerShell.

$roleDefinitionId = "f58310d9-a9f6-439a-9e8d-f62e7b41a168" //Role Based Access Control Administrator role definition ID

$principalId = "11112222-3333-4444-5555-666677778888" //Object ID of a user, group, service principal or managed identity

$scope = "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/My-ResourceGroup"

$condition = "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {acdd72a7-3385-48ef-bd42-f606fba81ae7, 749f88d5-cbae-40b8-bcfc-e573ddc772fa} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'Group'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {acdd72a7-3385-48ef-bd42-f606fba81ae7, 749f88d5-cbae-40b8-bcfc-e573ddc772fa} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'Group'}))"

$conditionVersion = "2.0"

New-AzRoleAssignment -ObjectId $principalId -Scope $scope -RoleDefinitionId $roleDefinitionId -Condition $condition -ConditionVersion $conditionVersion

From the post-command output we can see that there are assignments for both write and delete operations and that there are two roles that our user can now delegate (Reader, Monitoring Contributor). We can also see that the only type of service principal our user can delegate these roles is group object and the scope is set to Resource Group.

Built-in roles with conditions

It’s good be aware that there are also built-in roles that have conditions.

Disclaimer: The list of roles is subject to change, but at the time of writing these two built-in roles had conditions

• Key Vault Data Access Administrator
• Virtual Machine Data Access Administrator (preview)

For example Key Vault Data Access Administrator can only assign Key Vault RBAC roles but assigning any other role is denied.

Read more about built-in roles with conditions here.

List assignments with conditions

You might want to list role assignments that have conditions. Use the below command to list them. Notice that I’ve formatted the output as table and limited the columns that are displayed.

Get-AzRoleAssignment | Where-Object {$_.RoleDefinitionName -in "Owner", "Access Review Operator Service Role", "Role Based Access Control Administrator", "User Access Administrator" -and $_.Condition -ne $Null} | Format-Table -Property DisplayName, ObjectType, RoleDefinitionName, Scope

If you want to list role assignments that could be using constrained delegation just switch $_.Condition -ne $Null to $_.Condition -eq $Null and start analyzing those assignments.

Summary

I see this neat feature being utilized way too little and wanted to also raise awareness by writing this blog post. We all know that access management in cloud is really really important and I admit that it can sometimes feel boring, but constantly monitoring and reviewing role assignments should be included in your cloud governance processes. To allow more time for monitoring you should create smaller autonomous bubbles where you have set the limits and boundaries using the constrained delegation feature and thus assigned the responsibility closer to end user. I can see that this might go totally against some company policies where all access management to all applications and environment are implemented centrally, but I dare to challenge this view when it comes to cloud and development teams. Try it out and send your feedback to me in LinkedIn!

Stay secure!