Adicionar condições de atribuição de funções para segredos do Key Vault usando CLI do Azure (pré-visualização)

Note

O Azure ABAC para o Key Vault está em pré-visualização. Alguns aspetos podem mudar antes da disponibilidade geral. Para termos de pré-visualização, consulte os termos suplementares de utilização.

Na maioria dos casos, uma atribuição de funções no Azure concede as permissões necessárias para os recursos do Azure. Em alguns casos, pode querer um controlo de acesso mais detalhado adicionando uma condição de atribuição de funções.

Este artigo mostra como usar o CLI do Azure para adicionar uma condição de controlo de acesso baseado em atributos do Azure (Azure ABAC) a uma atribuição de funções no Key Vault, de modo que um principal só possa ler segredos cujos nomes comecem com um prefixo específico.

Para o conjunto completo de ações e atributos suportados, veja Ações e atributos para as condições ABAC do Azure Key Vault (pré-visualização).

Importante

As condições ABAC só funcionam quando o modelo de permissões do cofre de chaves está definido para controlo de acesso baseado em funções no Azure. As políticas de acesso ao cofre antigas não suportam condições.

Pré-requisitos

Para obter informações sobre os pré-requisitos para adicionar ou editar condições de atribuição de função, consulte Pré-requisitos de condições.
O cofre de chaves alvo deve ter o seu modelo de permissões definido para controlo de acesso baseado em funções no Azure.
CLI do Azure instalado localmente, ou use o Azure Cloud Shell.

Condition

Neste artigo, restringe o acesso a segredos cujos nomes começam por test-app. Se o utilizador tentar ler um segredo sem o test-app prefixo de nome, o acesso não é permitido.

Eis como se manifesta a condição:

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

Utilize az login e siga as instruções para iniciar sessão como Administrador de Acesso de Utilizador ou Proprietário.
```
az login
```
Utilize az account show para obter o seu ID da subscrição.
```
az account show
```
Inicialize uma variável com o seu ID de subscrição.
```
subscriptionId="<subscriptionId>"
```

Passo 2: Criar um utilizador

Utilize az ad user create para criar um utilizador ou para localizar um utilizador existente. Este artigo usa o User1 como exemplo.
Inicialize uma variável com o ID do objeto do utilizador.
```
userObjectId="<userObjectId>"
```

Passo 3: Configurar o cofre de chaves

Note

Os comandos neste artigo usam a sintaxe Bash (variable="value" e $variable). Se os executares a partir do PowerShell do Windows ou PowerShell 7, usa a sintaxe das variáveis do PowerShell em vez de ($variable = "value") e ignora a nota de expansão do histórico do Bash no Passo 4. Os az comandos em si são idênticos em ambos os shells.

Use o az-keyvault create para criar um cofre de chaves que utilize o Azure RBAC como modelo de permissões.

az keyvault create --name "<keyVaultName>" --resource-group "<resourceGroup>" --location "<location>" --enable-rbac-authorization true

Atribui a ti próprio uma função de plano de dados do Key Vault para que possas criar segredos. Quando um vault usa Azure RBAC, funções de plano de controlo como Proprietário ou Contribuinte não concedem acesso a valores secretos. Sem uma função de plano de dados, az keyvault secret set falha com o erro (Forbidden) Caller is not authorized to perform action on resource na ação Microsoft.KeyVault/vaults/secrets/setSecret/action.
```
myObjectId=$(az ad signed-in-user show --query id -o tsv)
vaultScope="/subscriptions/$subscriptionId/resourceGroups/<resourceGroup>/providers/Microsoft.KeyVault/vaults/<keyVaultName>"
az role assignment create --assignee-object-id $myObjectId --assignee-principal-type User --role "Key Vault Secrets Officer" --scope $vaultScope
```
Note

Use o Key Vault Secrets Officer para criar e gerir valores secretos, ou o Key Vault Administrator para acesso completo ao plano de dados. Key Vault Secrets User tem acesso só de leitura. Depois de atribuir um papel, espere de 1 a 5 minutos pela propagação antes de executar o próximo comando. Um Forbidden erro imediatamente após a atribuição normalmente significa que a função ainda não se propagou.
Use o conjunto secreto do az-keyvault para criar um segredo chamado test-app-secret1.
```
az keyvault secret set --vault-name "<keyVaultName>" --name "test-app-secret1" --value "<secretValue>"
```
Note

O nome secreto é o atributo de recurso avaliado pela condição. Escolha nomes que reflitam o prefixo ao qual pretende restringir o acesso.

Crie um segundo segredo chamado test-db-password.

az keyvault secret set --vault-name "<keyVaultName>" --name "test-db-password" --value "<secretValue>"

Inicialize variáveis com os nomes que usaste.

resourceGroup="<resourceGroup>"
keyVaultName="<keyVaultName>"
secretNameAllowed="test-app-secret1"
secretNameDenied="test-db-password"

Passo 4: Atribuir um papel com uma condição

Inicialize as variáveis de papel de utilizador do Key Vault Secrets.

roleDefinitionName="Key Vault Secrets User"
roleDefinitionId="4633458b-17de-408a-b874-0445c86b69e6"

Inicialize o âmbito do grupo de recursos.

scope="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup"

Inicialize a condição.
```
condition="((!(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'})) OR (@Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'test-app'))"
```
Para a Get secret ação, esta condição permite ler um segredo apenas se o seu nome começar por test-app. Todas as outras ações (não-getSecret) não são afetadas.
Note

A condição deve ser uma cadeia de caracteres numa única linha. As condições de múltiplas linhas são rejeitadas. Se criar a condição em várias linhas, converta-a primeiro para uma única linha. Por exemplo:
```
condition=$(echo "$condition" | tr -s ' \n' ' ')
```
No Bash, se a expansão de histórico estiver ativada, podes ver bash: !: event not found por causa do ponto de exclamação (!) na condição. Desative a expansão de histórico com set +H, e depois reative-a mais tarde com set -H.

Inicialize a versão e a descrição da condição.

conditionVersion="2.0"
description="Read access to secrets whose names start with test-app"

Utilize az role assignment create para atribuir a função Key Vault Secrets User com uma condição ao utilizador ao nível do grupo de recursos.

az role assignment create --assignee-object-id $userObjectId --scope $scope --role $roleDefinitionId --description "$description" --condition "$condition" --condition-version $conditionVersion

Exemplo de saída:

{
  "canDelegate": null,
  "condition": "((!(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'})) OR (@Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'test-app'))",
  "conditionVersion": "2.0",
  "description": "Read access to secrets whose names start with test-app",
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}",
  "name": "{roleAssignmentId}",
  "principalId": "{userObjectId}",
  "principalType": "User",
  "resourceGroup": "{resourceGroup}",
  "roleDefinitionId": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/4633458b-17de-408a-b874-0445c86b69e6",
  "scope": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}",
  "type": "Microsoft.Authorization/roleAssignments"
}

Passo 5: Testar a condição

Abre uma nova janela de comandos.
Utilize az login para iniciar sessão como User1.
```
az login
```

Inicializa as variáveis que usaste anteriormente.

keyVaultName="<keyVaultName>"
secretNameAllowed="test-app-secret1"
secretNameDenied="test-db-password"

Utilize az keyvault secret show para tentar ler o segredo ao qual foi negado o acesso.

az keyvault secret show --vault-name $keyVaultName --name $secretNameDenied

Exemplo de saída. Note que a leitura falha devido à condição:

(Forbidden) Caller is not authorized to perform action on resource.
If role assignments, deny assignments or role definitions changed
recently, please observe propagation time.
...
Code: ForbiddenByRbac

Leia o segredo cujo nome começa por test-app.

az keyvault secret show --vault-name $keyVaultName --name $secretNameAllowed

Exemplo de saída. Note que pode ler o segredo porque o seu nome começa por test-app:

{
  "attributes": { },
  "contentType": null,
  "id": "https://<keyVaultName>.vault.azure.net/secrets/test-app-secret1/<version>",
  "name": "test-app-secret1",
  "tags": {},
  "value": "<secretValue>"
}

Passo 6: (Opcional) Editar a condição

Na janela de comandos original, usa a lista de atribuição de funções do az para obter a atribuição de funções que adicionaste.
```
az role assignment list --assignee $userObjectId --resource-group $resourceGroup
```

Crie um ficheiro JSON com o seguinte formato e atualize as condition propriedades e description para permitir também segredos cujos nomes comecem por api-.

{
  "canDelegate": null,
  "condition": "((!(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'})) OR (@Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'test-app' OR @Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'api-'))",
  "conditionVersion": "2.0",
  "description": "Read access to secrets whose names start with test-app or api-",
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}",
  "name": "{roleAssignmentId}",
  "principalId": "{userObjectId}",
  "principalName": "user1@contoso.com",
  "principalType": "User",
  "resourceGroup": "{resourceGroup}",
  "roleDefinitionId": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/4633458b-17de-408a-b874-0445c86b69e6",
  "roleDefinitionName": "Key Vault Secrets User",
  "scope": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}",
  "type": "Microsoft.Authorization/roleAssignments"
}

Utilize az role assignment update para atualizar a condição.

az role assignment update --role-assignment "./path/roleassignment.json"

Etapa 7: Limpar recursos

Utilize az role assignment delete para remover a atribuição de função e a condição.

az role assignment delete --assignee $userObjectId --role "$roleDefinitionName" --resource-group $resourceGroup

Elimine o Key Vault que criou.
Apaga o utilizador que criaste.

Comentários

Esta página foi útil?

Last updated on 2026-07-18