What is Azure attribute-based access control (Azure ABAC)? (preview)

Important

Azure ABAC and Azure role assignment conditions are currently in preview. This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Attribute-based access control (ABAC) is 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.

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 fined-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 a 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

For more information about how to create these examples, see Examples of Azure role assignment conditions.

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
  • Snapshot
  • 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.

Diagram of role assignment with a condition.

If Chandra tries to read a blob without the Project=Cascade tag, access will not be allowed.

Diagram of access is not allowed with a condition.

Here is what the condition looks like in the Azure portal:

Screenshot of condition editor in Azure portal showing build expression section with values for blob index tags.

Here is what the condition looks like in code:

(
    (
        !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
        AND
        SubOperationMatches{'Blob.Read.WithTagConditions'})
    )
    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.

Features of conditions

Here's a list of the primary features of conditions:

Feature Status Date
Use the following attributes in a condition: Account name, Blob prefix, Encryption scope name, Is Current Version, Is hierarchical namespace enabled, Snapshot, Version ID Preview May 2022
Use custom security attributes on a principal in a condition Preview November 2021
Add conditions to blob storage data role assignments Preview May 2021
Use attributes on a resource in a condition Preview May 2021
Use attributes that are part of the action request in a condition Preview May 2021

Conditions and Privileged Identity Management (PIM)

You can also add conditions to eligible role assignments using Privileged Identity Management (PIM). With PIM, your end users must activate an eligible role assignment to get permission to perform certain actions. Using conditions in PIM enables you not only to limit a user's access to a resource using fine-grained conditions, but also to use 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 Azure AD Privileged Identity Management (PIM) and custom security attributes, Principal does not appear in Attribute source when adding a condition.

Next steps