Azure RBAC Conditions: Attribute-Based Access Control

What RBAC conditions are

Standard RBAC asks three questions: who is the principal, what role do they have, and what scope does it apply to. Conditions add a fourth question: do the attributes of this specific request match the condition expression?

Without conditions, if you assign Storage Blob Data Reader to a user at the storage account scope, they can read every blob in every container in that account. With a condition, you can restrict that same assignment so it only allows reads on blobs in containers whose names start with prod-, or only on blobs that have a specific index tag.

Conditions are an extension of RBAC, not a replacement. They sit on top of the standard role assignment structure — the condition and conditionVersion fields in the role assignment JSON hold the expression and the version of the condition language being used.

Conditions are part of what Microsoft calls Attribute-Based Access Control (ABAC). Azure’s ABAC implementation uses conditions on RBAC role assignments rather than a separate system.

Supported scenarios

As of 2026, RBAC conditions are supported on a specific set of resource types and action types. The most mature and commonly used scenarios are:

Azure Blob Storage conditions

Blob storage is where conditions are most fully featured. You can write conditions based on:

• Container name — restrict access to specific containers by name or name prefix
• Blob path — restrict access to blobs at specific paths within a container
• Blob index tags — restrict access to blobs that have specific metadata tags (key-value pairs stored in blob index storage)
• Blob prefix — restrict access to blobs whose names start with a given string

Azure Queue Storage conditions

Queue conditions allow filtering by queue name, which is useful when a storage account hosts multiple queues with different sensitivity levels.

Azure Key Vault conditions

Key Vault conditions support filtering by secret name, key name, and certificate name. This lets you grant access to a subset of secrets in a vault without granting access to all secrets — useful when a single Key Vault stores both application configuration secrets and more sensitive credentials.

Condition expression syntax

Azure RBAC conditions use a specific expression language defined in version 2.0 of the condition format. Expressions are written in a format that looks like:

(
  (
    !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  )
  OR
  (
    @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:environment<$key_case_sensitive$>] StringEquals 'production'
  )
)

Let’s break this down:

• ActionMatches — the action this condition applies to. The !(ActionMatches{…}) pattern means “if this is NOT the specified action, allow it unconditionally.” This is the standard wrapper pattern that allows all other actions in the role to work normally. Without this wrapper, a condition on read blobs would accidentally block write operations too.
• @Resource[…] — references an attribute of the resource being accessed. In this case, a blob index tag.
• StringEquals — the comparison operator. Other operators include StringLike (supports wildcards), StringNotEquals, StringStartsWith, and StringEqualsIgnoreCase.
• ‘production’ — the value to compare against.

The overall expression reads as: “For blob read operations, only allow access if the blob has an index tag named environment with the value production. For all other operations included in this role, allow unconditionally.”

Concrete example: read-only access to production-tagged blobs

Here is a realistic use case: you have a reporting service that should only be able to read blobs tagged as belonging to the production environment. Your storage account contains blobs from multiple environments, all in the same container for historical reasons. You want to grant the reporting service read access but prevent it from accidentally (or maliciously) reading staging or development data.

Step 1: Tag your blobs

Blob index tags are metadata you apply to individual blobs (not just containers). Set the tag when uploading:

az storage blob upload \
  --account-name mystorageaccount \
  --container-name reports \
  --name "2026/01/report.parquet" \
  --file report.parquet \
  --tags "environment=production" "team=analytics"

Or add tags to existing blobs:

az storage blob tag set \
  --account-name mystorageaccount \
  --container-name reports \
  --name "2026/01/report.parquet" \
  --tags "environment=production"

Step 2: Write the condition expression

Save this as condition.json:

{
  "conditionVersion": "2.0",
  "condition": "(!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}) OR (@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:environment<$key_case_sensitive$>] StringEquals 'production'))"
}

Step 3: Assign the role with the condition

The az role assignment create command accepts the condition and conditionVersion as separate parameters:

az role assignment create \
  --assignee "reporting-service-object-id" \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions/YOUR_SUB_ID/resourceGroups/data-rg/providers/Microsoft.Storage/storageAccounts/mystorageaccount" \
  --condition "(!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}) OR (@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:environment<\$key_case_sensitive\$>] StringEquals 'production'))" \
  --condition-version "2.0"

Note that the scope here is at the storage account level — conditions cannot be set at a scope broader than the resource where they apply.

What happens when the service makes a request

When the reporting service tries to read a blob:

• Azure checks the role assignment: does the service have Storage Blob Data Reader on this storage account? Yes.
• Azure evaluates the condition: is this a blob read operation? Yes. Does the blob have the tag environment=production? If yes, the read is allowed. If no, the read is denied.

For non-read operations (which Storage Blob Data Reader does not include anyway), the !(ActionMatches{…}) wrapper allows them unconditionally — but since the role does not include write or delete permissions, those operations fail anyway due to the base role restriction.

When conditions are worth the complexity

RBAC conditions add meaningful complexity to your access control configuration. The condition syntax is not intuitive, conditions can be hard to debug, and they require the resource type to support ABAC attributes. Before using conditions, consider simpler alternatives:

When conditions are the right choice

• You have a large number of blobs with varying sensitivity levels in the same container, and restructuring the container layout is not feasible
• You need dynamic access control where the set of accessible resources changes based on resource attributes rather than a fixed list of containers
• You are implementing a pattern where access control tracks a business attribute (like environment or classification) that is already stored as a blob tag

When to use a simpler approach instead

• If you can organize blobs by access level into separate containers, assign the role at container scope instead — this is simpler and better supported by all tools
• If the access pattern is fixed (always this container, never that one), a scoped role assignment at the container level is clearer than a condition
• If the team managing the storage does not have experience with condition syntax, the maintenance burden may outweigh the benefits

Conditions make the most sense when combined with a least privilege strategy for storage resources where restructuring the data layout is impractical.

Key Vault conditions: limiting access by secret name

Key Vault conditions let you restrict a role assignment to specific secrets within a vault. This is useful when a single vault holds both application secrets and more sensitive credentials (like database master passwords) and you want to grant an application access to only its own secrets.

az role assignment create \
  --assignee "app-service-identity-object-id" \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/YOUR_SUB_ID/resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/prod-keyvault" \
  --condition "(!(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'}) OR (@Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'app-myservice-'))" \
  --condition-version "2.0"

This assignment gives the application service access to read any secret whose name starts with app-myservice-, such as app-myservice-db-password or app-myservice-api-key, while blocking access to unrelated secrets in the same vault.