What is Azure attribute-based access control (Azure ABAC)?
Attribute-based access control (ABAC) is an authorization system that defines access based on attributes associated with security principals, resources, and the environment of an access request. With ABAC, you can grant a security principal access to a resource based on attributes. Azure ABAC refers to the implementation of ABAC for Azure.
What are role assignment conditions?
Azure role-based access control (Azure RBAC) is an authorization system that helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. In most cases, Azure RBAC will provide the access management you need by using role definitions and role assignments. However, in some cases you might want to provide more fine-grained access management or simplify the management of hundreds of role assignments.
Azure ABAC builds on Azure RBAC by adding role assignment conditions based on attributes in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can add a condition that requires an object to have a specific tag to read the object. You cannot explicitly deny access to specific resources using conditions.
Why use conditions?
There are three primary benefits for using role assignment conditions:
- Provide more fine-grained access control - A role assignment uses a role definition with actions and data actions to grant security principal permissions. You can write conditions to filter down those permissions for more fine-grained access control. You can also add conditions to specific actions. For example, you can grant John read access to blobs in your subscription only if the blobs are tagged as Project=Blue.
- Help reduce the number of role assignments - Each Azure subscription currently has a role assignment limit. There are scenarios that would require thousands of role assignments. All of those role assignments would have to be managed. In these scenarios, you could potentially add conditions to use significantly fewer role assignments.
- Use attributes that have specific business meaning - Conditions allow you to use attributes that have specific business meaning to you in access control. Some examples of attributes are project name, software development stage, and classification levels. The values of these resource attributes are dynamic and change as users move across teams and projects.
Example scenarios for conditions
There are several scenarios where you might want to add a condition to your role assignment. Here are some examples.
- Read access to blobs with the tag Project=Cascade
- New blobs must include the tag Project=Cascade
- Existing blobs must be tagged with at least one Project key or Program key
- Existing blobs must be tagged with a Project key and Cascade, Baker, or Skagit values
- Read, write, or delete blobs in containers named blobs-example-container
- Read access to blobs in containers named blobs-example-container with a path of readonly
- Write access to blobs in containers named Contosocorp with a path of uploads/contoso
- Read access to blobs with the tag Program=Alpine and a path of logs
- Read access to blobs with the tag Project=Baker and the user has a matching attribute Project=Baker
- Read access to blobs during a specific date/time range.
- Write access to blobs only over a private link or from a specific subnet.
For more information about how to create these examples, see Example Azure role assignment conditions for Blob Storage.
Where can conditions be added?
Currently, conditions can be added to built-in or custom role assignments that have blob storage or queue storage data actions. Conditions are added at the same scope as the role assignment. Just like role assignments, you must have Microsoft.Authorization/roleAssignments/write permissions to add a condition.
Here are some of the blob storage attributes you can use in your conditions.
- Account name
- Blob index tags
- Blob path
- Blob prefix
- Container name
- Encryption scope name
- Is Current Version
- Is hierarchical namespace enabled
- Is private link
- Snapshot
- UTC now (the current date and time in Coordinated Universal Time)
- Version ID
What does a condition look like?
You can add conditions to new or existing role assignments. Here is the Storage Blob Data Reader role that has been assigned to a user named Chandra at a resource group scope. A condition has also been added that only allows read access to blobs with the tag Project=Cascade.
If Chandra tries to read a blob without the Project=Cascade tag, access will not be allowed.
Here is what the condition looks like in the Azure portal:
Here is what the condition looks like in code:
(
(
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
AND NOT
SubOperationMatches{'Blob.List'})
)
OR
(
@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
)
)
For more information about the format of conditions, see Azure role assignment condition format and syntax.
Status of condition features
The following table lists the status of condition features:
| Feature | Status | Date |
|---|---|---|
| Use environment attributes in a condition | GA | April 2024 |
| Add conditions using the condition editor in the Azure portal | GA | October 2022 |
| Add conditions using Azure PowerShell, Azure CLI, or REST API | GA | October 2022 |
| Use resource and request attributes for specific combinations of Azure storage resources, access attribute types, and storage account performance tiers. For more information, see Status of condition features in Azure Storage. | GA | October 2022 |
| Use custom security attributes on a principal in a condition | GA | November 2023 |
Conditions and Microsoft Entra PIM
You can also add conditions to eligible role assignments using Microsoft Entra Privileged Identity Management (Microsoft Entra PIM) for Azure resources. With Microsoft Entra PIM, your end users must activate an eligible role assignment to get permission to perform certain actions. Using conditions in Microsoft Entra PIM enables you not only to limit a user's access to a resource using fine-grained conditions, but also to use Microsoft Entra PIM to secure it with a time-bound setting, approval workflow, audit trail, and so on. For more information, see Assign Azure resource roles in Privileged Identity Management.
Terminology
To better understand Azure RBAC and Azure ABAC, you can refer back to the following list of terms.
| Term | Definition |
|---|---|
| attribute-based access control (ABAC) | An authorization system that defines access based on attributes associated with security principals, resources, and environment. With ABAC, you can grant a security principal access to a resource based on attributes. |
| Azure ABAC | Refers to the implementation of ABAC for Azure. |
| role assignment condition | An additional check that you can optionally add to your role assignment to provide more fine-grained access control. |
| attribute | In this context, a key-value pair such as Project=Blue, where Project is the attribute key and Blue is the attribute value. Attributes and tags are synonymous for access control purposes. |
| expression | A statement in a condition that evaluates to true or false. An expression has the format of <attribute> <operator> <value>. |
Limits
Here are some of the limits for conditions.
| Resource | Limit | Notes |
|---|---|---|
| Number of expressions per condition using the visual editor | 5 | You can add more than five expressions using the code editor |
Known issues
Here are the known issues with conditions:
- If you are using Microsoft Entra Privileged Identity Management (PIM) and custom security attributes, Principal does not appear in Attribute source when adding a condition.