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:

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.

    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 o si usa key il certificate tipo, assegnare il Key Vault Certificate User ruolo per concedere le autorizzazioni.
    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa secret il tipo, assegnare il Key Vault Secrets User ruolo.
    • Se l'insieme di credenziali delle chiavi non è impostato con --enable-rbac-authorization, è possibile usare il comando con il az keyvault set-policy parametro , --certificate-permissions geto --secret-permissions get per creare un criterio dell'insieme --key-permissions getdi 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

    Per il corretto funzionamento di SecretProviderClass , assicurarsi di popolare Azure Key Vault con segreti, chiavi o certificati prima di farvi riferimento nella objects sezione .

  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

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 l'identità clientId, che verrà usata nei passaggi successivi durante la creazione di un oggetto 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 az role assignment create comando .

    Importante

    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa o certificate si digitakey, assegnare il Key Vault Certificate User ruolo.
    • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa secret il tipo, assegnare il Key Vault Secrets User ruolo.
    • Se l'insieme di credenziali delle chiavi non è impostato con --enable-rbac-authorization, è possibile usare il comando con il az keyvault set-policy parametro , --certificate-permissions geto --secret-permissions get per creare un criterio dell'insieme --key-permissions getdi 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

    Per il corretto funzionamento di SecretProviderClass , assicurarsi di popolare Azure Key Vault con segreti, chiavi o certificati prima di farvi riferimento nella objects sezione .

  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 di Service Connector semplifica la configurazione della connessione per i carichi di lavoro del servizio Azure Kubernetes e i servizi di backup 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 l'introduzione di Service Connector.

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