Teilen über

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

  • Artikel

Der Secrets Store Container Storage Interface (CSI)-Treiber auf Azure Kubernetes Service (AKS) bietet verschiedene Methoden des identitätsbasierten Zugriffs auf Ihren Azure Key Vault. In diesem Artikel werden diese Methoden und Best Practices für die Verwendung von rollenbasierten Zugriffssteuerungsmodellen (RBAC) oder OpenID Connect (OIDC)-Sicherheitsmodellen für den Zugriff auf Ihren Schlüsseltresor und den AKS-Cluster beschrieben.

Sie können eine der folgenden Zugriffsmethoden verwenden:

  • Dienstconnector mit Workload ID
  • Workload ID
  • Benutzerseitig zugewiesene verwaltete Identität

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:

  • Erstellen eines AKS-Clusters und einer Azure Key Vault-Instanz
  • Herstellen einer Verbindung zwischen dem AKS-Cluster und der Azure Key Vault-Instanz mit dem Dienstconnector
  • Erstellen Sie eine SecretProviderClass-CRD und einen Pod, der den CSI-Anbieter zum Testen der Verbindung verwendet.
  • Bereinigen der Ressourcen

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Voraussetzungen

Erstellen von Azure-Ressourcen

  1. Erstellen Sie mit dem Befehl az group create eine Ressourcengruppe.

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

  2. Erstellen Sie mit dem Befehl az aks create einen AKS-Cluster. Im folgenden Beispiel wird ein AKS-Cluster mit nur einem Knoten mit aktivierter verwalteter Identität erstellt.

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

  3. Verwenden Sie den Befehl az aks get-credentials, um eine Verbindung mit dem Cluster herzustellen.

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

  4. Erstellen Sie eine Azure-Schlüsseltresor-Instanz mithilfe des Befehls az keyvault create.

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

  5. Erstellen Sie ein Geheimnis im Schlüsseltresor mithilfe des Befehls az keyvault secret set.

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

Erstellen einer Dienstverbindung in AKS mit dem Dienstconnector (Vorschau)

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

  1. Navigieren Sie im Azure-Portal zur AKS-Clusterressource.

  2. Wählen Sie im Dienstmenü unter Einstellungen die Optionen Dienstconnector (Vorschau)>Erstellen aus.

  3. Konfigurieren Sie auf der Seite Verbindung erstellen die folgenden Einstellungen auf der Registerkarte Grundlagen:

    • Kubernetes-Namespace: Wählen Sie default aus.
    • Diensttyp: Wählen Sie die Option Key Vault aus, und aktivieren Sie das Kontrollkästchen, um den Azure Key Vault CSI-Anbieter zu aktivieren.
    • Verbindungsname: Geben Sie einen Namen für die Verbindung ein.
    • Abonnement: Wählen Sie das Abonnement aus, das den Schlüsseltresor enthält.
    • Schlüsseltresor: Wählen Sie den Schlüsseltresor aus, den Sie erstellt haben.
    • Clienttyp: Wählen Sie die Option Keine aus.

  4. Wählen Sie zunächst Überprüfen und Erstellen und dann Erstellen aus, um die Verbindung zu 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ätsclient-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

Zugriff mit einer Microsoft Entra-Workload-ID

Eine Microsoft Entra Workload-ID ist eine Identität, die eine Anwendung, die auf einem Pod ausgeführt wird, um sich bei anderen Azure-Diensten zu authentifizieren, z. B. Workloads in Software. Der Secret Store CSI Driver lässt sich in die nativen Kubernetes-Funktionen integrieren, um sich mit externen Identitätsanbietern zu verbinden.

In diesem Sicherheitsmodell fungiert der AKS-Cluster als Tokenaussteller. Microsoft Entra ID verwendet dann OIDC, um öffentliche Signierschlüssel zu ermitteln und die Authentizität des Dienstkontotokens zu überprüfen, bevor es gegen ein Microsoft Entra-Token ausgetauscht wird. Damit Ihr Workload ein auf sein Volume projiziertes Dienstkonto-Token gegen ein Microsoft Entra-Token austauschen kann, benötigen Sie die Azure Identity-Client-Bibliothek im Azure SDK oder die Microsoft Authentication Library (MSAL)

Hinweis

  • Diese Authentifizierungsmethode ersetzt die vom Pod verwaltete Microsoft Entra-Identität (Vorschau). Die vom Pod verwaltete Open-Source-Microsoft Entra-Identität (Vorschau) im Azure Kubernetes Service wurde zum 24.10.2022 als veraltet markiert.
  • Microsoft Entra Workload ID unterstützt sowohl Windows- als auch Linux-Cluster.

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 sie nicht aktiviert ist, finden Sie unter Aktivieren einer Workloadidentität in einem vorhandenen AKS-Cluster Informationen zur Aktivierung.

    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. 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 Ihr Schlüsseltresor mit --enable-rbac-authorization festgelegt ist und Sie den Typ key oder certificate verwenden, weisen Sie die Key Vault Certificate User-Rolle zu, um Berechtigungen zu erteilen.
    • 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-authorizationfestgelegt 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. Zum Beispiel:
    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. 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 sie nicht aktiviert ist, lesen Sie Aktualisieren eines AKS-Clusters mit OIDC Issuer, um ihn 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 einen Verbundidentitätsnachweis zwischen der Microsoft Entra-Anwendung, dem Aussteller des Dienstkontos und dem Subjekt. Rufen Sie die Objekt-ID der Microsoft Entra-Anwendung mit den folgenden Befehlen ab. Aktualisieren Sie unbedingt die Werte für serviceAccountName und serviceAccountNamespace 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.

    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

    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.

  8. 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
  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

Voraussetzungen für CSI-Treiber

Zugriff mit verwalteten Identitäten

Eine von Microsoft Entra verwaltete ID ist eine Identität, die ein Administrator zur Authentifizierung bei anderen Azure-Diensten verwendet. Die verwaltete Identität verwendet RBAC zum Verbund mit externen Identitätsanbietern.

In diesem Sicherheitsmodell können Sie den Zugriff auf Ihre Clusterressourcen für Teammitglieder oder Mandanten gewähren, die eine verwaltete Rolle teilen. Die Rolle wird auf den Bereich überprüft, um auf den KeyVault und andere Anmeldeinformationen zuzugreifen. Wenn Sie den Azure Key Vault Provider für den Secrets Store CSI-Treiber auf Ihrem AKS-Cluster aktiviert haben, wurde eine Benutzeridentität erstellt.

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 bei der Erstellung einer SecretProviderClass-Identität in späteren Schritten verwenden werden.

    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

    Alternativ können Sie mithilfe der folgenden Befehle eine neue verwaltete Identität erstellen und sie Ihrer VM-Skalierungsgruppen oder jeder VM-Instanz in Ihrer Verfügbarkeitsgruppen zuweisen.

    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. 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 Ihr Schlüsseltresor mit --enable-rbac-authorization festgelegt ist und Sie den Typ key oder certificate verwenden, weisen Sie die Key Vault Certificate User-Rolle 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-authorizationfestgelegt 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. Zum Beispiel:
    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. Erstellen Sie eine SecretProviderClass mit dem folgenden YAML-Code. Verwenden Sie unbedingt Ihre eigenen Werte für userAssignedIdentityID, keyvaultName, tenantId und die Objekte, die aus dem Schlüsseltresor abgerufen werden sollen.

    # 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

    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 einen Pod mithilfe des folgenden YAML-Codes.

    # 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. Wenden Sie mithilfe des Befehls kubectl apply den Pod auf Ihren Cluster an.

    kubectl apply -f pod.yaml

Geheimnisse des Schlüsseltresors validieren

Nachdem der Pod gestartet wurde, ist der eingebundene Inhalt unter dem in Ihrer Bereitstellungs-YAML angegebenen Volumepfad 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 ExampleSecret angezeigt.

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

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, welche Objekte den verschiedenen Ressourcen Ihres Zertifikats zugeordnet sind:

Object Rückgabewert Zeigt die gesamte Zertifikatskette an
key Der öffentliche Schlüssel im PEM-Format (Privacy Enhanced Mail). Nicht zutreffend
cert Das Zertifikat im PEM-Format Nein
secret Der private Schlüssel und das Zertifikat im PEM-Format Ja

Deaktivieren des Add-Ons auf vorhandenen Clustern

Hinweis

Stellen Sie vor dem Deaktivieren des Add-Ons sicher, dass keine SecretProviderClass verwendet wird. Der Versuch, das Add-On zu deaktivieren, während eine SecretProviderClass vorhanden ist, führt zu einem Fehler.

  • 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

Hinweis

Wenn Sie das Add-On deaktivieren, sollten bei vorhandenen Workloads keine Probleme auftreten und keine Aktualisierungen in den eingebundenen Geheimnissen angezeigt werden. Wenn der Pod neu gestartet werden soll oder ein neuer Pod im Rahmen des Hochskalierungsereignisses erstellt wird, tritt beim Starten des Pods ein Fehler auf, da der Treiber nicht mehr ausgeführt wird.

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.