外部シークレットのトラブルシューティング

EKS/AKS の Automation Suite における外部シークレットの演算子に関する問題の解決策

概要

このセクションでは、Automation Suite の外部シークレット演算子と secretstore の構成に関連する問題を解決するためのトラブルシューティング手順について説明します。

クラスターと外部シークレット プロバイダー間の同期または認証の問題を特定して解決するには、このセクションで説明されている手順に従います。

外部シークレットの検証 ポッドのステータスとログ

まず、External Secrets Operator ポッドが正しく実行されていることを確認します。

ポッドが [実行中 ] ステートでない場合、または再起動が繰り返される場合は、認証、権限、または設定ミスに関連するエラーがないかログを確認します。

外部シークレット ポッドのステータスをチェックしてログを表示するには、次のコマンドを実行します。

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

たとえば、特定のポッドのログを表示するには、次のコマンドを実行します。

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

SecretStore オブジェクトと ExternalSecret オブジェクトを検査する

ポッドが正しく実行されている場合は、SecretStore リソースと ExternalSecret リソースが適切に構成され、同期されていることを確認します。

これらのリソースは、外部シークレットを取得および保存する方法を定義するため、設定に誤りがあると同期が正常に完了しなくなる可能性があります。

• ExternalSecret リソースを確認する まず、クラスター内の ExternalSecret オブジェクトを確認します。これは、リソースが SecretStore に正しくリンクされていること、および同期ステータスが有効であることの確認に役立ちます。
  • ExternalSecret リソースを表示および検査するには、次のコマンドを実行します。

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

  • たとえば、 uipath 名前空間の特定の ExternalSecret を確認するには、以下の手順を実行します。

    kubectl describe externalsecret azure-secret-store -n uipath
    

• SecretStore リソースを確認する 関連する SecretStore 構成を調べます。このリソースは、シークレット プロバイダー (Azure Key Vault など) の接続の詳細を定義します。ここでエラーが発生すると、シークレットの同期がブロックされる可能性があります。
  • SecretStore 定義を確認するには、次のコマンドを使用します。

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

  • たとえば、 uipath 名前空間の SecretStore 設定を調べるには、次のようにします。

    kubectl describe secretstore azure-secretstore -n uipath
    

• 外部シークレットに関連するイベントを確認する External Secrets Operator に関連する Kubernetes イベントを確認します。これらのイベントにより、同期の失敗、アクセス許可の問題、またはプロバイダーの構成ミスが明らかになる可能性があります。

  • 関連するイベントを表示するには、次のコマンドを実行します。

    kubectl get events -A | grep external-secrets
    

    イベント出力を確認するときは、次の点を確認します。

    • [ステータス] セクションのエラー メッセージ
    • Ready: Trueかどうかを示す条件
    • [イベント] セクションの警告または同期の失敗

シークレット ストアの資格情報を検証する

シークレット プロバイダーとして Azure Key Vault を使用している場合は、資格情報と設定が有効かつ最新であることを確認してください。

資格情報が正しくないか、権限がないことは、同期エラーの一般的な原因です。

• 認証資格情報
  • clientId、clientSecret、tenantId の値が正しいことを確認します。
  • サービス プリンシパルに Key Vault に対する必要なアクセス許可があることを確認します。
• Key Vault のアクセス ポリシー
  • シークレットの Get 権限と List 権限を確認します。
  • Key Vault のファイアウォールの設定で、クラスターからのアクセスが許可されていることを確認します。
• ワークロード ID の構成 (該当する場合)
  • フェデレーション資格情報が正しく設定されていることを確認します。
  • 関連付けられているサービス アカウントに必要なアノテーションがあることを確認します。
• Key Vault URI

  • SecretStore 設定の vaultUrl が正しいことを確認します。

    形式の例:

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

Azure Key Vault サービス プリンシパルのアクセス許可を確認する

デプロイでサービス プリンシパルを使用している場合は、Azure Key Vault からシークレットを取得するためのアクセス権があることを確認します。

サービス プリンシパルがアクセスできるシークレットを一覧表示するには、次のコマンドを実行します。

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

HashiCorp Vault の接続と認証を確認する

シークレット プロバイダーとして HashiCorp Vault を使用している場合は、以下を確認します。

• Test Vault サーバーへのアクセス可能性 SecretStore構成のボールト・サーバーURLが、クラスタへのネットワーク・アクセスを持つノードまたはジャンプホストから到達可能であることを確認します:

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

  正常な Vault は、 "initialized": true と "sealed": falseを含む JSON 応答を返します。コマンドがタイムアウトするか、 connection refusedを返す場合は、クラスタと Vault サーバ間のネットワーク ポリシーとファイアウォール ルールを確認します。

• ヴォールトの封印状態の確認

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

  "sealed": trueの場合、ESOがシークレットを取得する前に、Vaultサーバの封印を解除する必要があります。

• Kubernetes 認証ログインをテストするauth_type: kubernetesを使用する場合は、サービスアカウントトークンが Vault に対して認証できることを確認します。まず、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)
  

  次に、ログインをテストします。

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

  成功した応答には client_tokenが含まれます。permission deniedエラーは、Vault ロールでサービス アカウントが許可されていないか、Kubernetes 認証方法が正しく設定されていないことを示します。

• AppRole 認証ログインのテスト [ auth_type: approle] を使用している場合は、AppRole の資格情報を確認します。

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

  これが失敗した場合は、AppRole secret-id の有効期限が切れていないことを確認してください (secret_id_ttl)。

• AppRole の資格情報のシークレットが存在することを確認する

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

  シークレットには、 role-id キーと secret-id キーの両方を含める必要があります。

• Vault KV v2 からのシークレットの読み取りのテスト 上記の認証手順から取得した Vault トークンを使用します。

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

  KV v1 の場合は、パスから /data/ を削除します。応答が no value found at pathの場合は、 hashicorp_kv.version が実際のエンジン バージョンと一致することを確認します。

• KV エンジンのバージョンを確認する 設定の hashicorp_kv.version が、Vaultで有効になっている実際のKVエンジンのバージョン(v1 または v2)と一致していることを確認します。v1 と v2 では異なる API パスが使用されるため、不一致では no value found at path エラーが発生します。

• Kubernetes 認証設定を確認する Vault Kubernetes 認証メソッドが有効で、正しい kubernetes_hostが設定されていることを確認します。Vault ロールで ESO サービスアカウント (またはカスタム service_account_name) が許可されていることを確認します。

AWS Secrets Manager の接続とアクセス許可を確認する

AWS Secrets Manager をシークレットプロバイダーとして使用している場合は、以下を確認します。

• アクセス キーの資格情報のシークレットが存在することを確認する

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

  シークレットには、 access-key-id キーと secret-access-key キーの両方を含める必要があります。

• AWS Secrets Manager へのアクセスをテストする アクセス キーの資格情報を使用して、シークレットを取得できることを確認します。

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

  • AccessDeniedException - IAM ユーザーに secretsmanager:GetSecretValue 権限がありません。
  • ResourceNotFoundException - シークレットは指定されたリージョンに存在しません。aws_kv.region値を確認します。

• リージョンの設定を確認するaws_kv.region値がシークレットが保存されているリージョンと一致することを確認します。領域が一致しないと ResourceNotFoundException エラーが発生します。

TLS および CA 証明書の問題

Vault または AWS エンドポイントがプライベート CA 証明書で HTTPS を使用する場合は、以下を確認します。

• 追加の CA 証明書のシークレットが存在するかどうかを確認する

  kubectl get secret additional-ca-certificates -n uipath
  

• CA 証明書の内容を確認する

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

  証明書の有効期限が切れていないこと、および発行者が Vault または AWS エンドポイントで使用されている CA と一致していることを確認してください。

• TLS ハンドシェイクをテストする

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

  「 SSL certificate problem: unable to get local issuer certificate」と表示される場合、CA 証明書は信頼されていません。additional_ca_certs が input.jsonで構成されていることを確認します。特定の CA 証明書ファイルを使用してテストするには、以下の手順を実行します。

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

設定に関する一般的な問題

次の一般的な問題と対応するエラー メッセージを確認して、問題の診断に役立ててください。

問題	考えられる原因	例 / エラー出力
クラスターでシークレットが見つからない	Kubernetes シークレットが見つからない	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
資格情報が無効です。	クライアント ID、クライアント シークレット、またはテナント ID が正しくない	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
Key Vault オブジェクトが見つからない	キーが Azure Key Vault に存在しない	external-secrets error processing spec.data[0] (key: external-object-storage-account-key), err: Secret does not exist
HashiCorp Vault にアクセスできない	サーバー URL が正しくない、またはネットワーク ポリシーがアクセスをブロックしている	connection refused OR context deadline exceeded
コンテナーの認証に失敗しました	Kubernetes サービス アカウントが Vault ロールにバインドされていない、または期限切れの AppRole secret-id	permission denied
KV バージョンの不一致	hashicorp_kv.version v2に設定されているがエンジンがv1 (またはその逆)	no value found at path
AWS 認証情報が無効です	アクセス キー ID またはシークレット アクセス キーが正しくない	InvalidClientTokenId OR SignatureDoesNotMatch
AWS シークレットが見つからない	設定したリージョンにシークレットが存在しないか、リージョンが一致しません	ResourceNotFoundException

これらの問題をさらに調査するには、コントローラ ログを確認するか、関連リソースについて説明します。

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