Azure ABAC rollout strategy

14 Feb 2025 🔖 security
💬 EN

Microsoft Azure is working on introducing attribute-based access controls (“ABAC”), in addition to their existing system of role-based access controls (“RBAC”), to manage authorization (“authz”).

Do you have an acceptable use policy that’s secure enough for the day Azure ABAC goes into general availability (“GA”)?

I’ve suggested one below that might serve as a useful starting point to your organization.

Risk

A significant risk of using ABAC systems, in general, is that they can make it pretty darned easy to accidentally overscope principals or targets.

Personally, I find Microsoft’s suggestion that Azure ABAC can be used to specify authZ conditions “that have specific business meaning” pretty nerve-wracking.

A well-meaning role assigner might accidentally condition a privilege – or target scope – upon the value of data that someone else regularly edits for their day job.

• Perhaps “someone else” who has no business granting such privileges.
• Perhaps “someone else” who hasn’t even been informed that their ordinary day-to-day work (e.g. someone in the Finance office suggesting that a tag be added to, or removed from, an Azure resource, to better track it for billing purposes) has just had authorization implications piled on top of business data they’ve always “owned.”

To avoid such mistakes, until the your organization has plenty of hands-on experience using ABAC systems, consider restricting your use of Azure ABAC according to these principles:

---

One Entra principal per role assignment

Just as you’re accustomed to with Azure RBAC role assignments, only use one identity from the corresponding identity provider as the principal of an ABAC role assignment.

Technologically, Azure ABAC will let you write a condition that matches zero to many principals. Don’t.

Your organization likely already has mechanisms to dynamically populate Entra group membership, and one Entra group ID already counts as a single principal identity.

For now, keep all of your principal-clumping in one place – Entra group membership definitions. You’ll thank yourself later for not creating chaos without a plan to manage it.

---

Target scope below the level of Azure resource is acceptable

Go ahead and use Azure ABAC to create a roll assignment that has a more granular target scope than you could do with Azure RBAC role assignments.

Thus far, the only example I know of that meets this criteria is that for some reason, Microsoft refuses to give Azure Container Registry (Microsoft.ContainerRegistry/registries) repositories their own Azure resource GUIDs, which means you can’t make each repository serve as an Azure RBAC Role Assignment target scope for, say, AcrPull.

For some reason, instead of just making repositories a type of Azure resource within an Azure resource, Microsoft says to use Azure ABAC Role Assignments to assign AcrPull and AcrPush, target-scoped to a specific repository within a given ACR resource. (Once ABAC goes GA, that is.)

Honestly, I find this weird. Microsoft gave Azure Key Vault (Microsoft.KeyVault/vaults) secrets (Microsoft.KeyVault/vaults/secrets) their own resource GUIDs that can serve as an Azure RBAC Role Assignment target scope for, say, Key Vault Secrets User. That’s how I’d solve the problem of ACR repository-specific role assignment non-scopability. But I don’t make the rules, I just blog them.

Nevertheless, because this particular suggestion uses Azure ABAC to provide more fine-grained access control than would be available with Azure RBAC, it follows the principle of least privilege and I recommend going ahead and doing it.

Plus, switching over to AcrPull and AcrPush role assignments (once ABAC goes GA) lets your principals use passwordless authentication (“authN”), so you can stop worrying about keeping ACR repository tokens a secret.

---

Other target scoping must be discussed case-by-case

I suggest requiring all other use of Azure ABAC to require case-by-case discussion for a while.

Reject conditions that match handfuls

• Scenario: An Azure Resource Group contains seven Storage Account resources, four of which the HumanResources Entra group need Storage Blob Data Reader against.
• Suggestion: While getting started with Azure ABAC, I’d suggest an organization continue to just create four separate Azure RBAC Role Assignments of type Storage Blob Data Reader & principal HumanResources, each with a different Storage Account resource as its target scope.

Discuss conditions that match multitudes

• Scenario: A principal needs the same role against a target scope of thousands of Azure resources. However, for whatever reason, an Azure RBAC Role Assignment target scope of “Resource Group,” “Subscription,” or “Management Group” would overscope and break the principle of least privilege. Creating thousands of Azure RBAC Role Assignments could introduce risk by:
  • cognitively fatiguing maintainers and
  • depleting the 4,000 Azure RBAC Role Assignments available per Azure subscription.
• Suggestion: Formally discuss how your organization might maintainably use Azure ABAC to manage this scenario and reduce its role assignment count to a more manageable number.