Aggiungere condizioni di assegnazione di ruolo per i segreti di Key Vault usando Azure PowerShell (anteprima)

Nella maggior parte dei casi, un'assegnazione di ruolo di Azure concede le autorizzazioni necessarie per le risorse di Azure. In alcuni casi, potrebbe essere necessario un controllo di accesso più granulare aggiungendo una condizione di assegnazione di ruolo.

Questo articolo illustra come usare Azure PowerShell per aggiungere una condizione di controllo degli accessi in base agli attributi di Azure (Azure ABAC) a un'assegnazione di ruolo di Key Vault, in modo che un'entità di sicurezza possa leggere solo i segreti i cui nomi iniziano con un prefisso specifico.

Per il set completo di azioni e attributi supportati, vedi Azioni e attributi per le condizioni ABAC di Azure Key Vault (anteprima).

Prerequisites

• Per informazioni sui prerequisiti per aggiungere o modificare condizioni di assegnazione di ruolo, vedere Prerequisiti delle condizioni.
• L'insieme di credenziali delle chiavi di destinazione deve avere il modello di autorizzazione impostato su controllo degli accessi in base al ruolo di Azure.
• Azure PowerShell installato in locale o usare Azure Cloud Shell.

Condition

In questo articolo si limita l'accesso ai segreti i cui nomi iniziano con test-app. Se l'utente tenta di leggere un segreto senza il prefisso del test-app nome, l'accesso non è consentito.

Ecco come appare la condizione:

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

Passaggio 1: Installare i prerequisiti

1. Aprire una finestra di PowerShell.

2. Usare Get-InstalledModule per controllare le versioni dei moduli installati.

   Get-InstalledModule -Name Az
   Get-InstalledModule -Name Az.Resources
   Get-InstalledModule -Name Az.KeyVault
   Get-InstalledModule -Name Microsoft.Graph.Users
   

3. Se necessario, usare Install-Module per installare le versioni necessarie dei Azmoduli , Az.Resourcese Az.KeyVault . È necessario il Microsoft.Graph.Users modulo solo se si prevede di creare un nuovo utente con New-MgUser nel passaggio 3. È possibile ignorarlo se si riutilizza un utente esistente.

   Install-Module -Name Az
   Install-Module -Name Az.Resources
   Install-Module -Name Az.KeyVault
   Install-Module -Name Microsoft.Graph.Users
   

4. Chiudere e riaprire PowerShell per aggiornare la sessione.

Passaggio 2: Accedere a Azure

1. Usare Connect-AzAccount e seguire le istruzioni per accedere come amministratore o proprietariodell'accesso utente.

   Connect-AzAccount
   

2. Usare Get-AzSubscription per elencare le sottoscrizioni. Formattare l'output come elenco in modo che gli ID di sottoscrizione completi non siano troncati.

   Get-AzSubscription | Format-List Name, Id, TenantId
   

   In alternativa, visualizzare i risultati in una tabella con una colonna non troncata Id :

   Get-AzSubscription | Format-Table Name, Id, State -AutoSize
   

3. Impostare la sottoscrizione come sottoscrizione attiva.

   $subscriptionId = "<subscriptionId>"
   $context = Get-AzSubscription -SubscriptionId $subscriptionId
   Set-AzContext $context
   

Passaggio 3: Creare un utente

Usare New-MgUser per creare un utente o trovare un utente esistente. Questo articolo usa User1 come esempio.

Connect-MgGraph -Scopes "User.ReadWrite.All"

Inizializzare una variabile con l'ID oggetto dell'utente.

$userObjectId = "<userObjectId>"

Passaggio 4: Configurare Key Vault

1. Usa New-AzKeyVault per creare un insieme di credenziali che usa Azure RBAC come modello di autorizzazioni.

   New-AzKeyVault -Name "<keyVaultName>" -ResourceGroupName "<resourceGroup>" -Location "<location>"
   

   Note

   In Az.KeyVault 6.0.0 e versioni successive, Azure RBAC è il modello di autorizzazioni predefinito, quindi non è necessario specificare uno switch aggiuntivo. L'opzione -EnableRbacAuthorization è stata rimossa nella versione 6.0.0. Se lo includi, il comando ora fallisce con A parameter cannot be found that matches parameter name 'EnableRbacAuthorization'. Usare -DisableRbacAuthorization solo se si vuole invece usare in modo esplicito il modello di criteri di accesso all'insieme di credenziali legacy.

   Se si usa una versione di Az.KeyVault precedente (anteriore alla 6.0.0), RBAC non è predefinito, quindi è necessario aggiungere il flag -EnableRbacAuthorization:

   New-AzKeyVault -Name "<keyVaultName>" -ResourceGroupName "<resourceGroup>" -Location "<location>" -EnableRbacAuthorization
   

   Controllare la versione installata con Get-InstalledModule -Name Az.KeyVault.

2. Concedere a sé stessi un ruolo del piano dati di Key Vault in modo da poter creare segreti. Quando un insieme di credenziali usa Azure RBAC (impostazione predefinita), i ruoli del piano di controllo, ad esempio Proprietario o Collaboratore, non concedono l'accesso ai valori dei segreti. Senza un ruolo di piano dati, Set-AzKeyVaultSecret non riesce con Operation returned an invalid status code 'Forbidden' e Assignment: (not found).

   # Object ID of the signed-in user (use -UserPrincipalName "you@tenant.com" if this returns nothing)
   $me = (Get-AzADUser -SignedIn).Id
   
   # Scope the assignment to the vault you just created
   $vaultScope = "/subscriptions/$subscriptionId/resourceGroups/<resourceGroup>/providers/Microsoft.KeyVault/vaults/<keyVaultName>"
   
   New-AzRoleAssignment -ObjectId $me `
     -RoleDefinitionName "Key Vault Secrets Officer" `
     -Scope $vaultScope
   

   Note

   Usa Key Vault Secrets Officer per creare e gestire i valori dei segreti oppure Key Vault Administrator per l'accesso completo al piano dati. Key Vault Secrets User è di sola lettura. Dopo aver assegnato un ruolo, attendere 1-5 minuti per la propagazione prima di eseguire il comando successivo. Un Forbidden errore subito dopo l'assegnazione indica in genere che il ruolo non è ancora stato propagato.

3. Usare Set-AzKeyVaultSecret per creare un segreto denominato test-app-secret1.

   $secretValue = ConvertTo-SecureString "<secretValue>" -AsPlainText -Force
   Set-AzKeyVaultSecret -VaultName "<keyVaultName>" -Name "test-app-secret1" -SecretValue $secretValue
   

   Note

   Il nome del segreto è l'attributo della risorsa valutato dalla condizione. Scegliere i nomi che riflettono il prefisso a cui si prevede di limitare l'accesso.

4. Creare un secondo segreto denominato test-db-password.

   Set-AzKeyVaultSecret -VaultName "<keyVaultName>" -Name "test-db-password" -SecretValue $secretValue
   

5. Inizializzare le variabili con i nomi usati.

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

Passaggio 5: Assegnare un ruolo con una condizione

1. Inizializza le variabili del ruolo Utente dei segreti di Key Vault.

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

2. Inizializzare l'ambito per il gruppo di risorse. Se non si è impostata prima in questa sessione la variabile $resourceGroup, impostarla sul nome del gruppo di risorse che contiene l'insieme di credenziali delle chiavi.

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

3. Inizializzare la condizione.

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

   Importante

   La condizione deve essere una stringa a riga singola. Le condizioni su più righe non sono accettate. Se si compila la condizione in una stringa qui o in più righe, appiattirla per prima:

   $condition = $condition -replace '\s+', ' '
   

   In PowerShell, se la condizione include un segno di dollaro ($), anteporre un apice inverso (`).

4. Inizializzare la versione e la descrizione della condizione.

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

5. Usare New-AzRoleAssignment per assegnare all'utente il ruolo Key Vault Secrets User con una condizione a livello di gruppo di risorse.

   New-AzRoleAssignment -ObjectId $userObjectId -Scope $scope -RoleDefinitionId $roleDefinitionId -Description $description -Condition $condition -ConditionVersion $conditionVersion
   

   Output di esempio:

   RoleAssignmentId   : /subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.Authorization/roleAssignments/<roleAssignmentId>
   Scope              : /subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>
   DisplayName        : User1
   SignInName         : user1@contoso.com
   RoleDefinitionName : Key Vault Secrets User
   RoleDefinitionId   : 4633458b-17de-408a-b874-0445c86b69e6
   ObjectId           : <userObjectId>
   ObjectType         : User
   CanDelegate        : False
   Description        : Read access to secrets whose names start with test-app
   ConditionVersion   : 2.0
   Condition          : ((!(ActionMatches{'Microsoft.KeyVault/vaults/secrets/getSecret/action'})) OR (@Resource[Microsoft.KeyVault/vaults/secrets:name] StringStartsWith 'test-app'))
   

Passaggio 6: Testare la condizione

1. Aprire una nuova finestra di PowerShell.

2. Usare Connect-AzAccount per accedere come User1.

   Connect-AzAccount
   

3. Inizializzare le variabili usate in precedenza.

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

4. Usare Get-AzKeyVaultSecret per provare a leggere il segreto negato.

   Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $secretNameDenied -AsPlainText
   

   Esempio di output. Si noti che la lettura ha esito negativo a causa della condizione:

   Get-AzKeyVaultSecret : Operation returned an invalid status code 'Forbidden'
   Caller is not authorized to perform action on resource.
   If role assignments, deny assignments or role definitions changed
   recently, please observe propagation time.
   ...
   ForbiddenByRbac
   

5. Leggere il segreto il cui nome inizia con test-app.

   Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $secretNameAllowed -AsPlainText
   

   È possibile leggere questo segreto perché il nome inizia con test-app.

Passaggio 7: (Facoltativo) Modificare la condizione

1. Nell'altra finestra di PowerShell usare Get-AzRoleAssignment per ottenere l'assegnazione di ruolo aggiunta.

   $testRa = Get-AzRoleAssignment -Scope $scope -RoleDefinitionName $roleDefinitionName -ObjectId $userObjectId | Where-Object { $_.Scope -eq $scope }
   

   Importante

   Get-AzRoleAssignment restituisce anche le assegnazioni ereditate da ambiti più elevati, ad esempio lo stesso ruolo assegnato a livello di sottoscrizione. Se l'entità ha questo ruolo in più ambiti, $testRa diventa una matrice e il passaggio successivo ha esito negativo con The property 'Condition' cannot be found on this object. Il Where-Object { $_.Scope -eq $scope } filtro mantiene solo l'assegnazione nell'ambito del gruppo di risorse, quindi $testRa è un singolo oggetto.

2. Modificare la condizione per consentire anche i segreti i cui nomi iniziano con api-.

   $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-'))"
   

   Per l'azione Get secret, questa condizione consente di leggere un segreto solo se il suo nome inizia con test-app o api-. Tutte le altre azioni passano normalmente attraverso la condizione.

3. Aggiorna la condizione e la descrizione dell'assegnazione.

   $testRa.Condition = $condition
   $testRa.Description = "Read access to secrets whose names start with test-app or api-"
   

4. Usare Set-AzRoleAssignment per salvare la modifica.

   Set-AzRoleAssignment -InputObject $testRa -PassThru
   

Passaggio 8: Pulire le risorse

1. Usare Remove-AzRoleAssignment per rimuovere l'assegnazione e la condizione del ruolo.

   Remove-AzRoleAssignment -ObjectId $userObjectId -RoleDefinitionName $roleDefinitionName -ResourceGroupName $resourceGroup
   

2. Eliminare l'insieme di credenziali creato.

3. Eliminare l'utente creato.

Contenuti correlati

• Azioni e attributi per le condizioni ABAC di Azure Key Vault (anteprima)
• Aggiungere condizioni di assegnazione di ruolo per i segreti Key Vault usando interfaccia della riga di comando di Azure (anteprima)
• Risolvere i problemi relativi alle condizioni di assegnazione dei ruoli di Azure
• Risolvere i problemi di accesso per Azure Key Vault