AKS での Azure Key Vault シークレットプロバイダーアドオンのトラブルシューティング

[アーティクル]
12/13/2024

この記事では、Azure Kubernetes Service (AKS) で Azure Key Vault シークレットプロバイダーアドオンを使用するときに発生する可能性がある問題のトラブルシューティング方法について説明します。

Note

この記事は、Azure Key Vault シークレットプロバイダーの AKS マネージドアドオンバージョンに適用されます。インストールされた (自己管理された) バージョンの Helm を使用する場合は、 Azure Key Vault Provider for Secrets Store CSI Driver GitHub ドキュメントに移動します。

前提条件

Azure CLI
Kubernetes kubectl ツール (Azure CLI を使用して kubectl をインストールするには、 az aks install-cli コマンドを実行します)。
AKS クラスターで有効になっている Kubernetes シークレットストア CSI ドライバーアドオン
クライアント URL (curl) ツール
TCP 接続用の Netcat (nc) コマンドラインツール

トラブルシューティングのチェックリスト

手順 1: クラスターで Azure Key Vault シークレットプロバイダーアドオンが有効になっていることを確認する

az aks show コマンドを実行して、クラスターでアドオンが有効になっていることを確認します。

az aks show -g <aks-resource-group-name> -n <aks-name> --query 'addonProfiles.azureKeyvaultSecretsProvider'

コマンドの出力は、次のテキストのようになります。

{
  "config": null,
  "enabled": true,
  "identity": {
    "clientId": "<client-id>",
    "objectId": "<object-id>",
    "resourceId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<azure-key-vault-secrets-provider-identity-name>"
  }
}

enabled フラグが上記の出力でfalseとして表示されている場合、Azure Key Vault シークレットプロバイダーアドオンはクラスターで有効になっていません。この場合、詳細なトラブルシューティングについては、 Azure Key Vault Provider for Secrets Store CSI Driver GitHub のドキュメントを参照してください。

上記の出力でtrueとしてenabled フラグが表示されている場合、クラスターで Azure Key Vault シークレットプロバイダーアドオンが有効になります。この場合は、この記事の次の手順に進みます。

手順 2: シークレットストアプロバイダーと CSI ドライバーポッドのログを確認する

Azure Key Vault シークレットプロバイダーアドオンログは、プロバイダーポッドとドライバーポッドの両方によって生成されます。プロバイダーまたはドライバーに影響する問題をトラブルシューティングするには、アプリケーションポッドと同じノードで実行されているポッドのログを調べます。

kubectl get コマンドを実行して、アプリケーションポッドが実行されているのと同じノードで実行されているシークレットストアプロバイダーと CSI ドライバーポッドを見つけます。
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
kubectl logs コマンドを実行して、シークレットストアプロバイダーポッドのログを表示します。
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
kubectl logs コマンドを実行して、Secrets Store CSI Driver ポッドのログを表示します。
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

シークレットストアプロバイダーと CSI ドライバーポッドのログを収集したら、次のセクションで説明されている原因に対してこれらのログを分析して、問題とそれに対応する解決策を特定します。

Note

サポート要求を開く場合は、Azure Key Vault プロバイダーとシークレットストア CSI ドライバーからの関連ログを含めるのが良い方法です。

原因 1: キーコンテナーのトークンを取得できない

ログまたはイベントメッセージに次のエラーエントリが表示される場合があります。

Warning FailedMount 74s kubelet MountVolume.SetUp failed for volume "secrets-store-inline" : kubernetes.io/csi: mounter.SetupAt failed: rpc error: code = Unknown desc = failed to mount secrets store objects for pod default/test, err: rpc error: code = Unknown desc = failed to mount objects, error: failed to get keyvault client: failed to get key vault token: nmi response failed with status code: 404, err: <nilil>

このエラーは、 aad-pod-identity 内のノードマネージド ID (NMI) コンポーネントが トークン要求に関するエラーメッセージを返したために発生します。

解決策 1: NMI ポッドのログを確認する

このエラーとその解決方法の詳細については、NMI ポッドログを確認し、 Microsoft Entra ポッド ID のトラブルシューティングガイドを参照してください。

原因 2: プロバイダーポッドがキーコンテナーのインスタンスにアクセスできない

ログまたはイベントメッセージに次のエラーエントリが表示される場合があります。

E1029 17:37:42.461313 1 server.go:54] がマウント要求の処理に失敗しました。 error: keyvault。BaseClient#GetSecret: 要求の送信エラー: StatusCode=0 -- 元のエラー: コンテキストの期限を超えました

このエラーは、プロバイダーポッドがキーコンテナーインスタンスにアクセスできないために発生します。次のいずれかの理由により、アクセスが禁止される場合があります。

ファイアウォール規則がプロバイダーからのエグレストラフィックをブロックしています。
AKS クラスターで構成されているネットワークポリシーが、エグレストラフィックをブロックしています。
プロバイダーポッドはホストネットワーク上で実行されます。ポリシーによってこのトラフィックがブロックされている場合、またはノードでネットワークジッターが発生した場合、エラーが発生する可能性があります。

解決策 2: ネットワークポリシー、許可リスト、ノード接続を確認する

この問題を解決するには、次のアクションを実行します。

プロバイダーポッドを許可リストに配置します。
トラフィックをブロックするように構成されているポリシーを確認します。
ノードが Microsoft Entra ID とキーコンテナーに接続されていることを確認します。

ホストネットワークで実行されているポッドから Azure Key Vault への接続をテストするには、次の手順に従います。

ポッドを作成します。

cat <<EOF | kubectl apply --filename -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  hostNetwork: true
  containers:
  - args:
    - tail
    - -f
    - /dev/null
    image: curlimages/curl:7.75.0
    name: curl
  dnsPolicy: ClusterFirst
  restartPolicy: Always
EOF

kubectl exec を実行して、作成したポッドでコマンドを実行します。
```
kubectl exec --stdin --tty  curl -- sh
```

Azure キーコンテナーを使用して認証します。

curl -X POST 'https://login.microsoftonline.com/<aad-tenant-id>/oauth2/v2.0/token' \
     -d 'grant_type=client_credentials&client_id=<azure-client-id>&client_secret=<azure-client-secret>&scope=https://vault.azure.net/.default'

Azure キーコンテナーに既に作成されているシークレットを取得してみてください。

curl -X GET 'https://<key-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2' \
     -H "Authorization: Bearer <access-token-acquired-above>"

原因 3: SecretProviderClass カスタムリソースでユーザー割り当てマネージド ID が正しくない

"ID が見つかりません" というエラーの説明を伴う HTTP エラーコード "400" インスタンスが発生した場合、ユーザー割り当てマネージド ID は、 SecretProviderClass カスタムリソースで正しくありません。完全な応答は次のテキストのようになります。

MountVolume.SetUp failed for volume "<volume-name>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName:<key-vault-secret-name>, objectVersion:: azure.BearerAuthorizer#WithAuthorization:  
      Failed to refresh the Token for request to https://<key-vault-name>.vault.azure.net/secrets/<key-vault-secret-name>/?api-version=2016-10-01:  
        StatusCode=400 -- Original Error: adal: Refresh request failed.  
        Status Code = '400'.  
        Response body: {"error":"invalid_request","error_description":"Identity not found"}  
        Endpoint http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=<userAssignedIdentityID>&resource=https%!!(MISSING)A(MISSING)%!!(MISSING)F(MISSING)%!!(MISSING)F(MISSING)vault.azure.net

解決策 3: 正しい userAssignedIdentityID 値を使用して SecretProviderClass を更新する

適切なユーザー割り当てマネージド ID を見つけて、 SecretProviderClass カスタムリソースを更新して、 userAssignedIdentityID パラメーターに正しい値を指定します。適切なユーザー割り当てマネージド ID を見つけるには、Azure CLI で次の az aks show コマンドを実行します。

az aks show --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
    --output tsv

SecretProviderClassカスタムリソースを YAML 形式で設定する方法については、「シークレットストア CSI ドライバー用の Azure Key Vault プロバイダーにアクセスするための ID の作成」の「ユーザー割り当てマネージド ID を使用する」セクションを参照してください。

原因 4: Key Vault のプライベートエンドポイントが AKS ノードとは異なる仮想ネットワーク上にある

パブリックネットワークアクセスは Azure Key Vault レベルでは許可されず、AKS と Key Vault の間の接続はプライベートリンクを介して行われます。ただし、AKS ノードと Key Vault のプライベートエンドポイントは、異なる仮想ネットワーク上にあります。このシナリオでは、次のテキストのようなメッセージが生成されます。

MountVolume.SetUp failed for volume "<volume>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName: :<key-vault-secret-name>, objectVersion:: keyvault.BaseClient#GetSecret:  
      Failure responding to request:  
        StatusCode=403 -- Original Error: autorest/azure: Service returned an error.  
        Status=403 Code="Forbidden"  
        Message="Public network access is disabled and request is not from a trusted service nor via an approved private link.\r\n  
        Caller: appid=<application-id>;oid=<object-id>;iss=https://sts.windows.net/<id>/;xms_mirid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss;xms_az_rid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss \r\n  
        Vault: <keyvaultname>;location=<location>" InnerError={"code":"ForbiddenByConnection"}

ソリューション 4a: 仮想ネットワークリンクと仮想ネットワークピアリングを設定して仮想ネットワークを接続する

接続の問題の修正は、通常、次の 2 段階のプロセスです。

private Azure DNS ゾーンレベルで、AKS クラスターの仮想ネットワークの仮想ネットワークリンク作成します。
AKS クラスター仮想ネットワークと Key Vault プライベートエンドポイントの仮想ネットワークの間に仮想ネットワークピアリングを追加します。

これらの手順は、以下のセクションで詳しく説明します。

手順 1: 仮想ネットワークリンクを作成する

AKS クラスターノードに接続し Key Vault の完全修飾ドメイン名 (FQDN) がパブリック IP アドレスまたはプライベート IP アドレスを使用して解決されるかどうかを判断します。 "パブリックネットワークアクセスが無効で、要求が信頼されたサービスからではなく、承認済みのプライベートリンク経由で要求されていません" というエラーメッセージが表示された場合、Key Vault エンドポイントはパブリック IP アドレスを介して解決される可能性があります。このシナリオを確認するには、 nslookup コマンドを実行します。

nslookup <key-vault-name>.vault.azure.net

FQDN がパブリック IP アドレスを介して解決される場合、コマンドの出力は次のテキストのようになります。

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
<key-vault-name>.privatelink.vaultcore.azure.net  canonical name = data-prod.weu.vaultcore.azure.net.
data-prod-weu.vaultcore.azure.net  canonical name = data-prod-weu-region.vaultcore.azure.net.
data-prod-weu-region.vaultcore.azure.net  canonical name = azkms-prod-weu-b.westeurope.cloudapp.azure.com.
Name:   azkms-prod-weu-b.westeurope.cloudapp.azure.com
Address: 20.1.2.3

この場合は、プライベート DNS ゾーンレベルで AKS クラスターの仮想ネットワークの仮想ネットワークリンクを作成します。 (Key Vault プライベートエンドポイントの仮想ネットワークには、仮想ネットワークリンクが既に自動的に作成されています)。

仮想ネットワークリンクを作成するには、以下の手順を実行します。

Azure ポータルでプライベート DNSゾーンを検索して選択。
プライベート DNS ゾーンの一覧で、プライベート DNS ゾーンの名前を選択します。この例では、プライベート DNS ゾーンが privatelink.vaultcore.azure.net。
プライベート DNS ゾーンのナビゲーションウィンドウで、 Settings 見出しを見つけて、 仮想ネットワークリンクを選択します。
仮想ネットワークリンクの一覧で Add を選択します。

仮想ネットワークリンクの追加ページで、次のフィールドに入力します。

フィールド名	アクション
リンク名	仮想ネットワークリンクに使用する名前を入力します。
サブスクリプション	仮想ネットワークリンクを含めるサブスクリプションの名前を選択します。
仮想ネットワーク	AKS クラスターの仮想ネットワークの名前を選択します。

[OK] ボタンを選択します。

リンク作成手順が完了したら、 nslookup コマンドを実行します。出力は、より直接的な DNS 解決を示す次のテキストのようになります。

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
Name:   <key-vault-name>.privatelink.vaultcore.azure.net
Address: 172.20.0.4

仮想ネットワークリンクを追加した後、FQDN はプライベート IP アドレスを介して解決できる必要があります。

手順 2: 仮想ネットワーク間に仮想ネットワークピアリングを追加する

プライベートエンドポイントを使用している場合は、Key Vault レベルでパブリックアクセスを無効にしている可能性があります。そのため、AKS と Key Vault の間に接続は存在しません。この構成は、次の Netcat (nc) コマンドを使用してテストできます。

nc -v -w 2 <key-vault-name>.vault.azure.net 443

AKS と Key Vault の間で接続できない場合は、次のテキストのような出力が表示されます。

nc: connect to <key-vault-name>.vault.azure.net port 443 (tcp) timed out: Operation now in progress

AKS と Key Vault の間の接続を確立するには、次の手順に従って仮想ネットワーク間の仮想ネットワークピアリングを追加します。

Azure ポータルにアクセスします。
次のいずれかのオプションを使用して、「 Tutorial: Azure portal を使用して仮想ネットワークピアリングを使用して仮想ネットワークを接続する」の「仮想ネットワークピアの作成」セクションの手順に従って仮想ネットワークをピアリングし、仮想ネットワークが接続されていることを確認します (一方の端から)。
- AKS 仮想ネットワークに移動し、Key Vault プライベートエンドポイントの仮想ネットワークとピアリングします。
- Key Vault プライベートエンドポイントの仮想ネットワークに移動し、AKS 仮想ネットワークとピアリングします。
Azure portal で、他の仮想ネットワーク (前の手順でピアリングした仮想ネットワーク) の名前を検索して選択します。
仮想ネットワークナビゲーションウィンドウで、 Settings 見出しを見つけて、 Peerings を選択します。
仮想ネットワークピアリングページで、Name 列に、手順 2 で指定した Remote 仮想ネットワークの Peering リンク名が含まれていることを確認します。また、そのピアリングリンクの Peering status 列の値が Connected であることを確認します。

この手順を完了したら、Netcat コマンドをもう一度実行できます。これで、AKS と Key Vault の間の DNS 解決と接続が成功します。また、次の出力に示すように、Key Vault シークレットが正常にマウントされ、期待どおりに動作することを確認します。

Connection to <key-vault-name>.vault.azure.net 443 port [tcp/https] succeeded!

解決策 4b: エラーコード 403 のトラブルシューティング

Azure Key Vault REST API エラーコードリファレンス記事の「HTTP 403: アクセス許可が不十分です」セクションを確認して、エラーコード "403" のトラブルシューティングを行います。

原因 5: secrets-store.csi.k8s.io ドライバーが登録済みの CSI ドライバーの一覧にない

ポッドイベントに不足している secrets-store.csi.k8s.io ドライバーに関する次のエラーメッセージが表示された場合、シークレットストア CSI ドライバーポッドは、アプリケーションが実行されているノードで実行されていません。

警告 FailedMount 42s (x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter.SetUpAt が CSI クライアントを取得できませんでした: ドライバー名 secrets-store.csi.k8s.io 登録済みの CSI ドライバーの一覧に見つかりません

解決策 5: 同じノードで実行されているシークレットストア CSI ドライバーポッドのトラブルシューティング

次のコマンドを実行して、同じノードで実行されているシークレットストア CSI ドライバーポッドの状態を取得します。

kubectl get pod -l app=secrets-store-csi-driver -n kube-system -o wide

ポッドの状態が Running されていない場合、またはこのポッド内のコンテナーのいずれかが Ready 状態でない場合は、「シークレットストアプロバイダーと CSI ドライバーポッドログを確認するの手順に従って、このポッドのログの確認に進みます。

原因 6: SecretProviderClass が見つかりません

アプリケーションポッドについて説明すると、次のイベントが表示されることがあります。

Events:
  Type     Reason       Age               From               Message
  ----     ------       ----              ----               -------
  Warning  FailedMount  2s (x5 over 10s)  kubelet            MountVolume.SetUp failed for volume "xxxxxxx" : rpc error: code = Unknown desc = failed to get secretproviderclass xxxxxxx/xxxxxxx, error: SecretProviderClass.secrets-store.csi.x-k8s.io "xxxxxxxxxxxxx" not found

このイベントは、ポッドのボリューム仕様で参照されている SecretProviderClass が、アプリケーションポッドと同じ名前空間に存在しないことを示します。

解決策 6a: 不足している SecretProviderClass リソースを作成する

ポッドのボリューム仕様で参照されている SecretProviderClass リソースが、アプリケーションポッドが実行されているのと同じ名前空間に存在することを確認します。

解決策 6b: 正しい SecretProviderClass リソース名を参照するようにアプリケーションポッドのボリューム仕様を変更する

アプリケーションポッドのボリューム仕様を編集して、正しい SecretProviderClass リソース名を参照します。

...
spec:
  containers:
  ...
  volumes:
    - name: my-volume
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "xxxxxxxxx"

原因 7: 要求が認証されていない

"401" エラーコードで示されているように、要求は Key Vault に対して認証されていません。

解決策 7: エラーコード 401 のトラブルシューティング

Azure Key Vault REST API エラーコードリファレンス記事の"HTTP 401: 認証されていない要求" セクションを確認して、エラーコード "401" のトラブルシューティングを行います。

原因 8: 要求の数が指定された最大値を超えています

要求の数が、"429" エラーコードで示されているように、期間の指定された最大値を超えています。

解決策 8: エラーコードのトラブルシューティング 429

エラーコード "429" のトラブルシューティングを行うには、Azure Key Vault REST API エラーコードリファレンス記事の「 HTTP 429: 要求が多すぎます」セクションを確認します。

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティサポートにお問い合わせください。 Azure フィードバックコミュニティに製品フィードバックを送信することもできます。

次の方法で共有

AKS での Azure Key Vault シークレットプロバイダーアドオンのトラブルシューティング

前提条件

トラブルシューティングのチェックリスト

手順 1: クラスターで Azure Key Vault シークレットプロバイダーアドオンが有効になっていることを確認する

手順 2: シークレットストアプロバイダーと CSI ドライバーポッドのログを確認する

原因 1: キーコンテナーのトークンを取得できない

解決策 1: NMI ポッドのログを確認する

原因 2: プロバイダーポッドがキーコンテナーのインスタンスにアクセスできない

解決策 2: ネットワークポリシー、許可リスト、ノード接続を確認する

原因 3: SecretProviderClass カスタムリソースでユーザー割り当てマネージド ID が正しくない

解決策 3: 正しい userAssignedIdentityID 値を使用して SecretProviderClass を更新する

原因 4: Key Vault のプライベートエンドポイントが AKS ノードとは異なる仮想ネットワーク上にある

ソリューション 4a: 仮想ネットワークリンクと仮想ネットワークピアリングを設定して仮想ネットワークを接続する

手順 1: 仮想ネットワークリンクを作成する

手順 2: 仮想ネットワーク間に仮想ネットワークピアリングを追加する

解決策 4b: エラーコード 403 のトラブルシューティング

原因 5: secrets-store.csi.k8s.io ドライバーが登録済みの CSI ドライバーの一覧にない

解決策 5: 同じノードで実行されているシークレットストア CSI ドライバーポッドのトラブルシューティング

原因 6: SecretProviderClass が見つかりません

解決策 6a: 不足している SecretProviderClass リソースを作成する

解決策 6b: 正しい SecretProviderClass リソース名を参照するようにアプリケーションポッドのボリューム仕様を変更する

原因 7: 要求が認証されていない

解決策 7: エラーコード 401 のトラブルシューティング

原因 8: 要求の数が指定された最大値を超えています

解決策 8: エラーコードのトラブルシューティング 429

お問い合わせはこちらから

フィードバック

その他のリソース

次の方法で共有

AKS での Azure Key Vault シークレット プロバイダー アドオンのトラブルシューティング

前提条件

トラブルシューティングのチェックリスト

手順 1: クラスターで Azure Key Vault シークレット プロバイダー アドオンが有効になっていることを確認する

手順 2: シークレット ストア プロバイダーと CSI ドライバー ポッドのログを確認する

原因 1: キー コンテナーのトークンを取得できない

解決策 1: NMI ポッドのログを確認する

原因 2: プロバイダー ポッドがキー コンテナーのインスタンスにアクセスできない

解決策 2: ネットワーク ポリシー、許可リスト、ノード接続を確認する

原因 3: SecretProviderClass カスタム リソースでユーザー割り当てマネージド ID が正しくない

解決策 3: 正しい userAssignedIdentityID 値を使用して SecretProviderClass を更新する

原因 4: Key Vault のプライベート エンドポイントが AKS ノードとは異なる仮想ネットワーク上にある

ソリューション 4a: 仮想ネットワークリンクと仮想ネットワーク ピアリングを設定して仮想ネットワークを接続する

手順 1: 仮想ネットワーク リンクを作成する

手順 2: 仮想ネットワーク間に仮想ネットワーク ピアリングを追加する

解決策 4b: エラー コード 403 のトラブルシューティング

原因 5: secrets-store.csi.k8s.io ドライバーが登録済みの CSI ドライバーの一覧にない

解決策 5: 同じノードで実行されているシークレット ストア CSI ドライバー ポッドのトラブルシューティング

原因 6: SecretProviderClass が見つかりません

解決策 6a: 不足している SecretProviderClass リソースを作成する

解決策 6b: 正しい SecretProviderClass リソース名を参照するようにアプリケーション ポッドのボリューム仕様を変更する

原因 7: 要求が認証されていない

解決策 7: エラー コード 401 のトラブルシューティング

原因 8: 要求の数が指定された最大値を超えています

解決策 8: エラー コードのトラブルシューティング 429

お問い合わせはこちらから

フィードバック

その他のリソース

AKS での Azure Key Vault シークレットプロバイダーアドオンのトラブルシューティング

手順 1: クラスターで Azure Key Vault シークレットプロバイダーアドオンが有効になっていることを確認する

手順 2: シークレットストアプロバイダーと CSI ドライバーポッドのログを確認する

原因 1: キーコンテナーのトークンを取得できない

原因 2: プロバイダーポッドがキーコンテナーのインスタンスにアクセスできない

解決策 2: ネットワークポリシー、許可リスト、ノード接続を確認する

原因 3: SecretProviderClass カスタムリソースでユーザー割り当てマネージド ID が正しくない

原因 4: Key Vault のプライベートエンドポイントが AKS ノードとは異なる仮想ネットワーク上にある

ソリューション 4a: 仮想ネットワークリンクと仮想ネットワークピアリングを設定して仮想ネットワークを接続する

手順 1: 仮想ネットワークリンクを作成する

手順 2: 仮想ネットワーク間に仮想ネットワークピアリングを追加する

解決策 4b: エラーコード 403 のトラブルシューティング

解決策 5: 同じノードで実行されているシークレットストア CSI ドライバーポッドのトラブルシューティング

解決策 6b: 正しい SecretProviderClass リソース名を参照するようにアプリケーションポッドのボリューム仕様を変更する

解決策 7: エラーコード 401 のトラブルシューティング

解決策 8: エラーコードのトラブルシューティング 429