Usare Azure Key Vault per passare un segreto come parametro durante la distribuzione di Bicep
Questo articolo illustra come usare Azure Key Vault per passare un segreto come parametro durante la distribuzione di Bicep. Anziché immettere un valore sicuro come una password direttamente nel file Bicep o nel file di parametri, è possibile recuperare il valore da Azure Key Vault durante una distribuzione.
Quando un modulo prevede un parametro stringa con un secure:true
modificatore applicato, è possibile usare la getSecret
funzione per ottenere un segreto dell'insieme di credenziali delle chiavi. Non si espone il valore perché si fa riferimento solo all'ID dell'insieme di credenziali delle chiavi.
Importante
Questo articolo è incentrato su come passare un valore sensibile come parametro di modello. Quando il segreto viene passato come parametro, l'insieme di credenziali delle chiavi può esistere in una sottoscrizione diversa rispetto al gruppo di risorse in cui si esegue la distribuzione.
Questo articolo non illustra come impostare una proprietà macchina virtuale (VM) su un URL di un certificato in un insieme di credenziali delle chiavi. Per un modello di avvio rapido di questo scenario, vedere WinRM in una macchina virtuale Windows.
Distribuire insiemi di credenziali delle chiavi e segreti
Per accedere a un insieme di credenziali delle chiavi durante la distribuzione di Bicep, impostare enabledForTemplateDeployment
nell'insieme di credenziali delle chiavi su true
.
Se si dispone già di un insieme di credenziali delle chiavi, assicurarsi che consenta le distribuzioni di modelli.
az keyvault update --name ExampleVault --enabled-for-template-deployment true
Per creare un nuovo insieme di credenziali delle chiavi e aggiungere un segreto, usare:
az group create --name ExampleGroup --location centralus
az keyvault create \
--name ExampleVault \
--resource-group ExampleGroup \
--location centralus \
--enabled-for-template-deployment true
az keyvault secret set --vault-name ExampleVault --name "ExamplePassword" --value "hVFkk965BuUv"
Il proprietario dell'insieme di credenziali delle chiavi ha automaticamente accesso per creare segreti. Se l'utente che lavora con segreti non è il proprietario dell'insieme di credenziali delle chiavi, è possibile concedere l'accesso con:
az keyvault set-policy \
--upn <user-principal-name> \
--name ExampleVault \
--secret-permissions set delete get list
Per altre informazioni sulla creazione di insiemi di credenziali delle chiavi e sull'aggiunta di segreti, vedere:
- Impostare e recuperare un segreto usando l'interfaccia della riga di comando di Azure
- Impostare e recuperare un segreto usando Azure PowerShell
- Impostare e recuperare un segreto usando il portale di Azure
- Impostare e recuperare un segreto usando .NET
- Impostare e recuperare un segreto usando Node.js
Concedere l'accesso ai segreti
L'utente che distribuisce il file Bicep deve disporre dell'autorizzazione Microsoft.KeyVault/vaults/deploy/action
per l'ambito del gruppo di risorse e dell'insieme di credenziali delle chiavi. Entrambi i ruoli Proprietario e Collaboratore possono concedere l'accesso. L’utente che ha creato l'insieme di credenziali delle chiavi è il proprietario e ha l'autorizzazione.
La procedura seguente illustra come creare un ruolo con l'autorizzazione minima e come assegnare l'utente:
Creare un file JSON personalizzato con una definizione di ruolo:
{ "Name": "Key Vault Bicep deployment operator", "IsCustom": true, "Description": "Lets you deploy a Bicep file with the access to the secrets in the Key Vault.", "Actions": [ "Microsoft.KeyVault/vaults/deploy/action" ], "NotActions": [], "DataActions": [], "NotDataActions": [], "AssignableScopes": [ "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e" ] }
Sostituire "00000000-0000-0000-0000-000000000000" con l’ID sottoscrizione.
Usare il file JSON per creare il nuovo ruolo:
az role definition create --role-definition "<path-to-role-file>" az role assignment create \ --role "Key Vault Bicep deployment operator" \ --scope /subscriptions/<Subscription-id>/resourceGroups/<resource-group-name> \ --assignee <user-principal-name>
Gli esempi precedenti assegnano il ruolo personalizzato all'utente a livello di gruppo di risorse.
Se si usa un insieme di credenziali delle chiavi con un file Bicep per un'applicazione gestita, è necessario concedere l'accesso all'entità servizio del provider di risorse dell'appliance. Per altre informazioni, vedere Accedere a un segreto di Key Vault durante la distribuzione di applicazioni gestite di Azure.
Recuperare i segreti in un file Bicep
È possibile usare la getSecret
funzione in un file Bicep per ottenere un segreto dell'insieme di credenziali delle chiavi. La getSecret
funzione può essere usata solo con una Microsoft.KeyVault/vaults
risorsa. Inoltre, può essere usata solo all'interno della params
sezione di un modulo e solo con parametri con decorator @secure()
.
È possibile usare un'altra funzione chiamata az.getSecret()
in un file di parametri Bicep per recuperare i segreti dell'insieme di credenziali delle chiavi. Per altre informazioni, vedere Recuperare i segreti in un file di parametri.
Poiché la getSecret
funzione può essere usata solo nella params
sezione di un modulo, creare un file sql.bicep nella stessa directory del file main.bicep con il contenuto seguente:
param sqlServerName string
param location string = resourceGroup().location
param adminLogin string
@secure()
param adminPassword string
resource sqlServer 'Microsoft.Sql/servers@2023-08-01-preview' = {
name: sqlServerName
location: location
properties: {
administratorLogin: adminLogin
administratorLoginPassword: adminPassword
version: '12.0'
}
}
Il adminPassword
parametro ha un @secure()
elemento decorator nel file precedente.
Il file Bicep seguente usa sql.bicep come modulo. Il file Bicep fa riferimento a un insieme di credenziali delle chiavi esistente, chiama la getSecret
funzione per recuperare il segreto dell'insieme di credenziali delle chiavi e quindi passa il valore come parametro al modulo:
param sqlServerName string
param adminLogin string
param subscriptionId string
param kvResourceGroup string
param kvName string
resource kv 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
name: kvName
scope: resourceGroup(subscriptionId, kvResourceGroup )
}
module sql './sql.bicep' = {
name: 'deploySQL'
params: {
sqlServerName: sqlServerName
adminLogin: adminLogin
adminPassword: kv.getSecret('vmAdminPassword')
}
}
Recuperare segreti in un file di parametri
Se non si vuole usare un modulo, è possibile recuperare i segreti dell'insieme di credenziali delle chiavi in un file di parametri. Tuttavia, l'approccio varia a seconda che si usi un file di parametri JSON o Bicep.
Il file Bicep seguente distribuisce un server SQL che include una password di amministratore. Mentre il parametro password è impostato su una stringa sicura, Bicep non specifica l'origine di tale valore:
param sqlServerName string
param location string = resourceGroup().location
param adminLogin string
@secure()
param adminPassword string
resource sqlServer 'Microsoft.Sql/servers@2023-08-01-preview' = {
name: sqlServerName
location: location
properties: {
administratorLogin: adminLogin
administratorLoginPassword: adminPassword
version: '12.0'
}
}
Creare quindi un file di parametri per il file Bicep precedente.
File dei parametri Bicep
La az.getSecret
funzione può essere usata in un .bicepparam
file per recuperare il valore di un segreto da un insieme di credenziali delle chiavi:
using './main.bicep'
param sqlServerName = '<your-server-name>'
param adminLogin = '<your-admin-login>'
param adminPassword = az.getSecret('<subscription-id>', '<rg-name>', '<key-vault-name>', '<secret-name>', '<secret-version>')
File dei parametri JSON
In un file di parametri JSON specificare un parametro che corrisponda al nome del parametro nel file Bicep. Per il valore del parametro, fare riferimento al segreto dall'insieme di credenziali delle chiavi. Passare l'identificatore della risorsa dell'insieme di credenziali delle chiavi e il nome del segreto. Nel file di parametri seguente il segreto dell'insieme di credenziali delle chiavi deve esistere già. Specificare un valore statico per il relativo ID risorsa.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"adminLogin": {
"value": "<your-admin-login>"
},
"adminPassword": {
"reference": {
"keyVault": {
"id": "/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.KeyVault/vaults/<key-vault-name>"
},
"secretName": "ExamplePassword"
}
},
"sqlServerName": {
"value": "<your-server-name>"
}
}
}
Se è necessario usare una versione del segreto diversa da quella corrente, includere una secretVersion
proprietà :
"secretName": "ExamplePassword",
"secretVersion": "cd91b2b7e10e492ebb870a6ee0591b68"
Contenuto correlato
- Per informazioni generali sugli insiemi di credenziali delle chiavi, vedere Informazioni su Azure Key Vault.
- Per esempi di GitHub completi che illustrano come fare riferimento ai segreti dell'insieme di credenziali delle chiavi, vedere Esempi di Key Vault.
- Per un modulo Learn che illustra come usare un insieme di credenziali delle chiavi per passare un valore sicuro, vedere Gestire distribuzioni cloud complesse usando funzionalità avanzate del modello di Resource Manager JSON.