At the start of a new Azure project, we typically conduct a short Azure governance exercise.  One of the items that are covered is role-based access control: both for the people that access the Azure portal and for the DevOps agents that have to deploy our solutions throughout the D-T-A-P street.  The latter always ends-up with the same discussion.  Let’s have a closer look!

The impasse

This is a typical conversation:

• The Development Team: “We want to completely automate our infrastructure through CI/CD.  Next to that, we want to ensure that all communication between the Azure services is done via Managed Identity.  If we want to do all of this in an automated way, the Service Principal that performs the deployment requires Owner or User Access Administrator rights.”
• The Cloud Center of Excellence: “No way that your Service Principal gets Owner rights, because then, we do not control the access to the services anymore, because that Service Principal can grant access to everyone in our tenant.  We want to avoid this at all time!”

You know what?  Both are right!  The Development Team wants to apply DevOps and security best practices, but the creation of role assignments – to grant a managed identity access to another Azure service – requires Owner or User Access Administrator rights.  The Cloud Center of Excellence is also right: they are responsible for RBAC, so it is normal that they don’t want to give those rights, because otherwise the Service Principal could be abused to grant access to user accounts.

This is a fundamental issue in the underlying Azure design.  Azure requires the same access rights (Microsoft.Authorization/roleAssignments/write) for:

• Granting a managed identity access to another Azure service >> This is what the Development Team wants
• Granting a user or security group access to an Azure service >> This is what the Cloud Center of Excellence wants to avoid

The solution

Luckily, we have now a solution for this impasse: role assignment conditions!  Let’s have a look at what this means for our situation:

• When you perform a role assignment and select the User Access Administrator role, an extra Conditions tab appears

• In the Conditions tab. click on + Add condition

• Click Configure under the Constrain roles and principal types option, which fits our use case

• Here, you can restrict which roles the Development Team can assign and limit the assignment to Service Principals.

Conclusion

Happy that the Azure product teams have listened to our feedback and implemented a solution that allows to minimize the role assignments to only what’s needed.  Least privilege, that’s what we like!  Now, both the Development Team and the Cloud Center of Excellence are happy!

Thanks for sharing!
Toon