Some interesting changes happened recently (within last year 😉) in the area of highly privileged (i.e. control plane or Tier 0 in legacy terms) Azure infrastructure RBAC model roles.
Up until now, the classic trio of control plane privileged roles with direct control over Azure infrastructure was limited to:
- Owner
- User Access Administrator
- Entra ID Global Administrator (via single-click elevation❕)
Tip
Indirect elevation paths to control plane starting with less powerful roles are essentially unlimited, but that's a topic for different post.
To get a glimpse, see these excellent articles by Andy Robbins and Karl Fosaaen :
Since then, two new roles have been added:
Let's dissect Reservations Administrator first.
Is it really a control plane role? To answer this, we need to look at its definition:
{
"assignableScopes": [
"/providers/Microsoft.Capacity"
],
<...redacted for brevity...>
"permissions": [
{
"actions": [
"Microsoft.Capacity/*/read",
"Microsoft.Capacity/*/action",
"Microsoft.Capacity/*/write",
"Microsoft.Authorization/roleAssignments/read",
"Microsoft.Authorization/roleDefinitions/read",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/roleAssignments/delete"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
<...redacted for brevity...>
}
All right, it has Microsoft.Authorization/roleAssignments/write control plane privileged action allowing assignments of any Azure RBAC role, however, to obtain the full context, one would also need to pay attention to the assignableScopes property - set to /providers/Microsoft.Capacity.
That assignable scope value is odd in the context of built-in role, isn't it?
However, it makes sense after reviewing the documentation on Azure Reservations.
To summarize, Reservations Administrator, even though it can mange role assignment, it can do so only on Azure reservation objects. Technically it's still a control plane role, but greatly constrained - can't be assigned to resources and constructs other than reservation objects.
Tip
To assign Reservations Administrator role, activate User Access Administrator (or better Role Based Access Control Administrator) and use following Azure CLI command: az role assignment create --assignee "<assignee (user or group) ObjectID>" --scope "/providers/Microsoft.Capacity" --role "a8889054-8d42-49c9-bc1c-52486c10e7cd".
Reservations can then be managed in Cost Management blade in Azure Portal.
Onto the second one.
Role Based Access Control Administrator is, in my opinion, very useful one.
Let's examine role definition first:
{
"assignableScopes": [
"/"
],
<...redacted for brevity...>
"permissions": [
{
"actions": [
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/roleAssignments/delete",
"*/read",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
<...redacted for brevity...>
}
By default, role definition of Role Based Access Control Administrator includes following control plane actions:
"Microsoft.Authorization/roleAssignments/write"- ability to assign any Azure RBAC role (inc. control plane roles like Owner or User Access Administrator) at any scope"Microsoft.Authorization/roleAssignments/delete"- ability to delete assignments of any Azure RBAC role
Above actions make the role highly privileged and member of control plane. That's the default configuration.
However, the main value of this role comes from the capability to implement Azure RBAC role assignment constrained delegation scenario.
How does it work? Let me describe an imaginary scenario as an example.
Imagine Anna, who is tasked with administering and operating IAM for her company's Azure infrastructure resources.
Currently, every time she needs to make a change in role assignments, she has to logon to privileged access workstation, use Privileged Identity Management to activate User Access Administrator role at a correct scope, and perform the actual role assignment.
It's only first week of the month and Anna already had to perform over 20 unique role assignments.
Tim, who is responsible for setting up the permissions for his team's DevOps pipeline, requests User Access Administrator to be assigned at the DevOps team subscription scope.
Anna knows the core tenets of zero trust (least privilege, assume breach and verify explicitly) and decides the request must be implemented in smarter fashion.
She decides to assign Role Based Access Control Administrator role to Tim at his team subscription scope.
Anna also decides the role will be constrained - Tim will be able to assign just the roles delegated to him and assign them only to service principals.
Anna performs following actions in the Azure Portal:
-
She selects 'Allow user to only assign selected roles to selected principals' option
-
She creates an assignment condition constraining Tim to assign only Contributor role to service principal objects
By performing above activities Anna accomplished few goals:
- Enabled Tim to manage role assignments within applied guardrails. Tim can be more efficient now, instead of raising requests for role assignments and be blocked until their completion, he can now spend more time on deliverables that can move his team and company goals forward.
- Anna can now spend less time on assigning roles and similarly to Tim, can focus on more important goals.
- Anna did all of this in alignment with security best practices and principles.
Note
In which cases does Role Based Access Control fall shor when compared to User Access Administrator?
- It can't (yet!) manage eligible role assignments in Privileged Identity Management
- It can't create new, custom role assignments
To summarize, always strive to be aligned with one of the basic Zero Trust tenets - least privilege. Minimize the use of User Access Administrator or Owner roles and smartly delegate assignment capabilities with Role Based Access Control Administrator.
Don't be that person! 😃
- Enterprise Access Model
- Understand role definition structure
- Azure infrastructure built-in roles
- Automating Azure abuse research
- Azure Automation Account connections
All work is licensed under a Creative Commons Attribution 4.0 International License.
