Freigeben über

Verwenden der Geheimnisspeichererweiterung zum Abrufen von Geheimnissen für den Offlinezugriff in Azure Arc-fähigen Kubernetes-Clustern

  • Artikel

Die Azure Key Vault-Geheimnisspeichererweiterung für Kubernetes (Secret Store Extension, SSE) synchronisiert Geheimnisse aus Azure Key Vault automatisch mit einem Azure Arc-fähigen Kubernetes-Cluster, um den Offlinezugriff zu ermöglichen. Das bedeutet, dass Sie Azure Key Vault verwenden können, um Ihre Geheimnisse zu speichern, zu verwalten und zu rotieren, auch wenn Sie Ihren Kubernetes-Cluster in einem teilweise getrennten Zustand ausführen. Synchronisierte Geheimnisse werden im Geheimnisspeicher des Clusters gespeichert, sodass sie als Kubernetes-Geheimnisse verfügbar sind und wie gewohnt verwendet werden können: Einbindung als Datenvolumes oder Verfügbarmachen als Umgebungsvariablen für einen Container in einem Pod.

Synchronisierte Geheimnisse sind kritische Geschäftsressourcen. Daher werden sie vom SSE durch isolierte Namespaces und Knoten, RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) und eingeschränkte Berechtigungen für die Geheimnissynchronisierung geschützt. Um zusätzlichen Schutz zu gewährleisten, verschlüsseln Sie den Kubernetes-Geheimnisspeicher in Ihrem Cluster.

Tipp

Die SSE wird für Szenarien empfohlen, in denen Offlinezugriff erforderlich ist oder wenn Geheimnisse mit dem Kubernetes-Geheimnisspeicher synchronisiert werden müssen. Wenn Sie diese Features nicht benötigen, können Sie die Azure Key Vault-Geheimnisanbietererweiterung für die Geheimnisverwaltung in Ihren Arc-fähigen Kubernetes-Clustern verwenden. Es wird nicht empfohlen, die Azure Key Vault-Geheimnisanbietererweiterung für den Onlinezugriff und die SSE für den Offlinezugriff nebeneinander in einem Cluster auszuführen.

In diesem Artikel erfahren Sie, wie Sie die SSE als Azure Arc-fähige Kubernetes-Erweiterung installieren und konfigurieren.

Wichtig

Die SSE befindet sich derzeit in der VORSCHAU. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Voraussetzungen

  • Ein Arc-fähiger Cluster. Hierbei kann es sich um einen Cluster handeln, mit dem Sie selbst die Verbindung hergestellt haben (die Beispiele in diesem Handbuch verwenden einen K3s-Cluster), oder einen von Microsoft verwalteten Azure Arc-fähigen AKS-Cluster. Der Cluster muss die Kubernetes-Version 1.27 oder höher ausführen und sich in einer der unterstützten Regionen (USA, Osten, USA, Osten 2, USA, Westen, USA, Westen 2, USA, Westen 3, Europa, Westen, „Europa, Norden) befinden. Die Region wird durch die Ressourcengruppenregion definiert, die zum Erstellen des Arc-Clusters verwendet wird.
  • Stellen Sie sicher, dass Sie die allgemeinen Voraussetzungen für Clustererweiterungen erfüllen und u. a. die aktuelle Version der Azure CLI-Erweiterung k8s-extension nutzen.
  • Zur Unterstützung von TLS für die clusterinterne Protokollkommunikation ist cert-manager erforderlich. Die Beispiele weiter unten in diesem Handbuch leiten Sie durch die Installation. Weitere Informationen zu cert-manager finden Sie unter cert-manager.io.

Installieren Sie die Azure CLI, und melden Sie sich an, sofern Sie dies noch nicht getan haben:

az login

Bevor Sie beginnen, legen Sie Umgebungsvariablen fest, die zum Konfigurieren von Azure- und Clusterressourcen verwendet werden sollen. Wenn Sie bereits über eine verwaltete Identität, eine Azure Key Vault-Instanz oder eine andere hier aufgelistete Ressource verfügen, aktualisieren Sie die Namen in den Umgebungsvariablen so, dass sie diese Ressourcen widerspiegeln.

export RESOURCE_GROUP="AzureArcTest"
export CLUSTER_NAME="AzureArcTest1"
export LOCATION="EastUS"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
az account set --subscription "${SUBSCRIPTION}"
export AZURE_TENANT_ID="$(az account show -s $SUBSCRIPTION --query tenantId --output tsv)"
export CURRENT_USER="$(az ad signed-in-user show --query userPrincipalName --output tsv)"
export KEYVAULT_NAME="my-kv"
export KEYVAULT_SECRET_NAME="my-secret"
export USER_ASSIGNED_IDENTITY_NAME="my-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="my-credential"
export KUBERNETES_NAMESPACE="my-namespace"
export SERVICE_ACCOUNT_NAME="my-service-account"

Aktivieren des Workload-Identitätsverbunds in Ihrem Cluster

Die SSE verwendet ein Feature mit dem Namen Workload-Identitätsverbund, um auf Azure Key Vault-Geheimnisse zuzugreifen und diese zu synchronisieren. In diesem Abschnitt wird beschrieben, wie Sie sie einrichten. In den folgenden Abschnitten wird erläutert, wie sie ausführlich verwendet wird.

Tipp

Die folgenden Schritte basieren auf der Schrittanleitung zum Konfigurieren von Arc-fähigem Kubernetes mit dem Workload-Identitätsverbund. Weitere Unterstützung finden Sie in dieser Dokumentation.

Wenn Ihr Cluster noch nicht mit Azure Arc verbunden ist, führen Sie diese Schritte aus. Aktivieren Sie während der Schritte den Workload-Identitätsverbund als Teil des Befehls connect:

az connectedk8s connect --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer --enable-workload-identity

Wenn Ihr Cluster bereits mit Azure Arc verbunden ist, aktivieren Sie die Workloadidentität mithilfe des Befehls update:

az connectedk8s update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer --enable-workload-identity

Konfigurieren Sie Ihren Cluster nun so, dass Dienstkontotoken mit einer neuen Aussteller-URL (service-account-issuer) ausgegeben werden, mit der Microsoft Entra ID die für die Überprüfung dieser Token erforderlichen öffentlichen Schlüssel finden kann. Diese öffentlichen Schlüssel gelten für den eigenen Dienstkonto-Tokenherausgeber des Clusters, und sie wurden aufgrund der oben festgelegten Option --enable-oidc-issuer unter dieser URL abgerufen und in der Cloud gehostet.

Optional können Sie auch Grenzwerte für die eigenen Berechtigungen der SSE als privilegierte Ressource konfigurieren, die auf der Steuerungsebene ausgeführt wird, indem Sie den Zugangscontroller OwnerReferencesPermissionEnforcement konfigurieren. Dieser Zugangscontroller schränkt ein, in welchem Maß die SSE andere Objekte im Cluster ändern kann.

  1. Konfigurieren Sie kube-apiserver mit dem Feld für die Aussteller-URL und der Berechtigungserzwingung. Das folgende Beispiel ist für einen k3s-Cluster. Ihr Cluster verfügt möglicherweise über andere Mittel zur Änderung der API-Serverargumente: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".

    • Rufen Sie die Dienstkontoaussteller-URL ab.

      export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER

    • Öffnen Sie die Konfigurationsdatei für den k3s-Server.

      sudo nano /etc/systemd/system/k3s.service

    • Bearbeiten Sie die Serverkonfiguration so, dass sie wie im folgenden Beispiel aussieht, indem Sie <SERVICE_ACCOUNT_ISSUER> durch die Ausgabe von echo $SERVICE_ACCOUNT_ISSUER ersetzen. Denken Sie daran, den nachstehenden Schrägstrich dieser URL einzuschließen:

      ExecStart=/usr/local/bin/k3s \
  server --write-kubeconfig-mode=644 \
     --kube-apiserver-arg="--service-account-issuer=<SERVICE_ACCOUNT_ISSUER>" \
     --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement"

  2. Starten Sie „kube-apiserver“ neu.

    sudo systemctl daemon-reload
sudo systemctl restart k3s

Erstellen eines Geheimnisses und konfigurieren einer Identität für den Zugriff auf Geheimnisse

Um auf ein bestimmtes Azure Key Vault-Geheimnis zuzugreifen und dieses zu synchronisieren, benötigt die SSE Zugriff auf eine verwaltete Azure-Identität mit entsprechenden Azure-Berechtigungen für den Zugriff auf dieses Geheimnis. Die verwaltete Identität muss mithilfe des zuvor aktivierten Workload-Identitätsverbunds mit einem Kubernetes-Dienstkonto verknüpft werden. Die SSE verwendet die zugeordnete verwaltete Azure-Verbundidentität, um Geheimnisse aus Azure Key Vault in Ihren Kubernetes-Geheimnisspeicher zu pullen. In den folgenden Abschnitten wird die Vorgehensweise zur Einrichtung beschrieben.

Erstellen einer Azure Key Vault-Instanz

Erstellen Sie eine Azure Key Vault-Instanz, und fügen Sie ein Geheimnis hinzu. Wenn Sie bereits über eine Azure Key Vault-Instanz und ein Geheimnis verfügen, können Sie diesen Abschnitt überspringen.

  1. Erstellen einer Azure Key Vault-Instanz:

    az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization

  2. Erteilen Sie sich selbst die Berechtigung „Geheimnisbeauftragter“ für den Tresor, damit Sie ein Geheimnis erstellen können:

    az role assignment create --role "Key Vault Secrets Officer" --assignee ${CURRENT_USER} --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

  3. Erstellen Sie ein Geheimnis, und aktualisieren Sie es so, dass Sie zwei Versionen haben:

    az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello!'
az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello2'

Erstellen einer benutzerseitig zugewiesenen verwalteten Identität

Erstellen Sie als Nächstes eine benutzerseitig zugewiesene verwaltete Identität, und erteilen Sie ihr Berechtigungen für den Zugriff auf Azure Key Vault. Wenn Sie bereits über eine verwaltete Identität mit den Berechtigungen „Key Vault-Leseberechtigter“ und „Key Vault-Geheimnisbenutzer“ für Azure Key Vault verfügen, können Sie diesen Abschnitt überspringen. Weitere Informationen finden Sie unter Erstellen einer benutzerseitig zugewiesenen verwalteten Identität und Verwenden von Geheimnis-, Schlüssel- und Zertifikatberechtigungen von Azure RBAC mit Key Vault.

  1. Erstellen Sie die benutzerseitig zugewiesene verwaltete Identität:

    az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

  2. Erteilen Sie der Identität Berechtigungen vom Typ „Key Vault-Leseberechtigter“ und „Key Vault-Geheimnisbenutzer“. Möglicherweise müssen Sie einen Moment auf die Replikation der Identitätserstellung warten, bevor diese Befehle erfolgreich sind:

    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)"
az role assignment create --role "Key Vault Reader" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}
az role assignment create --role "Key Vault Secrets User" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

Erstellen von Anmeldeinformationen für eine Verbundidentität

Erstellen Sie ein Kubernetes-Dienstkonto für die Workload, die Zugriff auf Geheimnisse benötigt. Erstellen Sie dann Anmeldeinformationen für eine Verbundidentität, um eine Verknüpfung zwischen der verwalteten Identität, dem OIDC-Dienstkontoaussteller und dem Kubernetes-Dienstkonto herzustellen.

  1. Erstellen Sie ein Kubernetes-Dienstkonto, das im Verbund mit der verwalteten Identität verwendet wird. Kommentieren Sie es mit Details der zugeordneten benutzerseitig zugewiesenen verwalteten Identität.

    kubectl create ns ${KUBERNETES_NAMESPACE}

    cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${KUBERNETES_NAMESPACE}
EOF

  2. Erstellen Sie Anmeldeinformationen für eine Verbundidentität:

    az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name ${USER_ASSIGNED_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --issuer ${SERVICE_ACCOUNT_ISSUER} --subject system:serviceaccount:${KUBERNETES_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

Installieren der SSE

Die SSE ist als Azure Arc-Erweiterung verfügbar. Ein Azure Arc-fähiger Kubernetes-Cluster kann mit Azure Arc-fähigen Kubernetes-Erweiterungen erweitert werden. Erweiterungen ermöglichen Azure-Funktionen in Ihren verbundenen Clustern und bieten eine von Azure Resource Manager unterstützte Benutzeroberfläche für die Installation und Lebenszyklusverwaltung von Erweiterungen.

cert-manager und trust-manager sind auch für die sichere Kommunikation von Protokollen zwischen Clusterdiensten erforderlich und müssen vor der Arc-Erweiterung installiert werden.

  1. Installieren Sie cert-manager.

    helm repo add jetstack https://charts.jetstack.io/ --force-update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.16.2 --set crds.enabled=true

  2. Installieren Sie trust-manager.

    helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait

  3. Installieren Sie die SSE mit dem folgenden Befehl in Ihrem Arc-fähigen Cluster:

    az k8s-extension create \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --extension-type microsoft.azure.secretstore \
  --resource-group ${RESOURCE_GROUP} \
  --release-train preview \
  --name ssarcextension \
  --scope cluster

    Bei Bedarf können Sie optional das standardmäßige Rotationsabrufintervall ändern, indem Sie --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds> hinzufügen:

    Parametername Beschreibung Standardwert
    rotationPollIntervalInSeconds Gibt an, wie schnell die SSE das von ihr verwaltete Geheimnis überprüft oder aktualisiert. 3600 (1 Stunde)

Konfigurieren der SSE

Konfigurieren Sie die installierte Erweiterung mit Informationen zu Ihrer Azure Key Vault-Instanz und den Geheimnissen, die mit Ihrem Cluster synchronisiert werden sollen, indem Sie Instanzen von benutzerdefinierte Kubernetes-Ressourcen definieren. Sie erstellen zwei Arten von benutzerdefinierten Ressourcen:

  • Ein SecretProviderClass-Objekt zum Definieren der Verbindung mit Key Vault
  • Ein SecretSync-Objekt für jedes Geheimnis, das synchronisiert werden soll

Erstellen einer SecretProviderClass-Ressource

Die SecretProviderClass-Ressource wird verwendet, um die Verbindung mit Azure Key Vault und die Identität zu definieren, die für den Zugriff auf den Tresor verwendet werden soll. Außerdem werden die Geheimnisse, die synchronisiert werden sollen, und die Anzahl der Versionen aller Geheimnisse festgelegt, die lokal aufbewahrt werden sollen.

Sie benötigen eine separate SecretProviderClass-Ressource für jede Azure Key Vault-Instanz, die Sie synchronisieren möchten, für jede Identität, die für den Zugriff auf eine Azure Key Vault-Instanz verwendet wird, und für jeden Kubernetes-Zielnamespace.

Erstellen Sie anhand des folgenden Beispiels eine oder mehrere SecretProviderClass-YAML-Dateien mit den entsprechenden Werten für Ihre Key Vault-Instanz und Geheimnisse:

cat <<EOF > spc.yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: secret-provider-class-name                      # Name of the class; must be unique per Kubernetes namespace
  namespace: ${KUBERNETES_NAMESPACE}                    # Kubernetes namespace to make the secrets accessible in
spec:
  provider: azure
  parameters:
    clientID: "${USER_ASSIGNED_CLIENT_ID}"               # Managed Identity Client ID for accessing the Azure Key Vault with.
    keyvaultName: ${KEYVAULT_NAME}                       # The name of the Azure Key Vault to synchronize secrets from.
    objects: |
      array:
        - |
          objectName: ${KEYVAULT_SECRET_NAME}            # The name of the secret to sychronize.
          objectType: secret
          objectVersionHistory: 2                       # [optional] The number of versions to synchronize, starting from latest.
    tenantID: "${AZURE_TENANT_ID}"                       # The tenant ID of the Key Vault 
EOF

Erstellen eines SecretSync-Objekts

Jedes synchronisierte Geheimnis erfordert auch ein SecretSync-Objekt, um clusterspezifische Informationen zu definieren. Hier geben Sie Informationen wie den Namen des Geheimnisses in Ihrem Cluster und Namen für jede Version des Geheimnisses an, die in Ihrem Cluster gespeichert ist.

Erstellen Sie anhand dieser Vorlage eine SecretSync-Objekt-YAML-Datei für jedes Geheimnis. Der Kubernetes-Namespace sollte mit dem Namespace der übereinstimmenden SecretProviderClass-Ressource übereinstimmen.

cat <<EOF > ss.yaml
apiVersion: secret-sync.x-k8s.io/v1alpha1
kind: SecretSync
metadata:
  name: secret-sync-name                                  # Name of the object; must be unique per Kubernetes namespace
  namespace: ${KUBERNETES_NAMESPACE}                      # Kubernetes namespace
spec:
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}             # The Kubernetes service account to be given permissions to access the secret.
  secretProviderClassName: secret-provider-class-name     # The name of the matching SecretProviderClass with the configuration to access the AKV storing this secret
  secretObject:
    type: Opaque
    data:
    - sourcePath: ${KEYVAULT_SECRET_NAME}/0                # Name of the secret in Azure Key Vault with an optional version number (defaults to latest)
      targetKey: ${KEYVAULT_SECRET_NAME}-data-key0         # Target name of the secret in the Kubernetes secret store (must be unique)
    - sourcePath: ${KEYVAULT_SECRET_NAME}/1                # [optional] Next version of the AKV secret. Note that versions of the secret must match the configured objectVersionHistory in the secrets provider class 
      targetKey: ${KEYVAULT_SECRET_NAME}-data-key1         # [optional] Next target name of the secret in the K8s secret store
EOF

Anwenden der benutzerdefinierten Ressourcen der Konfiguration

Wenden Sie die benutzerdefinierten Ressourcen der Konfiguration mithilfe des Befehls kubectl apply an:

kubectl apply -f ./spc.yaml
kubectl apply -f ./ss.yaml

Die SSE sucht automatisch nach den Geheimnissen und beginnt, sie mit dem Cluster zu synchronisieren.

Anzeigen von Konfigurationsoptionen

Um zusätzliche Konfigurationsoptionen für diese beiden Typen benutzerdefinierter Ressourcen anzuzeigen, verwenden Sie den Befehl kubectl describe, anzuzeigen, um die CRDs im Cluster zu überprüfen:

# Get the name of any applied CRD(s)
kubectl get crds -o custom-columns=NAME:.metadata.name

# View the full configuration options and field parameters for a given CRD
kubectl describe crd secretproviderclass
kubectl describe crd secretsync

Beobachten von Geheimnissen, die mit dem Cluster synchronisiert werden

Sobald die Konfiguration angewendet wurde, beginnt automatisch die Synchronisierung der Geheimnisse mit dem Cluster in dem bei der Installation der SSE angegebenen Intervall.

Anzeigen synchronisierter Geheimnisse

Zeigen Sie die mit dem Cluster synchronisierten Geheimnisse an, indem Sie den folgenden Befehl ausführen:

# View a list of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE}

# View details of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE} -o yaml

Anzeigen des Status der letzten Synchronisierung

Um den Status der letzten Synchronisierung für ein bestimmtes Geheimnis anzuzeigen, verwenden Sie den Befehl kubectl describe für das SecretSync-Objekt. Die Ausgabe enthält den Zeitstempel der Geheimniserstellung, die Versionen des Geheimnisses und detaillierte Statusmeldungen für jedes Synchronisierungsereignis. Diese Ausgabe kann verwendet werden, um Verbindungs- oder Konfigurationsfehler zu diagnostizieren und zu beobachten, wann sich der Geheimniswert ändert.

kubectl describe secretsync secret-sync-name -n ${KUBERNETES_NAMESPACE}

Anzeigen von Geheimniswerten

Verwenden Sie den folgenden Befehl, um die synchronisierten Geheimniswerte anzuzeigen, die nun im Kubernetes-Geheimnisspeicher gespeichert sind:

kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key0}" | base64 -d
kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key1}" | base64 -d

Problembehandlung

Die SSE ist eine Kubernetes-Bereitstellung, die einen Pod mit zwei Containern enthält: dem Controller, der das Speichern von Geheimnissen im Cluster verwaltet, und dem Anbieter, der den Zugriff auf Azure Key Vault und das Pullen von Geheimnissen aus Azure Key Vault verwaltet. Jedes synchronisierte Geheimnis verfügt über ein SecretSync-Objekt, das den Status der Synchronisierung dieses Geheimnisses aus Azure Key Vault mit dem Clustergeheimnisspeicher enthält.

Sehen Sie sich zur Problembehandlung zunächst den Status des SecretSync-Objekts an, wie unter Anzeigen des Status der letzten Synchronisierung beschrieben. In der folgenden Tabelle sind allgemeine Statustypen, ihre Bedeutungen und mögliche Schritte zur Problembehandlung aufgeführt, um Fehler zu beheben.

SecretSync-Statustyp Details Schritte zur Behebung/weiteren Untersuchung
CreateSucceeded Das Geheimnis wurde erfolgreich erstellt. Nicht zutreffend
CreateFailedProviderError Fehler bei der Erstellung des Geheimnisses aufgrund eines Problems mit dem Anbieter (Verbindung mit Azure Key Vault). Dieser Fehler kann auf die Internetverbindung, unzureichende Berechtigungen der Identität zur Geheimnissynchronisierung, die Fehlkonfiguration von SecretProviderClass oder andere Probleme zurückzuführen sein. Untersuchen Sie das Problem genauer, indem Sie sich die Protokolle des Anbieters mithilfe der folgenden Befehle ansehen:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
CreateFailedInvalidLabel Fehler bei der Erstellung des Geheimnisses, da das Geheimnis bereits ohne die richtige Kubernetes-Bezeichnung vorhanden ist, die die SSE zum Verwalten der Geheimnisse verwendet. Entfernen Sie die vorhandene Bezeichnung und das Geheimnis, und erlauben Sie der SSE, das Geheimnis neu zu erstellen: kubectl delete secret <secret-name>
Um zu erzwingen, dass die SSE das Geheimnis schneller neu erstellt, als durch das konfigurierte Rotationsabrufintervall vorgesehen, löschen Sie das SecretSync-Objekt (kubectl delete secretsync <secret-name>), und wenden Sie die Geheimnissynchronisierungsklasse erneut an (kubectl apply -f <path_to_secret_sync>).
CreateFailedInvalidAnnotation Fehler bei der Erstellung des Geheimnisses, da das Geheimnis bereits ohne die richtige Kubernetes-Anmerkung vorhanden ist, die die SSE zum Verwalten der Geheimnisse verwendet. Entfernen Sie die vorhandene Anmerkung und das Geheimnis, und erlauben Sie der SSE, das Geheimnis neu zu erstellen: kubectl delete secret <secret-name>
Um zu erzwingen, dass die SSE das Geheimnis schneller neu erstellt, als durch das konfigurierte Rotationsabrufintervall vorgesehen, löschen Sie das SecretSync-Objekt (kubectl delete secretsync <secret-name>), und wenden Sie die Geheimnissynchronisierungsklasse erneut an (kubectl apply -f <path_to_secret_sync>).
UpdateNoValueChangeSucceeded Die SSE hat Azure Key Vault am Ende des konfigurierten Abrufintervalls auf Updates überprüft, es waren jedoch keine Änderungen für die Synchronisierung vorhanden. Nicht zutreffend
UpdateValueChangeOrForceUpdateSucceeded Die SSE hat Azure Key Vault auf Updates überprüft und den Wert aktualisiert. Nicht zutreffend
UpdateFailedInvalidLabel Fehler beim Aktualisieren des Geheimnisses, da die Bezeichnung des Geheimnisses geändert wurde, die die SSE zum Verwalten der Geheimnisse verwendet. Entfernen Sie die vorhandene Bezeichnung und das Geheimnis, und erlauben Sie der SSE, das Geheimnis neu zu erstellen: kubectl delete secret <secret-name>
Um zu erzwingen, dass die SSE das Geheimnis schneller neu erstellt, als durch das konfigurierte Rotationsabrufintervall vorgesehen, löschen Sie das SecretSync-Objekt (kubectl delete secretsync <secret-name>), und wenden Sie die Geheimnissynchronisierungsklasse erneut an (kubectl apply -f <path_to_secret_sync>).
UpdateFailedInvalidAnnotation Fehler beim Aktualisieren des Geheimnisses, da die Anmerkung des Geheimnisses geändert wurde, die die SSE zum Verwalten der Geheimnisse verwendet. Entfernen Sie die vorhandene Anmerkung und das Geheimnis, und erlauben Sie der SSE, das Geheimnis neu zu erstellen: kubectl delete secret <secret-name>
Um zu erzwingen, dass die SSE das Geheimnis schneller neu erstellt, als durch das konfigurierte Rotationsabrufintervall vorgesehen, löschen Sie das SecretSync-Objekt (kubectl delete secretsync <secret-name>), und wenden Sie die Geheimnissynchronisierungsklasse erneut an (kubectl apply -f <path_to_secret_sync>).
UpdateFailedProviderError Fehler beim Aktualisieren des Geheimnisses aufgrund eines Problems mit dem Anbieter (Verbindung mit Azure Key Vault). Dieser Fehler kann auf die Internetverbindung, unzureichende Berechtigungen der Identität zur Geheimnissynchronisierung, die Konfiguration von SecretProviderClass oder andere Probleme zurückzuführen sein. Untersuchen Sie das Problem genauer, indem Sie sich die Protokolle des Anbieters mithilfe der folgenden Befehle ansehen:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
UserInputValidationFailed Fehler beim Aktualisieren des Geheimnisses, da die Geheimnissynchronisierungsklasse falsch konfiguriert wurde (z. B. mit einem ungültigen Geheimnistyp). Überprüfen Sie die Definition der Geheimnissynchronisierungsklasse, und korrigieren Sie alle Fehler. Löschen Sie dann das SecretSync-Objekt (kubectl delete secretsync <secret-name>), löschen Sie die Geheimnissynchronisierungsklasse (kubectl delete -f <path_to_secret_sync>), und wenden Sie die Geheimnissynchronisierungsklasse erneut an (kubectl apply -f <path_to_secret_sync>).
ControllerSpcError Fehler beim Aktualisieren des Geheimnisses, da die SSE die Anbieterklasse nicht abrufen konnte oder die Anbieterklasse falsch konfiguriert ist. Überprüfen Sie die Anbieterklasse, und korrigieren Sie alle Fehler. Löschen Sie dann das SecretSync-Objekt (kubectl delete secretsync <secret-name>), löschen Sie die Anbieterklasse (kubectl delete -f <path_to_provider>), und wenden Sie die Anbieterklasse erneut an (kubectl apply -f <path_to_provider>).
ControllerInternalError Fehler beim Aktualisieren des Geheimnisses aufgrund eines internen Fehlers in der SSE. Weitere Informationen finden Sie in den SSE-Protokollen oder -Ereignissen:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'
SecretPatchFailedUnknownError Fehler beim Aktualisieren des Geheimnisses beim Patchen des Kubernetes-Geheimniswerts. Dieser Fehler kann auftreten, wenn das Geheimnis von einer anderen Instanz als der SSE geändert wurde oder wenn während eines SSE-Updates Probleme aufgetreten sind. Versuchen Sie, das Geheimnis und das SecretSync-Objekt zu löschen, und lassen Sie dann die SSE das Geheimnis neu erstellen, indem Sie die benutzerdefinierte Ressource für die Geheimnissynchronisierung erneut anwenden:
kubectl delete secret <secret-name>
kubectl delete secretsync <secret-name>
kubectl apply -f <path_to_secret_sync>

Entfernen der SSE

Um die SSE zu entfernen und die Synchronisierung von Geheimnissen zu beenden, deinstallieren Sie sie mit dem Befehl az k8s-extension delete:

az k8s-extension delete --name ssarcextension --cluster-name $CLUSTER_NAME  --resource-group $RESOURCE_GROUP  --cluster-type connectedClusters

Durch das Deinstallieren der Erweiterung werden keine Geheimnisse, SecretSync-Objekte oder CRDs aus dem Cluster entfernt. Diese Objekte müssen direkt mit kubectl entfernt werden.

Beim Löschen der SecretSync-CRD werden alle SecretSync-Objekte und standardmäßig alle eigenen Geheimnisse entfernt, Geheimnisse werden jedoch möglicherweise in folgenden Fällen beibehalten:

  • Sie haben den Besitz eines der Geheimnisse geändert.
  • Sie haben die Garbage Collection-Einstellungen in Ihrem Cluster geändert und etwa verschiedene Finalizer festgelegt.

In den oben genannten Fällen müssen Geheimnisse direkt mit kubectl gelöscht werden.

Nächste Schritte