Condividi tramite

Connettere il provider di identità di Azure al driver CSI dell'archivio di segreti di Azure Key Vault nel servizio Azure Kubernetes

  • Articolo

Il driver CSI (Secrets Store Container Storage Interface) nel servizio Azure Kubernetes offre vari metodi di accesso basato sulle identità all'insieme di credenziali delle chiavi di Azure. Questo articolo illustra questi metodi e le procedure consigliate per l'uso del controllo degli accessi in base al ruolo o dei modelli di sicurezza OIDC (OpenID Connect) per accedere all'insieme di credenziali delle chiavi e al cluster del servizio Azure Kubernetes.

È possibile usare uno dei metodi di accesso seguenti:

  • Service Connector con identità gestita
  • ID dei carichi di lavoro
  • Identità gestita assegnata dall'utente

Informazioni su come connettersi ad Azure Key Vault con il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes servizio Azure Kubernetes usando Service Connector. In questo articolo vengono completate le attività seguenti:

  • Creare un cluster del servizio Azure Kubernetes e un insieme di credenziali delle chiavi di Azure.
  • Creare una connessione tra il cluster del servizio Azure Kubernetes e i Azure Key Vault con Connettore di servizi.
  • Creare un SecretProviderClass CRD e un oggetto Pod che utilizza il provider CSI per testare la connessione.
  • Pulire le risorse.

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e opzionale. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Prerequisiti

Configurazione iniziale

  1. Se si usa il connettore di servizi per la prima volta, iniziare eseguendo il comando az provider register per registrare i provider di risorse del connettore di servizi e della configurazione Kubernetes.

    az provider register -n Microsoft.ServiceLinker

    az provider register -n Microsoft.KubernetesConfiguration

    Suggerimento

    È possibile verificare se questi provider di risorse sono già stati registrati eseguendo i comandi az provider show -n "Microsoft.ServiceLinker" --query registrationState e az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

  2. Facoltativamente, usare il comando dell'interfaccia della riga di comando di Azure per ottenere un elenco dei servizi di destinazione supportati per il cluster del servizio Azure Kubernetes.

    az aks connection list-support-types --output table

Creare risorse Azure

  1. Creare un gruppo di risorse usando il comando az group create.

    az group create \
    --name <resource-group-name> \
    --location <location>

  2. Creare un cluster del servizio Azure Kubernetes usando il comando az aks create. L'esempio seguente crea un cluster del servizio Azure Kubernetes a nodo singolo con identità gestita abilitata.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-managed-identity \
    --node-count 1

  3. Connettersi al cluster usando il comando az aks get-credentials.

    az aks get-credentials \
    --resource-group <resource-group-name> \
    --name <cluster-name>

  4. Creare un insieme di credenziali delle chiavi di Azure usando il az keyvault create comando .

    az keyvault create \
    --resource-group <resource-group-name> \  
    --name <key-vault-name> \
    --location <location>

  5. Creare un segreto nell'insieme di credenziali delle chiavi usando il az keyvault secret set comando .

    az keyvault secret set \
    --vault-name <key-vault-name> \
    --name <secret-name> \
    --value <secret-value>

Creare una connessione al servizio nel servizio Azure Kubernetes con connettore di servizi (anteprima)

È possibile creare una connessione al servizio ad Azure Key Vault usando il portale di Azure o l'interfaccia della riga di comando di Azure.

  1. Nel portale di Azure andare alla risorsa del cluster del servizio Azure Kubernetes.

  2. Dal menu del servizio, in Impostazioni, selezionare Service Connector (anteprima)>Crea.

  3. Nella pagina Crea connessione configurare le impostazioni seguenti nella scheda Informazioni di base:

    • Spazio dei nomi Kubernetes: selezionare predefinito.
    • Tipo di servizio: selezionare Key Vault e selezionare la casella di controllo per abilitare il provider CSI di Azure Key Vault.
    • Nome connessione: immettere un nome per la connessione.
    • Sottoscrizione: selezionare la sottoscrizione che contiene l'insieme di credenziali delle chiavi.
    • Insieme di credenziali delle chiavi: selezionare l'insieme di credenziali delle chiavi creato.
    • Tipo di client: selezionare Nessuno.

  4. Selezionare Rivedi e crea e quindi crea per creare la connessione.

Testare la connessione

Clonare il repository di esempio e distribuire i file manifesto

  1. Clonare il repository di esempio usando il git clone comando .

    git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git

  2. Passare all'esempio di provider CSI di Azure Key Vault.

    cd serviceconnector-aks-samples/azure-keyvault-csi-provider

  3. secret_provider_class.yaml Nel file sostituire i segnaposto seguenti con le informazioni di Azure Key Vault:

    • Sostituire <AZURE_KEYVAULT_NAME> con il nome dell'insieme di credenziali delle chiavi creato e connesso.
    • Sostituire <AZURE_KEYVAULT_TENANTID> con l'ID tenant dell'insieme di credenziali delle chiavi.
    • Sostituire <AZURE_KEYVAULT_CLIENTID> con l'ID client di identità del componente aggiuntivo azureKeyvaultSecretsProvider.
    • Sostituire <KEYVAULT_SECRET_NAME> con il segreto dell'insieme di credenziali delle chiavi creato. Ad esempio: ExampleSecret.

  4. Distribuire il SecretProviderClass CRD usando il kubectl apply comando .

    kubectl apply -f secret_provider_class.yaml

  5. Distribuire il Pod file manifesto usando il kubectl apply comando .

    Il comando crea un pod denominato sc-demo-keyvault-csi nello spazio dei nomi predefinito del cluster del servizio Azure Kubernetes.

    kubectl apply -f pod.yaml

Verificare la connessione

  1. Verificare che il pod sia stato creato correttamente usando il kubectl get comando .

    kubectl get pod/sc-demo-keyvault-csi

    Dopo l'avvio del pod, il contenuto montato nel percorso del volume specificato nella distribuzione YAML è disponibile.

  2. Visualizzare i segreti contenuti nell'archivio segreti usando il kubectl exec comando .

    kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/

  3. Visualizzare un segreto usando il kubectl exec comando .

    Questo comando di esempio mostra un segreto di test denominato ExampleSecret.

    kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret

Prerequisiti per il driver CSI

Accesso con un ID carico di lavoro Microsoft Entra

Un ID carico di lavoro Di Microsoft Entra è un'identità usata da un'applicazione in esecuzione in un pod per autenticarsi con altri servizi di Azure, ad esempio carichi di lavoro nel software. Il driver CSI dell'archivio segreti si integra con le funzionalità di Kubernetes native per la federazione con provider di identità esterni.

In questo modello di sicurezza il cluster del servizio Azure Kubernetes funge da emittente del token. Microsoft Entra ID usa quindi OIDC per individuare le chiavi di firma pubbliche e verificare l'autenticità del token dell'account del servizio prima di scambiarlo per un token Microsoft Entra. Per consentire al carico di lavoro di scambiare un token dell'account del servizio proiettato nel volume per un token Microsoft Entra, è necessaria la libreria client di Identità di Azure in Azure SDK o Microsoft Authentication Library (MSAL)

Nota

  • Questo metodo di autenticazione sostituisce l'identità gestita dal pod di Microsoft Entra (anteprima). L'identità gestita dal pod Microsoft Entra (anteprima) open source nel servizio Azure Kubernetes è stata deprecata a partire dal 24/10/2022.
  • L'ID del carico di lavoro Microsoft Entra supporta sia i cluster Windows che Linux.

Configurare l'identità del carico di lavoro

  1. Impostare la sottoscrizione usando il comando az account set.

    export SUBSCRIPTION_ID=<subscription id>
export RESOURCE_GROUP=<resource group name>
export UAMI=<name for user assigned identity>
export KEYVAULT_NAME=<existing keyvault name>
export CLUSTER_NAME=<aks cluster name>

az account set --subscription $SUBSCRIPTION_ID

  2. Creare un'identità gestita usando il comando az identity create.

    Nota

    Questo passaggio presuppone che sia disponibile un cluster del servizio Azure Kubernetes esistente con l'identità del carico di lavoro abilitata. Se non è abilitata, vedere Abilitare l'identità del carico di lavoro in un cluster del servizio Azure Kubernetes esistente per abilitarla.

    az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)

  3. Creare un'assegnazione di ruolo che concede all'identità del carico di lavoro l'autorizzazione per accedere ai segreti, alle chiavi di accesso e ai certificati dell'insieme di credenziali delle chiavi usando il comando az role assignment create.

    Importante

    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa il tipo key o certificate, assegnare il ruolo Key Vault Certificate User per concedere le autorizzazioni.
    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa il tipo secret, assegnare il ruolo Key Vault Secrets User.
    • Se l'insieme di credenziali delle chiavi non è impostato con --enable-rbac-authorization, è possibile usare il comando az keyvault set-policy con il parametro --key-permissions get, --certificate-permissions get o --secret-permissions get per creare un criterio dell'insieme di credenziali delle chiavi per concedere l'accesso per chiavi, certificati o segreti. Ad esempio:
    az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID

    export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

# Example command for key vault with RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

  4. Ottenere l'URL dell'autorità di certificazione OIDC del cluster del servizio Azure Kubernetes usando il comando az aks show.

    Nota

    Questo passaggio presuppone che sia presente un cluster del servizio Azure Kubernetes esistente con l'URL dell'autorità di certificazione OIDC abilitato. Se non è abilitata, vedere Aggiornare un cluster del servizio Azure Kubernetes con l'autorità di certificazione OIDC per abilitarla.

    export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
echo $AKS_OIDC_ISSUER

  5. Stabilire una credenziale di identità federata tra l'applicazione Microsoft Entra, l'autorità emittente dell'account del servizio e l'oggetto. Ottenere l'ID oggetto dell'applicazione Microsoft Entra usando i comandi seguenti. Assicurarsi di aggiornare i valori per serviceAccountName e serviceAccountNamespace con il nome dell'account del servizio Kubernetes e il relativo spazio dei nomi.

    export SERVICE_ACCOUNT_NAME="workload-identity-sa"  # sample name; can be changed
export SERVICE_ACCOUNT_NAMESPACE="default" # can be changed to namespace of your workload

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

  6. Creare le credenziali di identità federate tra l'identità gestita, l'autorità emittente dell'account del servizio e l'oggetto usando il comando az identity federated-credential create.

    export FEDERATED_IDENTITY_NAME="aksfederatedidentity" # can be changed as needed

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

  7. Distribuire un SecretProviderClass usando il comando kubectl apply e lo script YAML seguente.

    cat <<EOF | kubectl apply -f -
# This is a SecretProviderClass example using workload identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-wi # needs to be unique per namespace
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
    keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: secret1             # Set to the name of your secret
          objectType: secret              # object types: secret, key, or cert
          objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
        - |
          objectName: key1                # Set to the name of your key
          objectType: key
          objectVersion: ""
    tenantId: "${IDENTITY_TENANT}"        # The tenant ID of the key vault
EOF

    Nota

    Se si usa objectAlias invece di objectName, aggiornare lo script YAML per tener conto di esso.

    Nota

    Affinché SecretProviderClass funzioni correttamente, assicurarsi di popolare Azure Key Vault con segreti, chiavi o certificati prima di farvi riferimento nella sezione objects.

  8. Distribuire un pod di esempio usando il comando kubectl apply e lo script YAML seguente.

    cat <<EOF | kubectl apply -f -
# This is a sample pod definition for using SecretProviderClass and workload identity to access your key vault
kind: Pod
apiVersion: v1
metadata:
  name: busybox-secrets-store-inline-wi
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: "workload-identity-sa"
  containers:
    - name: busybox
      image: registry.k8s.io/e2e-test-images/busybox:1.29-4
      command:
        - "/bin/sleep"
        - "10000"
      volumeMounts:
      - name: secrets-store01-inline
        mountPath: "/mnt/secrets-store"
        readOnly: true
  volumes:
    - name: secrets-store01-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "azure-kvname-wi"
EOF

Prerequisiti per il driver CSI

Accesso con identità gestita

Un ID gestito di Microsoft Entra è un'identità usata da un amministratore per autenticarsi con altri servizi di Azure. L'identità gestita usa il controllo degli accessi in base al ruolo per la federazione con provider di identità esterni.

In questo modello di sicurezza è possibile concedere l'accesso alle risorse del cluster ai membri del team o ai tenant che condividono un ruolo gestito. Il ruolo viene controllato per l'ambito per accedere all'insieme di credenziali delle chiavi e ad altre credenziali. Quando è stato abilitato il provider di Azure Key Vault per il driver CSI dell'archivio segreti nel cluster del servizio Azure Kubernetes, è stata creata un'identità utente.

Configurare identità gestita

  1. Accedere all'insieme di credenziali delle chiavi usando il comando az aks show e l'identità gestita assegnata dall'utente creata dal componente aggiuntivo. È anche necessario recuperare clientId dell'identità, che verrà usata nei passaggi successivi durante la creazione di SecretProviderClass.

    az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv

    In alternativa, è possibile creare una nuova identità gestita e assegnarla al set di scalabilità di macchine virtuali o a ogni istanza di macchina virtuale nel set di disponibilità usando i comandi seguenti.

    az identity create --resource-group <resource-group> --name <identity-name>
az vmss identity assign --resource-group <resource-group> --name <agent-pool-vmss> --identities <identity-resource-id>
az vm identity assign --resource-group <resource-group> --name <agent-pool-vm> --identities <identity-resource-id>

az identity show --resource-group <resource-group> --name <identity-name> --query 'clientId' -o tsv

  2. Creare un'assegnazione di ruolo che concede all'identità l'autorizzazione per accedere ai segreti, alle chiavi di accesso e ai certificati dell'insieme di credenziali delle chiavi usando il comando az role assignment create.

    Importante

    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa il tipo key o certificate, assegnare il ruolo Key Vault Certificate User.
    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa il tipo secret, assegnare il ruolo Key Vault Secrets User.
    • Se l'insieme di credenziali delle chiavi non è impostato con --enable-rbac-authorization, è possibile usare il comando az keyvault set-policy con il parametro --key-permissions get, --certificate-permissions get o --secret-permissions get per creare un criterio dell'insieme di credenziali delle chiavi per concedere l'accesso per chiavi, certificati o segreti. Ad esempio:
    az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID

    export IDENTITY_OBJECT_ID="$(az identity show --resource-group <resource-group> --name <identity-name> --query 'principalId' -o tsv)"
export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv)

# Example command for key vault with RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

  3. Creare un SecretProviderClass usando il codice YAML seguente. Assicurarsi di usare i propri valori per userAssignedIdentityID, keyvaultName, tenantId e gli oggetti da recuperare dall'insieme di credenziali delle chiavi.

    # This is a SecretProviderClass example using user-assigned identity to access your key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname-user-msi
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"          # Set to true for using managed identity
    userAssignedIdentityID: <client-id>   # Set the clientID of the user-assigned managed identity to use
    keyvaultName: <key-vault-name>        # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: secret1
          objectType: secret              # object types: secret, key, or cert
          objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
        - |
          objectName: key1
          objectType: key
          objectVersion: ""
    tenantId: <tenant-id>                 # The tenant ID of the key vault

    Nota

    Se si usa objectAlias invece di objectName, assicurarsi di aggiornare lo script YAML.

    Nota

    Affinché SecretProviderClass funzioni correttamente, assicurarsi di popolare Azure Key Vault con segreti, chiavi o certificati prima di farvi riferimento nella sezione objects.

  4. Applicare l'oggetto SecretProviderClass al cluster usando il comando kubectl apply.

    kubectl apply -f secretproviderclass.yaml

  5. Creare un pod usando il codice YAML seguente.

    # This is a sample pod definition for using SecretProviderClass and the user-assigned identity to access your key vault
kind: Pod
apiVersion: v1
metadata:
  name: busybox-secrets-store-inline-user-msi
spec:
  containers:
    - name: busybox
      image: registry.k8s.io/e2e-test-images/busybox:1.29-4
      command:
        - "/bin/sleep"
        - "10000"
      volumeMounts:
      - name: secrets-store01-inline
        mountPath: "/mnt/secrets-store"
        readOnly: true
  volumes:
    - name: secrets-store01-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "azure-kvname-user-msi"

  6. Applicare il pod al cluster usando il comando kubectl apply.

    kubectl apply -f pod.yaml

Convalidare i segreti di Key Vault

Dopo l'avvio del pod, il contenuto montato nel percorso del volume specificato nella distribuzione YAML è disponibile. Usare i comandi seguenti per convalidare i segreti e stampare un segreto di test.

  1. Visualizzare i segreti contenuti nell'archivio segreti usando il comando seguente.

    kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/

  2. Visualizzare un segreto nell'archivio usando il comando seguente. Questo comando di esempio mostra il segreto ExampleSecret di test.

    kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret

Ottenere certificati e chiavi

La progettazione di Azure Key Vault distingue in modo netto le chiavi, i segreti e i certificati. Le funzionalità del certificato del servizio Key Vault sono progettate per usare le funzionalità di chiave e segreto. Quando si crea un certificato dell'insieme di credenziali delle chiavi, viene creata una chiave indirizzabile e un segreto con lo stesso nome. Questa chiave consente operazioni di autenticazione e il segreto consente il recupero del valore del certificato come segreto.

Un certificato Key Vault contiene inoltre metadati del certificato x509 pubblico. L'insieme di credenziali delle chiavi archivia i componenti pubblici e privati del certificato in un segreto. È possibile ottenere ogni singolo componente specificando objectType in SecretProviderClass. La tabella seguente illustra gli oggetti mappati alle varie risorse associate al certificato:

Oggetto Valore restituito Restituisce l'intera catena di certificati
key Chiave pubblica, in formato PEM (Privacy Enhanced Mail). N/D
cert Certificato, in formato PEM. No
secret Chiave privata e certificato, in formato PEM. Sì

Disabilitare il componente aggiuntivo nei cluster esistenti

Nota

Prima di disabilitare il componente aggiuntivo, assicurarsi che nonSecretProviderClass sia in uso. Se si tenta di disabilitare il componente aggiuntivo mentre esiste SecretProviderClass, viene generato un errore.

  • Disabilitare la funzionalità driver CSI dell'archivio chiavi di Azure per il provider di Azure Key Vault in un cluster esistente usando il comando az aks disable-addons con il componente aggiuntivo azure-keyvault-secrets-provider.

    az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster

Nota

Quando si disabilita il componente aggiuntivo, i carichi di lavoro esistenti non devono avere problemi o visualizzare eventuali aggiornamenti nei segreti montati. Se il pod viene riavviato o viene creato un nuovo pod come parte dell'evento di aumento delle prestazioni, il pod non viene avviato perché il driver non è più in esecuzione.

Passaggi successivi

In questo articolo si è appreso come creare e fornire un'identità per accedere ad Azure Key Vault. L'integrazione del connettore di servizi semplifica la configurazione della connessione per i carichi di lavoro del servizio Azure Kubernetes e i servizi sottostanti di Azure. Gestisce in modo sicuro le configurazioni di autenticazione e di rete e segue le procedure consigliate per la connessione ai servizi di Azure. Per altre informazioni, vedere Usare il provider di Azure Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes e Introduzione al connettore di servizi.

Per configurare le opzioni di configurazione aggiuntive o eseguire la risoluzione dei problemi, vedere Opzioni di configurazione e risoluzione dei problemi relativi alle risorse per il provider di Azure Key Vault con il driver CSI dell'archivio segreti nel servizio Azure Kubernetes.