Fehlerbehebung bei externen Geheimnissen

Lösungen für Probleme mit externen Geheimnisoperatoren in der Automation Suite auf EKS/AKS.

Überblick

Dieser Abschnitt enthält Schritte zur Fehlerbehebung im Zusammenhang mit dem Operator externer Geheimnisse und der Konfiguration des geheimen Speichers in der Automation Suite.

Um Synchronisierungs- oder Authentifizierungsprobleme zwischen Ihrem Cluster und dem externen Geheimnisanbieter zu identifizieren und zu lösen, führen Sie die in diesem Abschnitt beschriebenen Schritte aus.

Überprüfen Sie den Pod-Status und die Protokolle von External Secrets

Überprüfen Sie zunächst, ob die Pods des Operators „Externe Geheimnisse“ ordnungsgemäß ausgeführt werden.

Wenn die Pods nicht im Status „Wird ausgeführt“ sind oder wiederholte Neustarts anzeigen, überprüfen Sie ihre Protokolle auf Fehler im Zusammenhang mit Authentifizierung, Berechtigungen oder Fehlkonfigurationen.

Führen Sie Folgendes aus, um den Status der Pods für externe Geheimnisse zu überprüfen und ihre Protokolle anzuzeigen:

kubectl get pods -A | grep external-secrets
kubectl logs -f <pod-name> -n <namespace>

Führen Sie beispielsweise Folgendes aus, um Protokolle von einem bestimmten Pod anzuzeigen:

kubectl logs -f external-secrets-7d8c9b5f9f-abc12 -n external-secrets

Überprüfen Sie die Objekte SecretStore und ExternalSecret

Wenn die Pods ordnungsgemäß ausgeführt werden, stellen Sie sicher, dass die Ressourcen SecretStore und ExternalSecret ordnungsgemäß konfiguriert und synchronisiert sind.

Diese Ressourcen definieren, wie externe Geheimnisse abgerufen und gespeichert werden, sodass jede Fehlkonfiguration eine erfolgreiche Synchronisierung verhindern kann.

• Überprüfen von ExternalSecret-Ressourcen Überprüfen Sie zunächst die ExternalSecret-Objekte in Ihrem Cluster. Dadurch wird bestätigt, dass die Ressourcen korrekt mit ihrem SecretStore verknüpft sind und der Synchronisierungsstatus gültig ist.
  • Um Ihre ExternalSecret-Ressourcen anzuzeigen und zu überprüfen, führen Sie die folgenden Befehle aus:

    kubectl get externalsecrets -A
    kubectl describe externalsecret <externalsecret-name> -n <namespace>
    

  • Um beispielsweise ein bestimmtes ExternalSecret im Namespace uipath zu überprüfen:

    kubectl describe externalsecret azure-secret-store -n uipath
    

• SecretStore-Ressourcen überprüfen Überprüfen Sie die zugehörige SecretStore-Konfiguration. Diese Ressource definiert die Verbindungsdetails für Ihren Geheimnisanbieter (z. B. Azure Key Vault), und Fehler hier können die Synchronisierung von Geheimnissen blockieren.
  • Um die SecretStore-Definitionen zu überprüfen, verwenden Sie die folgenden Befehle:

    kubectl get secretstores -A
    kubectl describe secretstore <secretstore-name> -n <namespace>
    

  • Um beispielsweise eine SecretStore-Konfiguration im uipath -Namespace zu untersuchen:

    kubectl describe secretstore azure-secretstore -n uipath
    

• Überprüfen Sie Ereignisse im Zusammenhang mit externen Geheimnissen Überprüfen Sie alle Kubernetes-Ereignisse im Zusammenhang mit dem externen Geheimnisoperator. Diese Ereignisse können Synchronisierungsfehler, Berechtigungsprobleme oder Fehlkonfigurationen des Anbieters aufdecken.

  • Um verwandte Ereignisse anzuzeigen, führen Sie den folgenden Befehl aus:

    kubectl get events -A | grep external-secrets
    

    Achten Sie bei der Überprüfung der Ereignisausgabe auf Folgendes:

    • Fehlermeldungen im Abschnitt Status
    • Bedingungen, die angeben, ob Ready: True
    • Warnungen oder Synchronisierungsfehler im Abschnitt Ereignisse

Überprüfen Sie die Anmeldeinformationen für den Secret Store

Wenn Sie Azure Key Vault als Geheimnisanbieter verwenden, stellen Sie sicher, dass die Anmeldeinformationen und die Konfiguration gültig und aktuell sind.

Falsche Anmeldeinformationen oder fehlende Berechtigungen sind häufige Ursachen für Synchronisierungsfehler.

• Anmeldeinformationen für die Authentifizierung
  • Bestätigen Sie, dass die Werte clientId, clientSecret und tenantId korrekt sind.
  • Stellen Sie sicher, dass der Dienstprinzipal über die erforderlichen Berechtigungen für den Key Vault verfügt.
• Key Vault-Zugriffsrichtlinien
  • Überprüfen Sie Get und List -Berechtigungen für Geheimnisse.
  • Stellen Sie sicher, dass die Key Vault-Firewalleinstellungen den Zugriff von Ihrem Cluster aus zulassen.
• Konfiguration der Workload-Identität (falls zutreffend)
  • Überprüfen Sie, ob die verbundenen Anmeldeinformationen korrekt konfiguriert sind.
  • Stellen Sie sicher, dass das zugeordnete Dienstkonto über die erforderlichen Anmerkungen verfügt.
• Key Vault-URI

  • Stellen Sie sicher, dass der vaultUrl in Ihrer SecretStore-Konfiguration korrekt ist.

    Beispielformat:

    https://<key-vault-name>.vault.azure.net/
    

Überprüfen der Azure Key Vault-Dienstprinzipalberechtigungen

Wenn Ihre Bereitstellung einen Dienstprinzipal verwendet, bestätigen Sie, dass er Zugriff zum Abrufen von Geheimnissen aus dem Azure Key Vault hat.

Führen Sie Folgendes aus, um die Geheimnisse aufzulisten, auf die Ihr Dienstprinzipal zugreifen kann:

az keyvault secret list --vault-name <key-vault-name>

Überprüfen Sie die HashiCorp Vault-Verbindung und -Authentifizierung

Wenn Sie HashiCorp Vault als Geheimnisanbieter verwenden, überprüfen Sie Folgendes:

• Erreichbarkeit des Test Vault-Servers Bestätigen Sie, dass die Vault-Server-URL in Ihrer SecretStore-Konfiguration von einem Knoten oder Jumphost aus erreichbar ist, der Netzwerkzugriff auf den Cluster hat:

  curl -sk https://<vault-server>:8200/v1/sys/health
  

  Ein fehlerfreier Vault gibt eine JSON-Antwort mit "initialized": true und "sealed": false zurück. Wenn der Befehl eine Zeitüberschreitung auslöst oder connection refused zurückgibt, überprüfen Sie die Netzwerkrichtlinien und Firewallregeln zwischen dem Cluster und dem Vault-Server.

• Überprüfen Sie den Status der Tresor Siedung

  curl -sk https://<vault-server>:8200/v1/sys/seal-status
  

  Bei "sealed": true muss der Vault-Server geöffnet werden, bevor ESO geheime Schlüssel abrufen kann.

• Testen Sie Kubernetes-Auth-Anmeldung Wenn Sie auth_type: kubernetes verwenden, stellen Sie sicher, dass sich ein Dienstkonto-Token bei Vault authentifizieren kann. Extrahieren Sie zuerst das Token aus dem ESO-Pod:

  ESO_POD=$(kubectl get pods -n uipath -l app.kubernetes.io/name=external-secrets -o jsonpath='{.items[0].metadata.name}')
  JWT=$(kubectl exec -n uipath $ESO_POD -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  

  Testen Sie dann die Anmeldung:

  curl -sk --request POST \
    --data "{\"jwt\": \"$JWT\", \"role\": \"<vault-role>\"}" \
    https://<vault-server>:8200/v1/auth/<mount-path>/login
  

  Eine erfolgreiche Antwort enthält ein client_token. Ein permission denied -Fehler gibt an, dass die Vault-Rolle das Dienstkonto nicht zulässt oder dass die Kubernetes-Authentifizierungs-Methode falsch konfiguriert ist.

• Testen Sie die AppRole-Authentifizierungs-Anmeldung Wenn Sie auth_type: approle verwenden, überprüfen Sie die AppRole-Anmeldeinformationen:

  curl -sk --request POST \
    --data '{"role_id": "<role-id>", "secret_id": "<secret-id>"}' \
    https://<vault-server>:8200/v1/auth/<mount-path>/login
  

  Wenn dies fehlschlägt, überprüfen Sie, ob die AppRole secret-id nicht abgelaufen ist (secret_id_ttl).

• Stellen Sie sicher, dass das AppRole-Anmeldeinformationsgeheimnis vorhanden ist

  kubectl get secret <credentials-secret-name> -n uipath -o json | jq '.data | keys'
  

  Das Geheimnis muss sowohl role-id als auch secret-id -Schlüssel enthalten.

• Testen Sie das Lesen eines Geheimnisses aus Vault KV v2 mit einem Vault-Token, das aus den obigen Authentifizierungsschritten erhalten wurde:

  curl -sk -H "X-Vault-Token: <vault-token>" \
    https://<vault-server>:8200/v1/<kv-path>/data/<secret-path>
  

  Entfernen Sie bei KV v1 /data/ aus dem Pfad. Wenn die Antwort no value found at path ist, stellen Sie sicher, dass hashicorp_kv.version mit der aktuellen Engine-Version übereinstimmt.

• Version der KV-Engine überprüfen Stellen Sie sicher, dass der hashicorp_kv.version in Ihrer Konfiguration mit der tatsächlichen Version der KV-Engine übereinstimmt, die im Vault aktiviert ist (v1 oder v2). Eine Abweichung führt zu no value found at path -Fehlern, da v1 und v2 unterschiedliche API-Pfade verwenden.

• Konfiguration der Kubernetes-Authentifizierung überprüfen Stellen Sie sicher, dass die Kubernetes-Auth-Methode des Vault aktiviert und mit der richtigen kubernetes_host konfiguriert ist. Überprüfen Sie, ob die Vault-Rolle das ESO-Dienstkonto (oder eine benutzerdefinierte service_account_name) zulässt.

Überprüfen Sie die Konnektivität und Berechtigungen von AWS Secrets Manager

Wenn Sie AWS Secrets Manager als Geheimnisanbieter verwenden, überprüfen Sie Folgendes:

• Stellen Sie sicher, dass das Anmeldeinformationen-Geheimnis des Zugriffsschlüssels vorhanden ist

  kubectl get secret <credentials-secret-name> -n uipath -o json | jq '.data | keys'
  

  Das Geheimnis muss sowohl access-key-id als auch secret-access-key -Schlüssel enthalten.

• Testen des Zugriffs auf AWS Secrets Manager Stellen Sie mithilfe der Anmeldeinformationen des Zugriffsschlüssels sicher, dass das Geheimnis abgerufen werden kann:

  aws secretsmanager get-secret-value \
    --secret-id <secret-name> --region <region>
  

  • AccessDeniedException – Der IAM-Benutzer hat keine secretsmanager:GetSecretValue -Berechtigung.
  • ResourceNotFoundException – Das Geheimnis ist in der angegebenen Region nicht vorhanden. Überprüfen Sie den Wert aws_kv.region .

• Regionskonfiguration überprüfen Stellen Sie sicher, dass der aws_kv.region -Wert mit der Region übereinstimmt, in der Ihre Geheimnisse gespeichert sind. Eine Regionsabweichung führt zu ResourceNotFoundException -Fehlern.

Probleme mit TLS- und Zertifizierungsstellen

Wenn der Vault- oder AWS-Endpunkt HTTPS mit einem privaten Zertifizierungsstellenzertifikat verwendet, überprüfen Sie Folgendes:

• Überprüfen Sie, ob der zusätzliche geheime Schlüssel des Zertifikats der Zertifizierungsstelle vorhanden ist

  kubectl get secret additional-ca-certificates -n uipath
  

• Überprüfen Sie den Inhalt des Zertifikats der Zertifizierungsstelle

  kubectl get secret additional-ca-certificates -n uipath -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -text -noout
  

  Stellen Sie sicher, dass das Zertifikat nicht abgelaufen ist und der Aussteller mit der Zertifizierungsstelle übereinstimmt, die von Ihrem Vault- oder AWS-Endpunkt verwendet wird.

• Testen Sie den TLS-Handshake

  curl -v https://<vault-server>:8200/v1/sys/health
  

  Wenn Sie SSL certificate problem: unable to get local issuer certificate sehen, wird dem Zertifikat der Zertifizierungsstelle nicht vertraut. Stellen Sie sicher, dass additional_ca_certs in input.json konfiguriert ist. So testen Sie mit einer bestimmten Zertifikatsdatei einer Zertifizierungsstelle:

  curl -v --cacert /path/to/ca.crt https://<vault-server>:8200/v1/sys/health
  

Häufige Konfigurationsprobleme

Sehen Sie sich die folgenden häufigen Probleme und die entsprechenden Fehlermeldungen an, um die Problemdiagnose zu unterstützen.

Problem	Mögliche Ursache	Beispiel-/Fehlerausgabe
Geheimer Schlüssel nicht im Cluster gefunden	Fehlendes Kubernetes-Geheimnis	Warning InvalidProviderConfig 3s (x4 over 8s) secret-store cannot get Kubernetes secret "azure-service-principal-secret" from namespace "uipath": secrets "azure-service-principal-secret" not found
Ungültige Anmeldeinformationen	Client-ID, geheimer Clientschlüssel oder Mandanten-ID falsch	error processing spec.data[0] (key: external-object-storage-account-key-10176524), err: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request ... StatusCode=400
Fehlendes Key Vault-Objekt	Schlüssel ist in Azure Key Vault nicht vorhanden	external-secrets error processing spec.data[0] (key: external-object-storage-account-key), err: Secret does not exist
HashiCorp Vault nicht erreichbar	Falsche Server-URL oder Netzwerkrichtlinie, die den Zugriff blockiert	connection refused oder context deadline exceeded
Tresorauthentifizierung fehlgeschlagen	Kubernetes-Dienstkonto, das nicht an Vault-Rolle gebunden ist, oder AppRole abgelaufen secret-id	permission denied
KV-Versionen stimmen nicht überein	hashicorp_kv.version auf v2 festgelegt, aber Engine ist v1 (oder umgekehrt)	no value found at path
AWS-Anmeldeinformationen ungültig	Falsche Zugriffsschlüssel-ID oder geheimer Zugriffsschlüssel	InvalidClientTokenId oder SignatureDoesNotMatch
AWS-Geheimnis nicht gefunden	Geheimer Schlüssel ist in der konfigurierten Region nicht vorhanden, oder es liegt eine Regionskonfliktübereinstimmung vor	ResourceNotFoundException

Um diese Probleme weiter zu untersuchen, überprüfen Sie die Controller-Protokolle oder beschreiben Sie die zugehörigen Ressourcen:

kubectl describe externalsecret <name> -n <namespace>
kubectl describe secretstore <name> -n <namespace>