Actions and attributes for Azure Key Vault ABAC conditions (preview)

This article describes the supported actions, attributes, and operators that you can use in conditions on Azure role assignments for Azure Key Vault. For an overview of how role assignment conditions work, see What is Azure attribute-based access control (Azure ABAC)?. For the list of Key Vault data actions that a specific permission affects, see the Azure RBAC for Key Vault data plane operations guide.

Overview

Azure ABAC for Key Vault builds on Azure RBAC by adding conditions to role assignments. Azure evaluates each condition at runtime against the attributes of the resource being accessed or the incoming request, and either allows or denies the request based on comparison operators.

The benefits of using role assignment conditions for Key Vault are:

• Finer-grained access to secrets. Restrict a principal to secrets whose names match a specific pattern (for example, app-* or team-prod-*), or to specific key vaults by vault name.
• Fewer role assignments to manage. Use a single condition-gated role assignment for a security group instead of many individual assignments that model the same permissions. ABAC helps you scale role management - it doesn't grant permissions that a role assignment doesn't already grant.
• Extends existing Azure RBAC. ABAC layers on top of your existing role assignments. You don't have to replace RBAC to use it.

In this preview, ABAC for Key Vault applies only to secret data actions and supports two attributes: the vault name and the secret name. Key data actions, certificate data actions, tag-based attributes, token attributes, and built-in Key Vault ABAC conditions on any role aren't included.

To use ABAC conditions, the key vault's permission model must be set to Azure RBAC. For background, see Azure RBAC vs. access policies and Prepare for Key Vault API version 2026-02-01 and later.

Condition format

Conditions use the following general format:

@Resource[<ResourceType>:<AttributeName>] <Operator> '<Value>'

The condition version must be set to 2.0. For the complete grammar, see Azure role assignment condition format and syntax.

Supported operators

Azure Key Vault ABAC conditions support all the string comparison operators defined in the Azure ABAC condition format. For the full list of operators and their behavior, see String comparison operators.

Azure Key Vault actions

You can apply ABAC conditions to the following Key Vault secret data actions. Each subsection describes the action, the underlying DataAction, the attribute source it evaluates (Resource or Request), and an example condition.

Get secret

Read secret metadata

Set secret

Update secret

Delete secret

Backup secret

Restore secret

Recover secret

Purge secret

Attribute sources

Attributes describe properties evaluated at request time. Resource attributes describe the resource being accessed. Request attributes describe the incoming request when the resource might not yet exist (for example, during setSecret or restore).

Vault name

Use this attribute to scope access to key vaults whose names match a given pattern. When you apply a condition at subscription or resource group scope, Azure evaluates the vault name for every vault the principal attempts to access.

Example conditions:

@Resource[Microsoft.KeyVault/vaults:name] StringStartsWith 'prod-'
@Resource[Microsoft.KeyVault/vaults:name] StringEquals 'sample-vault'
@Resource[Microsoft.KeyVault/vaults:name] StringLike 'team-*-prod'

Secret name (Resource)

Use this attribute when the secret already exists at evaluation time.

Example conditions:

@Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'test-app'
@Resource[Microsoft.KeyVault/vaults/secrets:name] StringLike 'api-key-*'

Secret name (Request)

Use this attribute when the secret might not yet exist at evaluation time, such as during creation or restore.

Example conditions:

@Request[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'app-'
@Request[Microsoft.KeyVault/vaults/secrets:name] StringLike 'config-*'

Roles that support ABAC conditions

You can apply ABAC conditions to any role that includes Key Vault secret dataActions. Roles that only contain control-plane actions (such as Owner or Policy Administrator) don't support ABAC conditions because Azure evaluates conditions exclusively on data-plane operations. In this preview, no built-in role includes a preassigned Key Vault ABAC condition - you author the condition when you create the role assignment.

The following built-in roles include secret data actions and support ABAC conditions in this preview. For the full role definitions and IDs, see Azure built-in roles for Key Vault data plane operations.

Condition examples

The following examples show common ABAC patterns for Key Vault secrets. For more on the condition syntax, see Azure role assignment condition format and syntax.

Example: Restrict read access to secrets with a name prefix

Allow a principal to read only secrets whose names start with test-app:

• Role: Key Vault Secrets User
• Scope: Key vault resource
• Condition:

(
  !(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'})
  OR
  (
    @Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'test-app'
  )
)

Behavior:

• Allowed: Reading test-app-secret1.
• Denied (ForbiddenByRbac): Reading test-db-password.

Example: Restrict access to secrets in specific vaults by vault name prefix

Allow a principal to read secrets only in vaults whose names start with kv-prod:

• Role: Key Vault Secrets User
• Scope: Subscription
• Condition:

@Resource[Microsoft.KeyVault/vaults:name] StringStartsWith 'kv-prod'

Behavior:

• Allowed: Access to kv-prod-1.
• Denied: Access to test-kv.

Example: Restrict newly created secrets to a name prefix

Allow a principal to create secrets only when the secret name starts with app-. Because the secret doesn't yet exist at evaluation time, use the Request attribute:

• Role: Key Vault Secrets Officer
• Scope: Key vault resource
• Condition:

(
  !(ActionMatches{'Microsoft.KeyVault/vaults/secrets/setSecret/action'})
  OR
  (
    @Request[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'app-'
  )
)

Example: Combine vault and secret name conditions

Restrict a principal to read only secrets that start with api- in vaults whose names start with kv-prod:

• Role: Key Vault Secrets User
• Scope: Subscription
• Condition:

(
  !(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'})
  OR
  (
    @Resource[Microsoft.KeyVault/vaults:name] StringStartsWith 'kv-prod'
    AND
    @Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'api-'
  )
)

Related content

• Add role assignment conditions for Key Vault secrets by using Azure CLI (preview)
• Add role assignment conditions for Key Vault secrets by using Azure PowerShell (preview)
• What is Azure attribute-based access control (Azure ABAC)?
• Azure role assignment condition format and syntax
• Provide access to Key Vault keys, certificates, and secrets with Azure RBAC
• Troubleshoot Azure role assignment conditions
• Troubleshoot Key Vault access issues
• Prepare for Key Vault API version 2026-02-01 and later