Uređivanje

Dijeli putem

Example Azure role assignment conditions for Blob Storage

  • Članak

This article lists some examples of role assignment conditions for controlling access to Azure Blob Storage.

Important

Azure attribute-based access control (Azure ABAC) is generally available (GA) for controlling access to Azure Blob Storage, Azure Data Lake Storage Gen2, and Azure Queues using request, resource, environment, and principal attributes in both the standard and premium storage account performance tiers. Currently, the container metadata resource attribute and the list blob include request attribute are in PREVIEW. For complete feature status information of ABAC for Azure Storage, see Status of condition features in Azure Storage.

See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

Prerequisites

For information about the prerequisites to add or edit role assignment conditions, see Conditions prerequisites.

Summary of examples in this article

Use the following table to quickly locate an example that fits your ABAC scenario. The table includes a brief description of the scenario, plus a list of attributes used in the example by source (environment, principal, request and resource).

Example Environment Principal Request Resource
Read blobs with a blob index tag tags
New blobs must include a blob index tag tags
Existing blobs must have blob index tag keys tags
Existing blobs must have a blob index tag key and values tags
Read, write, or delete blobs in named containers container name
Read blobs in named containers with a path container name
blob path
Read or list blobs in named containers with a path blob prefix container name
blob path
Write blobs in named containers with a path container name
blob path
Read blobs with a blob index tag and a path tags
blob path
Read blobs in container with specific metadata container metadata
Write or delete blobs in container with specific metadata container metadata
Read only current blob versions isCurrentVersion
Read current blob versions and a specific blob version versionId isCurrentVersion
Delete old blob versions versionId
Read current blob versions and any blob snapshots snapshot isCurrentVersion
Allow list blob operation to include blob metadata, snapshots, or versions list blob include
Restrict list blob operation to not include blob metadata list blob include
Read only storage accounts with hierarchical namespace enabled isHnsEnabled
Read blobs with specific encryption scopes Encryption scope name
Read or write blobs in named storage account with specific encryption scope Storage account name
Encryption scope name
Read or write blobs based on blob index tags and custom security attributes ID tags tags
Read blobs based on blob index tags and multi-value custom security attributes ID tags
Allow read access to blobs after a specific date and time UtcNow container name
Allow access to blobs in specific containers from a specific subnet Subnet container name
Require private link access to read blobs with high sensitivity isPrivateLink tags
Allow access to a container only from a specific private endpoint Private endpoint container name
Example: Allow read access to highly sensitive blob data only from a specific private endpoint and by users tagged for access Private endpoint ID tags

Blob index tags

This section includes examples involving blob index tags.

Important

Although the Read content from a blob with tag conditions suboperation is currently supported for compatibility with conditions implemented during the ABAC feature preview, it has been deprecated and Microsoft recommends using the Read a blob action instead.

When configuring ABAC conditions in the Azure portal, you might see DEPRECATED: Read content from a blob with tag conditions. Microsoft recommends removing the operation and replacing it with the Read a blob action.

If you are authoring your own condition where you want to restrict read access by tag conditions, please refer to Example: Read blobs with a blob index tag.

Example: Read blobs with a blob index tag

This condition allows users to read blobs with a blob index tag key of Project and a value of Cascade. Attempts to access blobs without this key-value tag isn't allowed.

For this condition to be effective for a security principal, you must add it to all role assignments for them that include the following actions:

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing read access to blobs with a blob index tag.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal visual editor.

Condition #1 Setting
Actions Read a blob
Attribute source Resource
Attribute Blob index tags [Values in key]
Key {keyName}
Operator StringEquals
Value {keyValue}

Screenshot of condition editor in Azure portal showing read access to blobs with a blob index tag.

Example: New blobs must include a blob index tag

This condition requires that any new blobs must include a blob index tag key of Project and a value of Cascade.

There are two actions that allow you to create new blobs, so you must target both. You must add this condition to any role assignments that include one of the following actions:

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing new blobs must include a blob index tag.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Write to a blob with blob index tags
Write to a blob with blob index tags
Attribute source Request
Attribute Blob index tags [Values in key]
Key {keyName}
Operator StringEquals
Value {keyValue}

Screenshot of condition editor in Azure portal showing new blobs must include a blob index tag.

Example: Existing blobs must have blob index tag keys

This condition requires that any existing blobs be tagged with at least one of the allowed blob index tag keys: Project or Program. This condition is useful for adding governance to existing blobs.

There are two actions that allow you to update tags on existing blobs, so you must target both. You must add this condition to any role assignments that include one of the following actions:

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing existing blobs must have blob index tag keys.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Write to a blob with blob index tags
Write blob index tags
Attribute source Request
Attribute Blob index tags [Keys]
Operator ForAllOfAnyValues:StringEquals
Value {keyName1}
{keyName2}

Screenshot of condition editor in Azure portal showing existing blobs must have blob index tag keys.

Example: Existing blobs must have a blob index tag key and values

This condition requires that any existing blobs to have a blob index tag key of Project and values of Cascade, Baker, or Skagit. This condition is useful for adding governance to existing blobs.

There are two actions that allow you to update tags on existing blobs, so you must target both. You must add this condition to any role assignments that include one of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing existing blobs must have a blob index tag key and values.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Write to a blob with blob index tags
Write blob index tags
Attribute source Request
Attribute Blob index tags [Keys]
Operator ForAnyOfAnyValues:StringEquals
Value {keyName}
Operator And
Expression 2
Attribute source Request
Attribute Blob index tags [Values in key]
Key {keyName}
Operator ForAllOfAnyValues:StringEquals
Value {keyValue1}
{keyValue2}
{keyValue3}

Screenshot of condition editor in Azure portal showing existing blobs must have a blob index tag key and values.

Blob container names or paths

This section includes examples showing how to restrict access to objects based on container name or blob path.

Example: Read, write, or delete blobs in named containers

This condition allows users to read, write, or delete blobs in storage containers named blobs-example-container. This condition is useful for sharing specific storage containers with other users in a subscription.

There are five actions for read, write, and delete of existing blobs. You must add this condition to any role assignments that include one of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.
Add if the storage accounts included in this condition have hierarchical namespace enabled or might be enabled in the future.

Suboperations aren't used in this condition because the suboperation is needed only when conditions are authored based on tags.

Diagram of condition showing read, write, or delete blobs in named containers.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Delete a blob
Read a blob
Write to a blob
Create a blob or snapshot, or append data
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Container name
Operator StringEquals
Value {containerName}

Screenshot of condition editor in Azure portal showing read, write, or delete blobs in named containers.

Example: Read blobs in named containers with a path

This condition allows read access to storage containers named blobs-example-container with a blob path of readonly/*. This condition is useful for sharing specific parts of storage containers for read access with other users in the subscription.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.
Add if the storage accounts included in this condition have hierarchical namespace enabled or might be enabled in the future.

Diagram of condition showing read access to blobs in named containers with a path.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Container name
Operator StringEquals
Value {containerName}
Expression 2
Operator And
Attribute source Resource
Attribute Blob path
Operator StringLike
Value {pathString}

Screenshot of condition editor in Azure portal showing read access to blobs in named containers with a path.

Example: Read or list blobs in named containers with a path

This condition allows read access and also list access to storage containers named blobs-example-container with a blob path of readonly/*. Condition #1 applies to read actions excluding list blobs. Condition #2 applies to list blobs. This condition is useful for sharing specific parts of storage containers for read or list access with other users in the subscription.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.
Add if the storage accounts included in this condition have hierarchical namespace enabled or might be enabled in the future.

Diagram of condition showing read and list access to blobs in named containers with a path.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Note

The Azure portal uses prefix='' to list blobs from container's root directory. After the condition is added with the list blobs operation using prefix StringStartsWith 'readonly/', targeted users won't be able to list blobs from container's root directory in the Azure portal.

Condition #1 Setting
Actions Read a blob
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Container name
Operator StringEquals
Value {containerName}
Expression 2
Operator And
Attribute source Resource
Attribute Blob path
Operator StringStartsWith
Value {pathString}
Condition #2 Setting
Actions List blobs
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Container name
Operator StringEquals
Value {containerName}
Expression 2
Operator And
Attribute source Request
Attribute Blob prefix
Operator StringStartsWith
Value {pathString}

Example: Write blobs in named containers with a path

This condition allows a partner (a Microsoft Entra guest user) to drop files into storage containers named Contosocorp with a path of uploads/contoso/*. This condition is useful for allowing other users to put data in storage containers.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.
Add if the storage accounts included in this condition have hierarchical namespace enabled or might be enabled in the future.

Diagram of condition showing write access to blobs in named containers with a path.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Write to a blob
Create a blob or snapshot, or append data
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Container name
Operator StringEquals
Value {containerName}
Expression 2
Operator And
Attribute source Resource
Attribute Blob path
Operator StringLike
Value {pathString}

Screenshot of condition editor in Azure portal showing write access to blobs in named containers with a path.

Example: Read blobs with a blob index tag and a path

This condition allows a user to read blobs with a blob index tag key of Program, a value of Alpine, and a blob path of logs*. The blob path of logs* also includes the blob name.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing read access to blobs with a blob index tag and a path.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
Attribute source Resource
Attribute Blob index tags [Values in key]
Key {keyName}
Operator StringEquals
Value {keyValue}

Screenshot of condition 1 editor in Azure portal showing read access to blobs with a blob index tag and a path.

Condition #2 Setting
Actions Read a blob
Attribute source Resource
Attribute Blob path
Operator StringLike
Value {pathString}

Screenshot of condition 2 editor in Azure portal showing read access to blobs with a blob index tag and a path.

Blob container metadata

Example: Read blobs in container with specific metadata

This condition allows users to read blobs in blob containers with a specific metadata key/value pair.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
Attribute source Resource
Attribute Container metadata
Operator StringEquals
Value {containerName}

Screenshot of condition editor in Azure portal showing read blob in container with specific metadata.

Example: Write or delete blobs in container with specific metadata

This condition allows users to write or delete blobs in blob containers with a specific metadata key/value pair.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Write to a blob
Delete a blob
Attribute source Resource
Attribute Container metadata
Operator StringEquals
Value {containerName}

Screenshot of condition editor in Azure portal showing write and delete blob in container with specific metadata.

Blob versions or blob snapshots

This section includes examples showing how to restrict access to objects based on the blob version or snapshot.

Example: Read only current blob versions

This condition allows a user to only read current blob versions. The user can't read other blob versions.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing read access to current blob version only.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Is Current Version
Operator BoolEquals
Value True

Example: Read current blob versions and a specific blob version

This condition allows a user to read current blob versions as well as read blobs with a version ID of 2022-06-01T23:38:32.8883645Z. The user can't read other blob versions. The Version ID attribute is available only for storage accounts where hierarchical namespace isn't enabled.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Diagram of condition showing read access to a specific blob version.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
Attribute source Request
Attribute Version ID
Operator DateTimeEquals
Value <blobVersionId>
Expression 2
Operator Or
Attribute source Resource
Attribute Is Current Version
Operator BoolEquals
Value True

Example: Delete old blob versions

This condition allows a user to delete versions of a blob that are older than 06/01/2022 to perform cleanup. The Version ID attribute is available only for storage accounts where hierarchical namespace isn't enabled.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action

Diagram of condition showing delete access to old blob versions.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Delete a blob
Delete a version of a blob
Attribute source Request
Attribute Version ID
Operator DateTimeLessThan
Value <blobVersionId>

Example: Read current blob versions and any blob snapshots

This condition allows a user to read current blob versions and any blob snapshots. The Version ID attribute is available only for storage accounts where hierarchical namespace isn't enabled. The Snapshot attribute is available for storage accounts where hierarchical namespace isn't enabled and currently in preview for storage accounts where hierarchical namespace is enabled.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing read access to current blob versions and any blob snapshots.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Request
Attribute Snapshot
Exists Checked
Expression 2
Operator Or
Attribute source Resource
Attribute Is Current Version
Operator BoolEquals
Value True

Example: Allow list blob operation to include blob metadata, snapshots, or versions

This condition allows a user to list blobs in a container and include metadata, snapshot, and version information. The List blobs include attribute is available for storage accounts where hierarchical namespace isn't enabled.

Note

List blobs include is a request attribute, and works by allowing or restricting values in the include parameter when calling the List Blobs operation. The values in the include parameter are compared against the values specified in the condition using cross product comparison operators. If the comparison evaluates to true, the List Blobs request is allowed. If the comparison evaluates to false, the List Blobs request is denied.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions List blobs
Attribute source Request
Attribute List blobs include
Operator ForAllOfAnyValues:StringEqualsIgnoreCase
Value {'metadata', 'snapshots', 'versions'}

Screenshot of condition editor in Azure portal showing a condition to allow a user to list blobs in a container and include metadata, snapshot, and version information.

Example: Restrict list blob operation to not include blob metadata

This condition restricts a user from listing blobs when metadata is included in the request. The List blobs include attribute is available for storage accounts where hierarchical namespace isn't enabled.

Note

List blobs include is a request attribute, and works by allowing or restricting values in the include parameter when calling the List Blobs operation. The values in the include parameter are compared against the values specified in the condition using cross product comparison operators. If the comparison evaluates to true, the List Blobs request is allowed. If the comparison evaluates to false, the List Blobs request is denied.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions List blobs
Attribute source Request
Attribute List blobs include
Operator ForAllOfAllValues:StringNotEquals
Value {'metadata'}

Screenshot of condition editor in Azure portal showing a condition to restrict a user from listing blobs when metadata is included in the request.

Hierarchical namespace

This section includes examples showing how to restrict access to objects based on whether hierarchical namespace is enabled for a storage account.

Example: Read only storage accounts with hierarchical namespace enabled

This condition allows a user to only read blobs in storage accounts with hierarchical namespace enabled. This condition is applicable only at resource group scope or higher.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing read access to storage accounts with hierarchical namespace enabled.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
All data operations for accounts with hierarchical namespace enabled (if applicable)
Attribute source Resource
Attribute Is hierarchical namespace enabled
Operator BoolEquals
Value True

Encryption scope

This section includes examples showing how to restrict access to objects with an approved encryption scope.

Example: Read blobs with specific encryption scopes

This condition allows a user to read blobs encrypted with encryption scope validScope1 or validScope2.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Diagram of condition showing read access to blobs with encryption scope validScope1 or validScope2.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
Attribute source Resource
Attribute Encryption scope name
Operator ForAnyOfAnyValues:StringEquals
Value <scopeName>

Example: Read or write blobs in named storage account with specific encryption scope

This condition allows a user to read or write blobs in a storage account named sampleaccount and encrypted with encryption scope ScopeCustomKey1. If blobs aren't encrypted or decrypted with ScopeCustomKey1, the request returns forbidden.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

Note

Since encryption scopes for different storage accounts could be different, it's recommended to use the storageAccounts:name attribute with the encryptionScopes:name attribute to restrict the specific encryption scope to be allowed.

Diagram of condition showing read or write access to blobs in sampleaccount storage account with encryption scope ScopeCustomKey1.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob
Write to a blob
Create a blob or snapshot, or append data
Attribute source Resource
Attribute Account name
Operator StringEquals
Value <accountName>
Expression 2
Operator And
Attribute source Resource
Attribute Encryption scope name
Operator ForAnyOfAnyValues:StringEquals
Value <scopeName>

Principal attributes

This section includes examples showing how to restrict access to objects based on custom security principals.

Example: Read or write blobs based on blob index tags and custom security attributes

This condition allows read or write access to blobs if the user has a custom security attribute that matches the blob index tag.

For example, if Brenda has the attribute Project=Baker, she can only read or write blobs with the Project=Baker blob index tag. Similarly, Chandra can only read or write blobs with Project=Cascade.

You must add this condition to any role assignments that include the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

For more information, see Allow read access to blobs based on tags and custom security attributes.

Diagram of condition showing read or write access to blobs based on blob index tags and custom security attributes.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob conditions
Attribute source Principal
Attribute <attributeset>_<key>
Operator StringEquals
Option Attribute
Attribute source Resource
Attribute Blob index tags [Values in key]
Key <key>
Condition #2 Setting
Actions Write to a blob with blob index tags
Write to a blob with blob index tags
Attribute source Principal
Attribute <attributeset>_<key>
Operator StringEquals
Option Attribute
Attribute source Request
Attribute Blob index tags [Values in key]
Key <key>

Example: Read blobs based on blob index tags and multi-value custom security attributes

This condition allows read access to blobs if the user has a custom security attribute with any values that matches the blob index tag.

For example, if Chandra has the Project attribute with the values Baker and Cascade, she can only read blobs with the Project=Baker or Project=Cascade blob index tag.

You must add this condition to any role assignments that include the following action.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

For more information, see Allow read access to blobs based on tags and custom security attributes.

Diagram of condition showing read access to blobs based on blob index tags and multi-value custom security attributes.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the Azure portal.

Condition #1 Setting
Actions Read a blob conditions
Attribute source Resource
Attribute Blob index tags [Values in key]
Key <key>
Operator ForAnyOfAnyValues:StringEquals
Option Attribute
Attribute source Principal
Attribute <attributeset>_<key>

Environment attributes

This section includes examples showing how to restrict access to objects based on the network environment or the current date and time.

Example: Allow read access to blobs after a specific date and time

This condition allows read access to blob container container1 only after 1 PM on May 1, 2023 Universal Coordinated Time (UTC).

There are two potential actions for reading existing blobs. To make this condition effective for principals that have multiple role assignments, you must add this condition to all role assignments that include any of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Add action

Select Add action, then select only the Read a blob suboperation as shown in the following table.

Action Suboperation
All read operations Read a blob

Don't select the top-level All read operations action or any other suboperations as shown in the following image:

Screenshot of condition editor in Azure portal showing selection of just the read operation.

Build expression

Use the values in the following table to build the expression portion of the condition:

Setting Value
Attribute source Resource
Attribute Container name
Operator StringEquals
Value container1
Logical operator 'AND'
Attribute source Environment
Attribute UtcNow
Operator DateTimeGreaterThan
Value 2023-05-01T13:00:00.000Z

The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.

Screenshot of the condition editor in the Azure portal showing read access allowed after a specific date and time.

Example: Allow access to blobs in specific containers from a specific subnet

This condition allows read, write, add and delete access to blobs in container1 only from subnet default on virtual network virtualnetwork1. To use the Subnet attribute in this example, the subnet must have service endpoints enabled for Azure Storage.

There are five potential actions for read, write, add and delete access to existing blobs. To make this condition effective for principals that have multiple role assignments, you must add this condition to all role assignments that include any of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Add action

Select Add action, then select only the top-level actions shown in the following table.

Action Suboperation
All read operations n/a
Write to a blob n/a
Create a blob or snapshot, or append data n/a
Delete a blob n/a

Don't select any individual suboperations as shown in the following image:

Screenshot of condition editor in Azure portal showing selection of read, write, add and delete operations.

Build expression

Use the values in the following table to build the expression portion of the condition:

Setting Value
Attribute source Resource
Attribute Container name
Operator StringEquals
Value container1
Logical operator 'AND'
Attribute source Environment
Attribute Subnet
Operator StringEqualsIgnoreCase
Value /subscriptions/<your subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/virtualnetwork1/subnets/default

The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.

Screenshot of the condition editor in the Azure portal showing read access to specific containers allowed from a specific subnet.

This condition requires requests to read blobs where blob index tag sensitivity has a value of high to be over a private link (any private link). This means all attempts to read highly sensitive blobs from the public internet won't be allowed. Users can read blobs from the public internet that have sensitivity set to some value other than high.

A truth table for this ABAC sample condition follows:

Action  Sensitivity Private link  Access  
Read a blob  high   Yes  Allowed
Read a blob  high  No Not Allowed
Read a blob  NOT high  Yes  Allowed
Read a blob NOT high  No Allowed

There are two potential actions for reading existing blobs. To make this condition effective for principals that have multiple role assignments, you must add this condition to all role assignments that include any of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the visual condition editor in the Azure portal.

Add action

Select Add action, then select only the Read a blob suboperation as shown in the following table.

Action Suboperation
All read operations Read a blob

Don't select the top-level All read operations action of any other suboperations as shown in the following image:

Screenshot of condition editor in Azure portal showing selection of just the read operation.

Build expression

Use the values in the following table to build the expression portion of the condition:

Group Setting Value
Group #1
Attribute source Resource
Attribute Blob index tags [Values in key]
Key sensitivity
Operator StringEquals
Value high
Logical operator 'AND'
Attribute source Environment
Attribute Is private link
Operator BoolEquals
Value True
End of Group #1
Logical operator 'OR'
Attribute source Resource
Attribute Blob index tags [Values in key]
Key sensitivity
Operator StringNotEquals
Value high

The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.

Screenshot of the condition editor in the Azure portal showing read access requiring any private link for sensitive data.

Example: Allow access to a container only from a specific private endpoint

This condition requires that all read, write, add and delete operations for blobs in a storage container named container1 be made through a private endpoint named privateendpoint1. For all other containers not named container1, access doesn't need to be through the private endpoint.

There are five potential actions for read, write and delete of existing blobs. To make this condition effective for principals that have multiple role assignments, you must add this condition to all role assignments that include any of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.
Add if the storage accounts included in this condition have hierarchical namespace enabled or might be enabled in the future.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the visual condition editor in the Azure portal.

Add action

Select Add action, then select only the top-level actions shown in the following table.

Action Suboperation
All read operations n/a
Write to a blob n/a
Create a blob or snapshot, or append data n/a
Delete a blob n/a

Don't select any individual suboperations as shown in the following image:

Screenshot of condition editor in Azure portal showing selection of read, write, add and delete operations.

Build expression

Use the values in the following table to build the expression portion of the condition:

Group Setting Value
Group #1
Attribute source Resource
Attribute Container name
Operator StringEquals
Value container1
Logical operator 'AND'
Attribute source Environment
Attribute Private endpoint
Operator StringEqualsIgnoreCase
Value /subscriptions/<your subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/privateEndpoints/privateendpoint1
End of Group #1
Logical operator 'OR'
Attribute source Resource
Attribute Container name
Operator StringNotEquals
Value container1

The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.

Screenshot of condition editor in Azure portal showing read, write, or delete blobs in named containers with private endpoint environment attribute.

Example: Allow read access to highly sensitive blob data only from a specific private endpoint and by users tagged for access

This condition requires that blobs with index tag sensitivity set to high can be read only by users that have a matching value for their sensitivity security attribute. Additionally, they must be accessed over a private endpoint named privateendpoint1. Blobs that have a different value for the sensitivity tag can be accessed over other endpoints or the Internet.

There are two potential actions for reading existing blobs. To make this condition effective for principals that have multiple role assignments, you must add this condition to all role assignments that include any of the following actions.

Action Notes
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Add if role definition includes this action, such as Storage Blob Data Owner.

The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the Visual editor tab and the Code editor tabs to view the examples for your preferred portal editor.

Here are the settings to add this condition using the visual condition editor in the Azure portal.

Add action

Select Add action, then select only the Read a blob suboperation as shown in the following table.

Action Suboperation
All read operations Read a blob

Don't select the top-level action as shown in the following image:

Screenshot of condition editor in Azure portal showing selection of read a blob operation.

Build expression

Use the values in the following table to build the expression portion of the condition:

Group Setting Value
Group #1
Attribute source Principal
Attribute <attributeset>_<key>
Operator StringEquals
Option Attribute
Logical operator 'AND'
Attribute source Resource
Attribute Blob index tags [Values in key]
Key <key>
Logical operator 'AND'
Attribute source Environment
Attribute Private endpoint
Operator StringEqualsIgnoreCase
Value /subscriptions/<your subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/privateEndpoints/privateendpoint1
End of Group #1
Logical operator 'OR'
Attribute source Resource
Attribute Blob index tags [Values in key]
Key sensitivity
Operator StringNotEquals
Value high

The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.

Screenshot of condition editor in Azure portal showing read access allowed over a specific private endpoint for tagged users.

Next steps