Résolution des problèmes de clés secrètes externes

Résoudre les problèmes avec l'opérateur de secrets externes dans Automation Suite sur OpenShift.

Vue d'ensemble (Overview)

Cette section fournit des étapes de résolution des problèmes pour résoudre les problèmes liés à la configuration de l'opérateur de clés secrètes externe et du magasin de clés secrètes dans Automation Suite.

Pour identifier et résoudre les problèmes de synchronisation ou d'authentification entre votre cluster et le fournisseur de clé secrète externe, suivez les étapes décrites dans cette section.

Vérifier le statut et les journaux du pod des clés secrètes externes

Commencez par vérifier que les pods External Secrets Operator fonctionnent correctement.

Si les pods ne sont pas dans un état En cours d'exécution ou affichent des redémarrages répétés, consultez leurs journaux pour détecter les erreurs liées à l'authentification, aux autorisations ou à une mauvaise configuration.

Pour vérifier le statut des pods External Secrets et afficher leurs journaux, exécutez :

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

Par exemple, pour afficher les journaux à partir d'un pod spécifique, exécutez :

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

Inspecter les objets SecretStore et ExternalSecret

Si les pods s'exécutent correctement, vérifiez que les ressources SecretStore et ExternalSecret sont correctement configurées et synchronisées.

Ces ressources définissent comment les clés secrètes externes sont récupérées et stockées, de sorte que toute erreur de configuration peut empêcher la réussite d’une synchronisation.

• Vérifier les ressources ExternalSecret Commencez par examiner les objets ExternalSecret de votre cluster. Cela permet de confirmer que les ressources sont correctement liées à leur SecretStore et que le statut de synchronisation est valide.

  • Pour afficher et inspecter vos ressources ExternalSecret, exécutez les commandes suivantes :

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

  • Par exemple, pour examiner un objet CléSecrèteExterne spécifique dans l'espace de noms uipath :

    kubectl describe externalsecret azure-secret-store -n uipath
    

• Vérifier les ressources du magasin secret Inspectez la configuration du magasin secret associée. Cette ressource définit les détails de connexion de votre fournisseur de secret, et les erreurs peuvent bloquer la synchronisation des secrets.

  • Pour consulter les définitions du MagasinCléSecrète, utilisez les commandes suivantes :

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

  • Par exemple, pour examiner une configuration MagasinCléSecrète dans l'espace de noms uipath :

    kubectl describe secretstore azure-secretstore -n uipath
    

• Vérifier les événements liés aux clés secrètes externes Examinez tous les événements Kubernetes liés à l’opérateur de clés secrètes externes. Ces événements peuvent révéler des échecs de synchronisation, des problèmes d'autorisation ou des erreurs de configuration du fournisseur.

  • Pour afficher les événements liés, exécutez la commande suivante :

    kubectl get events -A | grep external-secrets
    

  Lorsque vous examinez la sortie de l'événement, recherchez :

  • Messages d’erreur dans la section Statut
  • Conditions indiquant si Ready: True
  • Avertissements ou échecs de synchronisation dans la section Événements

Vérifier les identifiants du magasin secret

Si vous utilisez Azure Key Vault comme fournisseur de clé secrète, assurez-vous que les informations d'identification et la configuration sont valides et à jour.

Des informations d'identification incorrectes ou des autorisations manquantes sont des causes courantes d'échec de synchronisation.

• Identifiants d'authentification

  • Confirmez que les valeurs clientId, clientSecret et tenantId sont correctes.
  • Assurez-vous que le principal du service dispose des autorisations requises pour le coffre de clés.

• Stratégies d’accès à Key Vault

  • Vérifiez les autorisations Get et List pour les clés secrètes.
  • Assurez-vous que les paramètres du pare-feu Key Vault autorisent l'accès depuis votre cluster.

• Configuration de l'identité de la charge de travail (le cas échéant)

  • Vérifiez que les informations d’identification fédérées sont correctement configurées.
  • Assurez-vous que le compte de service associé dispose des annotations nécessaires.

• URI de Key Vault

  • Vérifiez que le vaultUrl dans votre configuration SecretStore est correct.

  Exemple de format :

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

Vérifier les autorisations principales du service Azure Key Vault

Si votre déploiement utilise un principal de service, confirmez qu’il a accès à la récupération des clés secrètes d’Azure Key Vault.

Pour répertorier les clés secrètes accessibles à votre principal de service, exécutez :

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

Vérifier la connectivité et l'authentification de HashiCorp Vault

Si vous utilisez HashiCorp Vault comme fournisseur de clé secrète, vérifiez les éléments suivants :

• Accessibilité du serveur Test Vault Confirmez que l’URL du serveur Vault dans votre configuration SecretStore est accessible à partir d’un nœud ou d’un hôte qui dispose d’un accès réseau au cluster :

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

  Un coffre-fort sain renvoie une réponse JSON avec "initialized": true et "sealed": false. Si la commande expire ou renvoie connection refused, vérifiez les stratégies réseau et les règles de pare-feu entre le cluster et le serveur Vault.

• Vérifier le statut du joint de coffre

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

  Si "sealed": true, le serveur Vault doit être désactivé avant qu'ESO puisse récupérer les clés secrètes.

• Tester la connexion d'authentification Kubernetes Si vous utilisez auth_type: kubernetes, vérifiez qu'un jeton de compte de service peut s'authentifier auprès du coffre. Tout d'abord, extrayez le jeton du pod ESO :

  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)
  

  Testez ensuite la connexion :

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

  Une réponse réussie contient un client_token. Une erreur permission denied indique que le rôle Vault n'autorise pas le compte de service ou que la méthode d'authentification Kubernetes a été mal configurée.

• Tester la connexion d'authentification AppRole Si vous utilisez auth_type: approle, vérifiez les informations d'identification AppRole :

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

  En cas d'échec, vérifiez que l'AppRole secret-id n'a pas expiré (secret_id_ttl).

• Vérifier que le secret des identifiants AppRole existe

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

  Le secret doit contenir à la fois les clés role-id et secret-id .

• Testez la lecture d'une clé secrète à partir de Vault KV v2 à l'aide d'un jeton de coffre obtenu à partir des étapes d'authentification ci-dessus :

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

  Pour KV v1, supprimez /data/ du chemin d'accès. Si la réponse est no value found at path, vérifiez que hashicorp_kv.version correspond à la version réelle du moteur.

• Vérifier la version du moteur KV Assurez-vous que hashicorp_kv.version dans votre configuration correspond à la version réelle du moteur KV activée dans Vault (v1 ou v2). Une incompatibilité génère des erreurs no value found at path car v1 et v2 utilisent des chemins d'API différents.

• Vérifiez la configuration de Kubernetes Auth Assurez-vous que la méthode Vault Kubernetes Auth est activée et configurée avec le bon kubernetes_host. Vérifiez que le rôle Vault autorise le compte de service ESO (ou personnalisé service_account_name).

Vérifier la connectivité et les autorisations d'AWS Secrets Manager

Si vous utilisez AWS Secrets Manager comme fournisseur de clé secrète, vérifiez les éléments suivants :

• Vérifier que le secret des informations d’identification de la clé d’accès existe

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

  Le secret doit contenir à la fois les clés access-key-id et secret-access-key .

• Testez l'accès à AWS Secrets Manager à l'aide des informations d'identification de la clé d'accès, vérifiez que la clé secrète peut être récupérée :

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

  • AccessDeniedException : l’utilisateur IAM ne dispose pas de l’autorisation secretsmanager:GetSecretValue .
  • ResourceNotFoundException : la clé secrète n'existe pas dans la région spécifiée. Vérifiez la valeur aws_kv.region .

• Vérifier la configuration de la région Vérifiez la valeur aws_kv.region correspond à la région où vos clés secrètes sont stockées. Une incompatibilité de région produit ResourceNotFoundException erreurs.

Problèmes de certificat TLS et CA

Lorsque le point de terminaison Vault ou AWS utilise HTTPS avec un certificat CA privé, vérifiez les éléments suivants :

• Vérifiez si la clé secrète du certificat CA supplémentaire existe

  kubectl get secret additional-ca-certificates -n uipath
  

• Vérifier le contenu du certificat CA

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

  Vérifiez que le certificat n'a pas expiré et que l'émetteur correspond à l'autorité de certification utilisée par votre point de terminaison Vault ou AWS.

• Liaison TLS de test

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

  Si vous voyez SSL certificate problem: unable to get local issuer certificate, cela signifie que le certificat CA n'est pas approuvé. Vérifiez que additional_ca_certs est configuré dans input.json. Pour tester avec un fichier de certificat CA spécifique :

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

Problèmes de configuration courants

Examinez les problèmes courants suivants ainsi que les messages d’erreur correspondants afin de diagnostiquer le problème.

Problème	Cause possible	Exemple/sortie d’erreur
Secret introuvable dans le cluster	Clé secrète Kubernetes manquante	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
Identifiants non valides	ID client, clé secrète du client ou ID de locataire incorrect(e)	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
Objet Key Vault manquant	Clé absente dans Azure Key Vault	external-secrets error processing spec.data[0] (key: external-object-storage-account-key), err: Secret does not exist
HashiCorp Vault inaccessible	URL de serveur incorrecte ou stratégie réseau bloquant l'accès	connection refused ou context deadline exceeded
Échec de l’authentification du coffre	Compte de service Kubernetes non lié au rôle Vault ou AppRole expiré secret-id	permission denied
Incompatibilité de version KV	hashicorp_kv.version défini sur v2 mais le moteur est v1 (ou vice versa)	no value found at path
Identifiants AWS non valides	ID de clé d’accès ou clé d’accès secrète incorrecte	InvalidClientTokenId ou SignatureDoesNotMatch
Clé secrète AWS introuvable	La clé secrète n’existe pas dans la région configurée ou ne correspond pas aux régions	ResourceNotFoundException

Pour enquêter sur ces problèmes, examinez les journaux du contrôleur ou décrivez les ressources associées :

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