Verbinden Ihres Azure-Identitätsanbieters mit dem Azure Key Vault Secrets Store-CSI-Treiber in Azure Kubernetes Service (AKS)

Erfahren Sie, wie Sie mit dem Secrets Store CSI-Treiber in einem AKS-Cluster (Azure Kubernetes Service) mithilfe des Dienstconnectors eine Verbindung mit Azure Key Vault herstellen. In diesem Artikel führen Sie die folgenden Aufgaben aus:

Voraussetzungen

• Ein Azure-Konto mit einem aktiven Abonnement. Sie können kostenlos ein Konto erstellen.
• Die Azure CLI Melden Sie sich mit dem Befehl az login an.
• Docker und kubectl. Um kubectl lokal zu installieren, verwenden Sie den Befehl az aks install-cli.
• Grundlegendes Verständnis von Containern und AKS. Informationen zu den ersten Schritten finden Sie unter Vorbereiten einer Anwendung für Azure Kubernetes Service (AKS).
• Bevor Sie beginnen, stellen Sie sicher, dass Sie die Schritte unter Verwenden des Azure Key Vault-Anbieters für den Secrets Store CSI-Treiber in einem Azure Kubernetes Service (AKS)-Cluster abgeschlossen haben, um den Azure Key Vault Secrets Store CSI-Treiber in Ihrem AKS-Cluster zu aktivieren.

Anfängliche Einrichtung

1. Wenn Sie den Dienstconnector zum ersten Mal verwenden, führen Sie zunächst den Befehl az provider register aus, um die Ressourcenanbieter für den Dienstconnector und die Kubernetes-Konfiguration zu registrieren.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Tipp

   Sie können überprüfen, ob diese Ressourcenanbieter bereits registriert wurden, indem Sie die Befehle az provider show -n "Microsoft.ServiceLinker" --query registrationState und az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState ausführen.

2. Verwenden Sie optional den Azure CLI-Befehl, um eine Liste der unterstützten Zieldienste für AKS-Cluster abzurufen.

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

Erstellen einer Dienstverbindung in AKS mit Service Connector

Sie können eine Dienstverbindung mit Azure Key Vault über das Azure-Portals oder mithilfe der Azure CLI erstellen.

Testen der Verbindung

Klonen des Beispiel-Repositorys und Bereitstellen von Manifestdateien

1. Klonen Sie das Beispiel-Repository mithilfe des Befehls git clone.

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

2. Ändern Sie Verzeichnisse in das Beispiel für den Azure Key Vault CSI-Anbieter.

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

3. Ersetzen Sie in der Datei secret_provider_class.yaml die folgenden Platzhalter durch Ihre Azure Key Vault-Informationen:

   • Ersetzen Sie <AZURE_KEYVAULT_NAME> durch den Namen des von Ihnen erstellten und verbundenen Schlüsseltresors.
   • Ersetzen Sie <AZURE_KEYVAULT_TENANTID> durch die Mandanten-ID des Schlüsseltresors.
   • Ersetzen Sie <AZURE_KEYVAULT_CLIENTID> durch die Identitäts-Client-ID des azureKeyvaultSecretsProvider-Add-ons.
   • Ersetzen Sie <KEYVAULT_SECRET_NAME> durch das von Ihnen erstellte Schlüsseltresorgeheimnis. Beispiel: ExampleSecret.

4. Stellen Sie die SecretProviderClass-CRD mithilfe des Befehls kubectl apply bereit.

   kubectl apply -f secret_provider_class.yaml
   

5. Stellen Sie die Pod-Manifestdatei mithilfe des Befehls kubectl apply bereit.

   Der Befehl erstellt einen Pod namens sc-demo-keyvault-csi im Standardnamespace Ihres AKS-Clusters.

   kubectl apply -f pod.yaml
   

Überprüfen der Verbindung

1. Verifizieren Sie mithilfe des Befehls kubectl get, ob der Pod erfolgreich erstellt wurde.

   kubectl get pod/sc-demo-keyvault-csi
   

   Nachdem der Pod gestartet wurde, ist der eingebundene Inhalt unter dem in Ihrer Bereitstellungs-YAML angegebenen Volumepfad verfügbar.

2. Zeigen Sie die Geheimnisse im Geheimnisspeicher mithilfe des Befehls kubectl exec an.

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

3. Zeigen Sie mithilfe des Befehls kubectl exec ein Geheimnis an.

   Mit diesem Beispielbefehl wird das Testgeheimnis mit dem Namen ExampleSecret angezeigt.

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

Voraussetzungen für CSI-Treiber mit Workload-Identität

• Bevor Sie beginnen, stellen Sie sicher, dass Sie die Schritte unter Verwenden des Azure Key Vault-Anbieters für den Secrets Store CSI-Treiber in einem Azure Kubernetes Service (AKS)-Cluster abgeschlossen haben, um den Azure Key Vault Secrets Store CSI-Treiber in Ihrem AKS-Cluster zu aktivieren.
• Microsoft Entra Workload ID unterstützt sowohl Windows- als auch Linux-Cluster.

Zugriff mit einer Microsoft Entra-Workload-ID

Ein Microsoft Entra Workload ID ist eine Identität, die eine Anwendung oder ein Dienst verwendet, um sich bei anderen Azure-Diensten zu authentifizieren, z. B. Workloads in Software. Der Secrets Store CSI-Treiber integriert sich in native Kubernetes-Funktionen, um mit externen Identitätsanbietern zu föderieren.

In diesem Sicherheitsmodell fungiert der AKS-Cluster als Tokenaussteller. Wenn der Secrets Store CSI-Treiber das Volume einbindet, fordert er ein Kubernetes-Dienstkontotoken an, und der Azure Key Vault-Anbieter tauscht dieses Token gegen ein Microsoft Entra-Token aus. Die Anwendung liest die eingebundenen Dateien und benötigt für diesen Ablauf mit Volume-Einbindung weder die Azure Identity-Clientbibliothek noch die Microsoft Authentication Library (MSAL) (MSAL). Wenn die Anwendung unabhängig Microsoft Entra Token anfordert, geschützte APIs aufzurufen, verwenden Sie Azure Identity oder MSAL in der Anwendung.

Konfigurieren der Workloadidentität

1. Legen Sie Ihr Abonnement mithilfe des Befehls az account set fest.

   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. Erstellen Sie mithilfe des az identity create-Befehls eine verwaltete Identität.

   Hinweis

   In diesem Schritt wird davon ausgegangen, dass Sie über einen AKS-Cluster mit aktivierter Workloadidentität verfügen. Wenn die Workloadidentität nicht aktiviert ist, siehe Workloadidentität auf einem vorhandenen AKS-Cluster aktivieren, um sie zu aktivieren.

   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 KEYVAULT_TENANT_ID="$(az keyvault show --name $KEYVAULT_NAME --query properties.tenantId -o tsv)"
   

3. Erstellen Sie eine Rollenzuweisung, die der Workloadidentität die Berechtigung erteilt, mithilfe des Befehls az role assignment create auf die Schlüsseltresorgeheimnisse, Zugriffsschlüssel und Zertifikate zuzugreifen.

   Wichtig

   • Wenn Sie Ihren Schlüsseltresor mit --enable-rbac-authorization einrichten und den Typ cert oder key verwenden, weisen Sie die Rolle Key Vault Certificate User zu, um Berechtigungen zu gewähren.
   • Wenn Ihr Schlüsseltresor mit --enable-rbac-authorization festgelegt ist und Sie den Typ secret verwenden, weisen Sie die Key Vault Secrets User-Rolle zu.
   • Wenn Ihr Schlüsseltresor nicht mit --enable-rbac-authorization festgelegt ist, können Sie den Befehl az keyvault set-policy mit dem Parameter --key-permissions get, --certificate-permissions get oder --secret-permissions get verwenden, um eine Schlüsseltresorrichtlinie zu erstellen, um Zugriff auf Schlüssel, Zertifikate oder Geheimnisse zu gewähren. Beispiel:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --secret-permissions get --object-id <identity-object-id>
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example commands for a key vault with Azure RBAC enabled using `key` and `secret` types
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   az role assignment create --role "Key Vault Secrets User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

4. Rufen Sie die OIDC-Aussteller-URL des AKS-Clusters mit dem Befehl az aks show ab.

   Hinweis

   In diesem Schritt wird davon ausgegangen, dass Sie über einen vorhandenen AKS-Cluster mit aktivierter OIDC-Aussteller-URL verfügen. Wenn die OIDC-Aussteller-URL nicht aktiviert ist, siehe Aktualisieren eines AKS-Clusters mit OIDC Issuer, um sie zu aktivieren.

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

5. Erstellen Sie ein Kubernetes-Dienstkonto für die Workload. Aktualisieren Sie die Werte für SERVICE_ACCOUNT_NAME und SERVICE_ACCOUNT_NAMESPACE mit dem Namen des Kubernetes-Dienstkontos und seinem Namespace.

   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. Erstellen Sie die Verbundidentitäts-Anmeldeinformationen zwischen der verwalteten Identität, dem Dienstkontoaussteller und dem Antragsteller mithilfe des Befehls 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. Stellen Sie eine SecretProviderClass mithilfe des Befehls kubectl apply und des folgenden YAML-Skripts bereit.

Die folgenden Parameter konfigurieren den Workload-Identitätszugriff:

• usePodIdentity: Bei Verwendung der Workload-Identität auf "false" festlegen.

• clientID: Auf ${USER_ASSIGNED_CLIENT_ID} festgelegt, die Client-ID der benutzerseitig zugewiesenen verwalteten Identität, die für die Workloadidentität verwendet wird.

• cloudName:Wahlfrei. Lassen Sie leer, um die Standardumgebung AzurePublicCloud zu verwenden.

• objectType: Legen Sie den Typ des Key Vault Objekts fest, das bereitgestellt werden soll. Gültige Werte sind secret, keyund cert.

• tenantId: Legen Sie die Mandanten-ID fest, die den Schlüsseltresor enthält.

  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
    namespace: ${SERVICE_ACCOUNT_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: "${KEYVAULT_TENANT_ID}"     # The tenant ID of the key vault
  EOF
  

  Hinweis

  Wenn Sie objectAlias anstelle von objectName verwenden, aktualisieren Sie das YAML-Skript, um dies zu berücksichtigen.

  Hinweis

  Damit die SecretProviderClass Funktion ordnungsgemäß funktioniert, stellen Sie sicher, dass Sie Ihren Azure Key Vault mit geheimen Schlüsseln, Schlüsseln oder Zertifikaten auffüllen, bevor Sie sie im objects Abschnitt referenzieren.

1. Stellen Sie einen Beispiel-Pod mithilfe des Befehls kubectl apply und des folgenden YAML-Skripts bereit.

   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
     namespace: ${SERVICE_ACCOUNT_NAMESPACE}
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: ${SERVICE_ACCOUNT_NAME}
     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
   

Validieren von Key Vault-Geheimnissen mit Workloadidentität

Nach dem Start des Pods ist der unter /mnt/secrets-store eingebundene Inhalt verfügbar. Verwenden Sie die folgenden Befehle, um Ihre Geheimnisse zu überprüfen und ein Testgeheimnis auszudrucken.

1. Zeigen Sie mit dem folgenden Befehl Geheimnisse im Geheimnisspeicher an.

   kubectl exec --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- ls /mnt/secrets-store/
   

2. Zeigen Sie mit dem folgenden Befehl ein Geheimnis im Speicher an. Mit diesem Beispielbefehl wird das Testgeheimnis secret1 angezeigt.

   kubectl exec --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- cat /mnt/secrets-store/secret1
   

Voraussetzungen für CSI-Treiber mit verwalteter Identität

• Bevor Sie beginnen, stellen Sie sicher, dass Sie die Schritte unter Verwenden des Azure Key Vault-Anbieters für den Secrets Store CSI-Treiber in einem Azure Kubernetes Service (AKS)-Cluster abgeschlossen haben, um den Azure Key Vault Secrets Store CSI-Treiber in Ihrem AKS-Cluster zu aktivieren.

Zugriff mit verwalteten Identitäten

Diese Methode verwendet die vom Benutzer zugewiesene verwaltete Identität, die AKS automatisch erstellt, wenn Sie den Azure Key Vault-Provider für den Secrets Store CSI-Treiber aktivieren. Die Identität ist benannt azurekeyvaultsecretsprovider-xxxxx, wird in der Knotenressourcengruppe gespeichert und dem Skalierungssatz des virtuellen Computers zugewiesen.

Eine Microsoft Entra verwaltete Identität ermöglicht es einer Azure Ressource oder Arbeitsauslastung, sich bei Diensten zu authentifizieren, die Microsoft Entra Authentifizierung unterstützen, ohne Anmeldeinformationen im Code zu speichern. Gewähren Sie dieser Identität die entsprechenden Key Vault Berechtigungen für Datenebenen über Azure RBAC oder Zugriffsrichtlinien, und verwenden Sie sie dann in den folgenden Schritten.

Konfigurieren einer verwalteten Identität

1. Greifen Sie mithilfe des az aks show-Befehls und der vom Add-On erstellten vom Benutzer zugewiesenen verwalteten Identität auf Ihren Schlüsseltresor zu. Sie sollten auch die Identität clientId abrufen, die Sie später bei der Erstellung von SecretProviderClass verwenden.

   export RESOURCE_GROUP=<resource-group>
   export CLUSTER_NAME=<cluster-name>
   export KEYVAULT_NAME=<key-vault-name>
   
   export IDENTITY_OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv)
   export USER_ASSIGNED_CLIENT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv)
   

   Alternativ können Sie eine neue verwaltete Identität erstellen und sie Ihrer Skalierungsgruppe für virtuelle Maschinen oder jeder einzelnen VM-Instanz in Ihrer Verfügbarkeitsgruppe zuweisen.

   export USER_ASSIGNED_IDENTITY_NAME=<identity-name>
   
   az identity create --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME
   
   export IDENTITY_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query id -o tsv)
   export IDENTITY_OBJECT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query principalId -o tsv)
   export USER_ASSIGNED_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query clientId -o tsv)
   

   Weisen Sie für einen auf VM-Skalierungssätzen basierten Cluster dem VM-Skalierungssatz die Identität zu.

   az vmss identity assign --resource-group <node-resource-group> --name <agent-pool-vmss> --identities $IDENTITY_RESOURCE_ID
   

   Weisen Sie für einen auf Verfügbarkeitssatz basierenden Cluster die Identität jeder VM-Instanz im Verfügbarkeitssatz zu.

   az vm identity assign --resource-group <node-resource-group> --name <agent-pool-vm> --identities $IDENTITY_RESOURCE_ID
   

2. Erstellen Sie eine Rollenzuweisung, die der Identität die Berechtigung erteilt, mithilfe des Befehls az role assignment create auf die Schlüsseltresor-Geheimnisse, Zugriffsschlüssel und Zertifikate zuzugreifen.

   Wichtig

   • Wenn Sie Ihren Schlüsseltresor mit --enable-rbac-authorization festlegen und den Typ key oder cert verwenden, weisen Sie die Rolle Key Vault Certificate User zu.
   • Wenn Ihr Schlüsseltresor mit --enable-rbac-authorization festgelegt ist und Sie den Typ secret verwenden, weisen Sie die Key Vault Secrets User-Rolle zu.
   • Wenn Ihr Schlüsseltresor nicht mit --enable-rbac-authorization festgelegt ist, können Sie den Befehl az keyvault set-policy mit dem Parameter --key-permissions get, --certificate-permissions get oder --secret-permissions get verwenden, um eine Schlüsseltresorrichtlinie zu erstellen, um Zugriff auf Schlüssel, Zertifikate oder Geheimnisse zu gewähren. Beispiel:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --secret-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example commands for a key vault with Azure RBAC enabled using `key` and `secret` types
   az role assignment create --role "Key Vault Certificate User" --assignee-object-id $IDENTITY_OBJECT_ID --assignee-principal-type ServicePrincipal --scope $KEYVAULT_SCOPE
   az role assignment create --role "Key Vault Secrets User" --assignee-object-id $IDENTITY_OBJECT_ID --assignee-principal-type ServicePrincipal --scope $KEYVAULT_SCOPE
   

3. Erstellen Sie eine SecretProviderClass mithilfe der Identitätsclient-ID. Stellen Sie sicher, dass Sie für die Objekte, die Sie aus Ihrem Schlüsseltresor abrufen, Ihre eigenen Werte verwenden.

   Die folgenden Parameter konfigurieren den vom Benutzer zugewiesenen verwalteten Identitätszugriff:

   • usePodIdentity: Bei Verwendung einer verwalteten Identität auf "false" festlegen.
   • useVMManagedIdentity: Auf "true" setzen, um den Modus für verwaltete Identitäten zu aktivieren.
   • userAssignedIdentityID: Legen Sie die Client-ID der vom Benutzer zugewiesenen verwalteten Identität fest.
   • tenantId: Legen Sie die Mandanten-ID fest, die den Schlüsseltresor enthält.

   export KEYVAULT_TENANT_ID=$(az keyvault show --name $KEYVAULT_NAME --query properties.tenantId -o tsv)
   
   cat <<EOF > secretproviderclass.yaml
   # 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: ${USER_ASSIGNED_CLIENT_ID} # Set the client ID of the user-assigned managed identity to use
       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
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1
             objectType: key
             objectVersion: ""
       tenantId: ${KEYVAULT_TENANT_ID}       # The tenant ID of the key vault
   EOF
   

   Hinweis

   Wenn Sie objectAlias anstelle von objectName verwenden, müssen Sie das YAML-Skript aktualisieren.

   Hinweis

   Damit die SecretProviderClass Funktion ordnungsgemäß funktioniert, stellen Sie sicher, dass Sie Ihren Azure Key Vault mit geheimen Schlüsseln, Schlüsseln oder Zertifikaten auffüllen, bevor Sie sie im objects Abschnitt referenzieren.

4. Wenden Sie die SecretProviderClass mithilfe des Befehls kubectl apply auf Ihren Cluster an.

   kubectl apply -f secretproviderclass.yaml
   

5. Erstellen Sie ein Pod-Manifest pod.yaml mit dem folgenden Befehl.

   cat <<EOF > pod.yaml
   # 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"
   EOF
   

6. Wenden Sie mithilfe des Befehls kubectl apply den Pod auf Ihren Cluster an.

   kubectl apply -f pod.yaml
   

Key Vault-Geheimnisse mit verwalteter Identität überprüfen

Nach dem Start des Pods ist der unter /mnt/secrets-store eingebundene Inhalt verfügbar. Verwenden Sie die folgenden Befehle, um Ihre Geheimnisse zu überprüfen und ein Testgeheimnis auszudrucken.

1. Zeigen Sie mit dem folgenden Befehl Geheimnisse im Geheimnisspeicher an.

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

2. Zeigen Sie mit dem folgenden Befehl ein Geheimnis im Speicher an. Mit diesem Beispielbefehl wird das Testgeheimnis secret1 angezeigt.

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

Zertifikate und Schlüssel abrufen

Azure Key Vault unterscheidet streng zwischen Schlüsseln, Geheimnissen und Zertifikaten. Die Zertifikatsfunktionen des Schlüsseltresordiensts sind so konzipiert, dass sie die Fähigkeiten von Schlüssel und Geheimnis nutzen. Wenn Sie ein Key Vault-Zertifikat erstellen, werden ein adressierbarer Schlüssel und ein Geheimnis gleichen Namens erstellt. Dieser Schlüssel ermöglicht Authentifizierungsvorgänge und das Geheimnis ermöglicht den Abruf des Zertifikatswerts als Geheimnis.

Ein Key Vault-Zertifikat enthält auch öffentliche X509-Zertifikatmetadaten. Der Schlüsseltresor speichert sowohl die öffentliche als auch die private Komponente Ihres Zertifikats in einem Geheimnis. Sie können die jeweilige Komponente abrufen, indem Sie den objectType in SecretProviderClass angeben. Die folgende Tabelle zeigt die Werte, die Sie in SecretProviderClass angeben können, um verschiedene Komponenten eines objectTypeKey Vault-Zertifikats abzurufen, und was die einzelnen Werte jeweils zurückgeben:

Deaktivieren des Add-Ons auf vorhandenen Clustern

Verwenden Sie den Befehl az aks disable-addons mit dem Add-On azure-keyvault-secrets-provider, um die Funktionen des Azure Key Vault Provider for Secrets Store CSI-Treibers in einem vorhandenen Cluster zu deaktivieren.

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

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie eine Identität für den Zugriff auf Ihren Azure Key Vault erstellen und bereitstellen. Die Dienstconnector-Integration vereinfacht die Verbindungskonfiguration für AKS-Workloads und Azure-Sicherungsdienste. Sie verarbeitet Authentifizierungs- und Netzwerkkonfigurationen auf sichere Weise und folgt bewährten Methoden für die Verbindung mit Azure-Diensten. Weitere Informationen finden Sie unter Verwenden des Azure Key Vault Provider for Secrets Store CSI-Treibers in einem AKS-Cluster und Einführung in den Dienstconnector.

Wenn Sie zusätzliche Konfigurationsoptionen konfigurieren oder eine Problembehandlung durchführen möchten, lesen Sie Konfigurationsoptionen und Problembehandlungsressourcen für Azure Key Vault-Anbieter mit dem Secrets Store CSI-Treiber in AKS.