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

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

この記事では、Azure Kubernetes Service (AKS) で Secrets Store Container Storage Interface (CSI) ドライバー用 Microsoft Azure Key Vault プロバイダーを使用するときに発生する可能性のある一般的な問題について説明します。この記事では、これらの問題を解決するためのトラブルシューティングのヒントを提供します。

前提条件

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

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

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

トラブルシューティング手順 1: シークレットストアプロバイダーのログを確認する

アプリケーションポッドが実行されているのと同じノードで実行されている secrets-store-provider-azure ポッドを見つけるには、次の kubectl get および kubectl logs secrets-store-provider-azure アプリケーションを選択するコマンドを実行します。

kubectl get pods --selector 'app in (csi-secrets-store-provider-azure, secrets-store-provider-azure)' \
    --all-namespaces \
    --output wide
kubectl logs <provider-pod-name> --since=1h | grep ^E

トラブルシューティング手順 2: シークレットストアの CSI ドライバーログを確認する

Secrets Store CSI Driver ログにアクセスするには、手順 1 と同じコマンドを実行しますが、代わりに secrets-store-csi-driver アプリケーションを選択し、 secrets-store コンテナーを指定します。

kubectl get pods --selector app=secrets-store-csi-driver --all-namespaces --output wide
kubectl logs <driver-pod-name> --container secrets-store --since=1h | grep ^E

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 ドライバーの一覧に見つかりません

解決策 5a: シークレットストア CSI ドライバーをインストールする

配置マニフェストを使用して Key Vault プロバイダーをインストールした場合は、 instructions に従ってシークレットストア CSI ドライバーをインストールします。

解決策 5b: テイント容認を追加してシークレットストア CSI ドライバーと Key Vault プロバイダーを再デプロイする

シークレットストア CSI ドライバーを既に展開している場合は、ノードがテイントされているかどうかを確認します。ノードがテイントされている場合は、テイントの容認を追加して、シークレットストア CSI ドライバーと Key Vault プロバイダーを再デプロイします。

解決策 5c: (Windows のみ) シークレットストア CSI ドライバーと Key Vault プロバイダーをインストールするときに Helm 構成値を使用する

アプリケーションが Windows ノードで実行されている場合は、Helm 構成値を使用して、シークレットストア CSI ドライバーと Key Vault プロバイダーを Windows ノードにインストールします。

原因 6: ドライバーがプロバイダーと通信できない

ログまたはイベントで次のエラーメッセージが表示された場合、ドライバーはプロバイダーと通信できません。

警告 FailedMount 85s (x10 over 5m35s) kubelet, aks-default-28951543-vmss000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter.SetupAt failed: rpc error: code = Unknown desc = failed to mount secrets store objects for pod default/nginx-secrets-store-inline-user-msi, err: failed to find provider binary azure, err: stat /etc/kubernetes/secrets-store-csi-providers/azure/provider-azure: no such file or directory

解決策 6a: (バージョン 0.0.9 より前のプロバイダーバージョン) プロバイダーポッドがすべてのノードで実行されていることを確認する

インストールされている Key Vault プロバイダーのバージョンがバージョン 0.0.9 より前の場合は、プロバイダーポッドがすべてのノードで実行されていることを確認します。

ソリューション 6b: (プロバイダーバージョン 0.0.9 以降) プロバイダー通信に gRPC を使用する

Key Vault プロバイダーバージョン 0.0.9 以降のバージョンをインストールした場合は、gRPC を使用してプロバイダーと通信するようにドライバーを構成。

原因 7: CSI ドライバーで Kubernetes シークレットを作成できない

CSI ドライバーのシークレットストアコンテナーで次のエラーメッセージが表示される場合は、ロールベースのアクセス制御 (RBAC) クラスターロールとクラスターロールバインドをインストールしていません。 CSI ドライバーがマウントされたコンテンツを Kubernetes シークレットとして同期するには、クラスターロールとクラスターロールのバインドが必要です。

E0610 22:27:02.283100 1 secretproviderclasspodstatus_controller.go:325] "Kubernetes シークレットの作成に失敗しました" err="secrets is forbidden: User \"system:serviceaccount:default:secrets-store-csi-driver\" cannot create resource \"secrets\" in API group 名前空間 \"default\"""" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"

解決策 7: 必要なクラスターロールとクラスターロールのバインドをインストールする

secrets-store-csi-driver-provider-azure GitHub リポジトリの Helm チャートを使用して CSI ドライバーと Key Vault プロバイダーをインストールまたはアップグレードする場合、secrets-store-csi-driver.syncSecret.enabled Helm パラメーターをtrueに設定します。この構成変更により、必要なクラスターロールとクラスターロールのバインドがインストールされます。

クラスターの役割とクラスターの役割のバインドがインストールされていることを確認するには、次の kubectl get コマンドを実行します。

# Synchronize as Kubernetes secret cluster role.
kubectl get clusterrole/secretprovidersyncing-role

# Synchronize as Kubernetes secret cluster role binding.
kubectl get clusterrolebinding/secretprovidersyncing-rolebinding

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

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

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

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

原因 9: 要求の数が記載された最大値を超えています

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

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

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

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

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

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

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

次の方法で共有

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

前提条件

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

トラブルシューティング手順 1: シークレットストアプロバイダーのログを確認する

トラブルシューティング手順 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 ドライバーの一覧にない

解決策 5a: シークレットストア CSI ドライバーをインストールする

解決策 5b: テイント容認を追加してシークレットストア CSI ドライバーと Key Vault プロバイダーを再デプロイする

解決策 5c: (Windows のみ) シークレットストア CSI ドライバーと Key Vault プロバイダーをインストールするときに Helm 構成値を使用する

原因 6: ドライバーがプロバイダーと通信できない

解決策 6a: (バージョン 0.0.9 より前のプロバイダーバージョン) プロバイダーポッドがすべてのノードで実行されていることを確認する

ソリューション 6b: (プロバイダーバージョン 0.0.9 以降) プロバイダー通信に gRPC を使用する

原因 7: CSI ドライバーで Kubernetes シークレットを作成できない

解決策 7: 必要なクラスターロールとクラスターロールのバインドをインストールする

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

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

原因 9: 要求の数が記載された最大値を超えています

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

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

フィードバック

その他のリソース

次の方法で共有

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

前提条件

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

トラブルシューティング手順 1: シークレット ストア プロバイダーのログを確認する

トラブルシューティング手順 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 ドライバーの一覧にない

解決策 5a: シークレット ストア CSI ドライバーをインストールする

解決策 5b: テイント容認を追加してシークレット ストア CSI ドライバーと Key Vault プロバイダーを再デプロイする

解決策 5c: (Windows のみ) シークレット ストア CSI ドライバーと Key Vault プロバイダーをインストールするときに Helm 構成値を使用する

原因 6: ドライバーがプロバイダーと通信できない

解決策 6a: (バージョン 0.0.9 より前のプロバイダー バージョン) プロバイダー ポッドがすべてのノードで実行されていることを確認する

ソリューション 6b: (プロバイダー バージョン 0.0.9 以降) プロバイダー通信に gRPC を使用する

原因 7: CSI ドライバーで Kubernetes シークレットを作成できない

解決策 7: 必要なクラスター ロールとクラスター ロールのバインドをインストールする

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

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

原因 9: 要求の数が記載された最大値を超えています

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

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

フィードバック

その他のリソース

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

トラブルシューティング手順 1: シークレットストアプロバイダーのログを確認する

トラブルシューティング手順 2: シークレットストアの CSI ドライバーログを確認する

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

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

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

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

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

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

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

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

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

解決策 5a: シークレットストア CSI ドライバーをインストールする

解決策 5b: テイント容認を追加してシークレットストア CSI ドライバーと Key Vault プロバイダーを再デプロイする

解決策 5c: (Windows のみ) シークレットストア CSI ドライバーと Key Vault プロバイダーをインストールするときに Helm 構成値を使用する

解決策 6a: (バージョン 0.0.9 より前のプロバイダーバージョン) プロバイダーポッドがすべてのノードで実行されていることを確認する

ソリューション 6b: (プロバイダーバージョン 0.0.9 以降) プロバイダー通信に gRPC を使用する

解決策 7: 必要なクラスターロールとクラスターロールのバインドをインストールする

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

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