Introducing Attribute Based Access Control (ABAC) in Azure
The public preview of Attribute Based Access Control (ABAC) in Azure builds on Azure Role-Based Access Control (RBAC) to make it easier for organizations to manage access to Azure resources at scale. This first release of ABAC supports Azure Storage with resource attributes. Many of you are familiar with Azure RBAC role assignments, which enable you to grant access to one Azure resource or all resources in a hierarchy.
We’ve received the following feedback for Azure RBAC.
- In some scenarios, you need more fine-grained access control than what RBAC offers. For example, you need to grant access to some, not all, resources in a hierarchy.
- You need to make access control decisions based on business information, such as a resource’s deployment stage or a user’s project. Such information is commonly referred to as attributes or tags and using attributes in access control decisions is commonly referred to as ABAC.
- As your Azure usage grows, you need to manage access with relatively fewer role assignments.
With this preview, you can now write ABAC conditions in Azure role assignments. An ABAC condition consists of one or more target actions and a corresponding logical expression using attributes. When a user tries to perform the targeted action in an ABAC condition, the logical expression must evaluate to true to grant access. By using attributes as additional inputs into access control decisions, you can achieve even more fine-grained access control than what RBAC offers with relatively fewer role assignments.
Azure Storage Blob Index Tags and Azure Storage managed attributes are used as resource attributes in ABAC. Examples of ABAC conditions you can write include:
- Allow Read or Write or Delete to blobs based on storage container name
- Allow Read if specific tags and values are present on the blob
We plan to expand ABAC to more Azure resources based on your feedback and will soon add support for user attributes in ABAC conditions.
How do you add an ABAC condition?
You can add an ABAC condition to a new or existing Azure role assignment. Let me illustrate with a fictional example. Bob is an Azure subscription owner for the sales team at Contoso Corporation, a home improvement chain that sells items across lighting, appliances, and thousands of other categories.
Daily sales reports across these categories are stored in an Azure storage container for that day ( 2021-03-24, for example) so that the central finance team members can more easily access the reports. Charlie is the Sales Manager for the lighting category and needs to be able to read the sales reports for this category in any storage container, but not other categories.
Bob can add an ABAC condition in three steps. Let’s assume that the sales reports have the appropriate Blob Index Tags and values assigned and Charlie has a Storage Blob Data Reader role assignment to the “dailysales” storage account.
Step 1: Navigate to the role assignment for Charlie
Bob searches for Charlie’s role assignment for the “dailysales” storage account and clicks Add under the condition column.
Step 2: Select the actions to which the condition should apply
Bob adds a description for the condition and selects the action Read content from a blob with tag conditions to which the ABAC condition should apply.
Step 3: Add the expression
Bob adds an expression requiring that a resource attribute named Category be equal to Lighting to allow read access.
Bob clicks Save to finish adding the ABAC condition to the role assignment.
To summarize, Bob created one role assignment with an ABAC condition per user, which is equivalent to thousands of role assignments per user with RBAC alone. We also plan to add support for assigning attributes to Azure AD users and referring to those user attributes in ABAC conditions. For example, you can assign an attribute called Category to the users and then allow read access to sales reports if user’s Category attribute value matches the blob resource’s Category attribute value. Including user attributes in ABAC conditions along with resource attributes can reduce the one role assignment per user to one role assignment for all users in an Azure AD group. Stay tuned to this blog for updates!
Tools and governance
This launch of ABAC supports resource attributes for Azure Storage (Blobs/ADLS Gen2) and several comparison operators. ABAC conditions are supported via Azure CLI and PowerShell as well. You can also create ABAC conditions using Azure Active Directory Privileged Identity Management (PIM) in eligible role assignments to enforce time limits and justifications when your users activate role assignments.
We have several examples for you to get started and customize as needed. We plan to add ABAC support for more Azure resources. Try ABAC conditions for Azure Storage and let us know your feedback and scenarios.
Published on:
Learn moreRelated posts
Boost your Azure Cosmos DB Efficiency with Azure Advisor Insights
Azure Cosmos DB is Microsoft’s globally distributed, multi-model database service, trusted for mission-critical workloads that demand high ava...
Microsoft Azure Fundamentals #5: Complex Error Handling Patterns for High-Volume Microsoft Dataverse Integrations in Azure
🚀 1. Problem Context When integrating Microsoft Dataverse with Azure services (e.g., Azure Service Bus, Azure Functions, Logic Apps, Azure SQ...
Using the Secret Management PowerShell Module with Azure Key Vault and Azure Automation
Automation account credential resources are the easiest way to manage credentials for Azure Automation runbooks. The Secret Management module ...
Microsoft Azure Fundamentals #4: Azure Service Bus Topics and Subscriptions for multi-system CRM workflows in Microsoft Dataverse / Dynamics 365
🚀 1. Scenario Overview In modern enterprise environments, a single business event in Microsoft Dataverse (CRM) can trigger workflows across m...
Easily connect AI workloads to Azure Blob Storage with adlfs
Microsoft works with the fsspec open-source community to enhance adlfs. This update delivers faster file operations and improved reliability f...
Microsoft Azure Fundamentals #3: Maximizing Event-Driven Architecture in Microsoft Power Platform
🧩 1. Overview Event-driven architecture (EDA) transforms how systems communicate.Instead of traditional request–response or batch integration...
Azure Developer CLI (azd) – October 2025
This post announces the October release of the Azure Developer CLI (`azd`). The post Azure Developer CLI (azd) – October 2025 appeared f...
Microsoft Azure Fundamentals #2: Designing Real-Time Bi-Directional Sync Between Dataverse and Azure SQL for Multi-Region Deployments
Here’s a detailed technical breakdown of designing a real-time bi-directional sync between Dataverse and Azure SQL for multi-region deployment...
Azure DevOps local MCP Server is generally available
Today we are excited to take our local MCP Server for Azure DevOps out of preview 🥳. Since the initial preview announcement, we’ve work...
Announcing the new Azure DevOps Server RC Release
We’re excited to announce the release candidate (RC) of Azure DevOps Server, bringing new features previously available in our hosted version....