AKS 上のアプリケーションから Azure Key Vault のシークレット、キー、証明書を安全に使うなら、結論としては Secrets Store CSI Driver と Microsoft Entra の ID 設計をセットで確認すること が重要です。2026年5月6日前後の更新では、Azure Key Vault Provider for Secrets Store CSI Driver の導入・更新手順が整理され、Azure CLI だけでなく Terraform を前提にした展開パターンも明確になっています。認証方式は主に Service Connector、Microsoft Entra Workload ID、ユーザー割り当てマネージド ID の3つです。どれを選ぶかで、RBAC、OIDC、SecretProviderClass、サービスアカウント、移行手順の確認ポイントが変わります。(Microsoft Learn)
Microsoft EntraとAKSのKey Vault連携でまず押さえるべき結論
「Access Azure Key Vault with the CSI Driver Identity Provider – Azure Kubernetes Service」は、AKS の Pod が Azure Key Vault にアクセスするための ID 連携方法を説明する公式ドキュメントです。Secrets Store CSI Driver は、Key Vault のシークレット、キー、証明書を Kubernetes の CSI ボリュームとして Pod にマウントする仕組みで、SecretProviderClass を使って取得対象や認証方式を定義します。(Microsoft Learn)
今回確認すべきポイントは、単に「Key Vault の値を Pod にマウントできるか」ではありません。管理者や開発者は、次の3点を重点的に確認する必要があります。
- どの ID 方式で Key Vault にアクセスするのか
- Key Vault 側の権限付与が Azure RBAC なのか、アクセスポリシーなのか
- AKS 側の CSI Driver、OIDC、Workload ID、マネージド ID、
SecretProviderClassの設定が一致しているか
特に本番環境では、マネージド ID の作成場所、VM Scale Set への割り当て、Key Vault のロール、Pod の再起動時の挙動まで確認しないと、リリース後に「Pod は起動したがシークレットを読めない」「ロールを付けたのに反映されない」「移行後の namespace だけ失敗する」といったトラブルにつながります。
何が変わったのか
2026年5月6日前後の更新で実務上注目すべき点は、Identity Provider ページ単体の大幅な仕様変更というより、関連する Secrets Store CSI Driver 導入ページを含めた構成整理です。GitHub 上の変更履歴では、2026年5月5日のコミットで zone pivot と Terraform 関連の追加が行われ、対象ファイルには csi-secrets-store-driver.md、csi-secrets-store-identity-access.md、csi-secrets-store-nginx-tls.md が含まれています。(GitHub)
| 確認項目 | 更新・整理された内容 | 実務上の影響 |
|---|---|---|
| 導入手順 | Azure CLI と Terraform の作成・更新パターンが整理された | IaC で AKS と Key Vault を管理しているチームは、既存手順とのズレを確認する |
| Identity Provider ページ | 関連ページのアンカー参照が更新された | 認証方式の仕様変更というより、導線整理として把握する |
| Key Vault Provider | AKS アドオン、マネージド ID、VM Scale Set 割り当ての説明が明確化 | 自動作成される ID を削除・上書きしないように運用ルールを見直す |
| Terraform | Terraform 1.6 以降、azurerm provider 4.x 系を前提にした例が追加された | Terraform 管理下の既存クラスタでは plan の差分確認が必須 |
| Key Vault RBAC | シークレット、キー、証明書ごとの必要ロールが明示されている | secret と key/certificate で付与するロールを混同しない |
関連する CSI Driver ページでは、AKS に Key Vault Provider を有効化すると azurekeyvaultsecretsprovider-xxxxx というユーザー割り当てマネージド ID がノードリソースグループに作成され、VM Scale Set に自動で割り当てられると説明されています。この ID の作成を防ぐことはサポートされていません。(Microsoft Learn)
対象者と影響範囲
今回の内容は、Microsoft Entra 管理者だけでなく、AKS 管理者、アプリケーション開発者、IaC 担当者にも関係します。役割ごとに確認すべき範囲が異なるため、まず責任分界点を整理しておくと安全です。
| 対象者 | 主な確認ポイント | 見落とすと起きやすい問題 |
|---|---|---|
| Microsoft Entra / IAM 管理者 | Workload ID、フェデレーション資格情報、マネージド ID、ロール割り当て | Pod から Key Vault への認証が失敗する |
| AKS 管理者 | CSI Driver アドオン、OIDC issuer、VM Scale Set への ID 割り当て | ノードや Pod の再作成時にシークレットを読めない |
| アプリ開発者 | SecretProviderClass、Pod の serviceAccount、マウントパス、objectType | マニフェストは適用できても値がマウントされない |
| セキュリティ担当者 | Azure RBAC、Key Vault アクセス範囲、最小権限 | 必要以上に広い Key Vault 権限を付与してしまう |
| Terraform / IaC 担当者 | Terraform 例、既存リソース更新、terraform destroy の対象 | 共有基盤や本番 Key Vault を誤って変更・削除する |
重要なのは、Key Vault へのアクセス権限を「クラスタに付ける」のか「ワークロード単位で付ける」のかを先に決めることです。アプリごとに権限を分離したい場合は Microsoft Entra Workload ID を優先し、シンプルな検証環境や一部の共通基盤ではマネージド ID や Service Connector が適する場合があります。
3つのアクセス方式の違い
公式ドキュメントでは、Azure Key Vault にアクセスする方法として、Service Connector with managed identity、Workload ID、User-assigned managed identity が示されています。(Microsoft Learn)
| 方式 | 向いているケース | 主な設定 | 注意点 |
|---|---|---|---|
| Service Connector with managed identity | ポータルや Azure CLI で接続設定を簡略化したい場合 | az aks connection create keyvault、--enable-csi、--client-type none | 自動化や細かい権限分離が必要な環境では設計を確認する |
| Microsoft Entra Workload ID | Pod / アプリ単位で Key Vault 権限を分離したい場合 | OIDC issuer、サービスアカウント、フェデレーション資格情報、clientID | serviceAccount 名、namespace、subject の不一致で失敗しやすい |
| ユーザー割り当てマネージド ID | 既存のマネージド ID を使いたい場合、またはクラスタ側の ID で管理したい場合 | useVMManagedIdentity: "true"、userAssignedIdentityID | ワークロード単位の細かな分離には向かない場合がある |
Microsoft Entra Workload IDを選ぶべき場面
Microsoft Entra Workload ID は、Pod 上で動くアプリケーションが Azure サービスへ認証するための ID です。AKS クラスタがトークン発行者となり、Microsoft Entra ID が OIDC を使ってサービスアカウントトークンを検証し、Microsoft Entra トークンへ交換する流れになります。(Microsoft Learn)
アプリケーションごとに Key Vault のアクセス範囲を変えたい場合は、Workload ID が現実的です。たとえば、決済 API 用の Pod は決済用シークレットだけ、通知 API 用の Pod はメール送信用シークレットだけを読めるようにできます。
Workload ID で特に確認すべき設定は次の通りです。
| 設定 | 確認内容 |
|---|---|
| AKS | OIDC issuer と Workload ID が有効か |
| Microsoft Entra | ユーザー割り当てマネージド ID が作成されているか |
| フェデレーション資格情報 | system:serviceaccount:<namespace>:<serviceAccountName> が実際の Pod と一致しているか |
| Kubernetes ServiceAccount | azure.workload.identity/client-id アノテーションが正しいか |
| Pod | azure.workload.identity/use: "true" ラベルと serviceAccountName が設定されているか |
| SecretProviderClass | clientID、tenantId、keyvaultName、objects が正しいか |
なお、Microsoft Entra pod-managed identity は、Workload ID に置き換えられる認証方式として扱われており、AKS のオープンソース版 Microsoft Entra pod-managed identity は 2022年10月24日に非推奨になっています。既存環境で pod-managed identity を使っている場合は、Workload ID への移行計画を立てるべきです。(Microsoft Learn)
ユーザー割り当てマネージド IDを使う場面
ユーザー割り当てマネージド ID を使う方式では、Key Vault にアクセスする ID の clientId を SecretProviderClass に指定します。公式例では、usePodIdentity: "false"、useVMManagedIdentity: "true"、userAssignedIdentityID: <client-id> を使う構成が示されています。(GitHub)
この方式は、クラスタやノードプールに紐づく ID で Key Vault アクセスを管理したい場合に分かりやすい構成です。一方で、アプリケーションごとの最小権限を細かく設計したい場合は、Workload ID の方が運用しやすいケースがあります。
Key Vault側で確認すべきRBACと権限
Key Vault の権限設定では、対象が secret なのか、key または certificate なのかで必要なロールが変わります。Key Vault が Azure RBAC を使う設定の場合、secret には Key Vault Secrets User、key や certificate には Key Vault Certificate User が必要です。Azure RBAC を使っていない Key Vault では、az keyvault set-policy によるアクセスポリシー設定が必要になります。(Microsoft Learn)
| Key Vaultの対象 | SecretProviderClass の objectType | 主な確認ポイント |
|---|---|---|
| シークレット | secret | Key Vault Secrets User が対象 ID に付与されているか |
| キー | key | Key Vault Certificate User など必要ロールが付与されているか |
| 証明書 | cert または secret | 取得したい内容が証明書のみか、秘密鍵を含む PEM かを確認する |
証明書を扱う場合は特に注意が必要です。Key Vault の証明書は、キーとシークレットの機能を利用しており、objectType によって取得できる内容が変わります。公式ドキュメントでは、key は公開キー、cert は証明書、secret は秘密鍵と証明書を PEM 形式で返すと説明されています。(Microsoft Learn)
AKS管理者が確認すべき設定
AKS 側では、CSI Driver アドオンの有効化だけでなく、アドオンによって作成された ID と実際の Pod 設定が連動しているかを確認します。
CSI DriverとProviderの稼働確認
まず、Key Vault Provider for Secrets Store CSI Driver が Pod として動作しているか確認します。公式手順では、kube-system namespace で secrets-store-csi-driver と secrets-store-provider-azure の Pod を確認する流れが示されています。(Microsoft Learn)
kubectl get pods -n kube-system -l 'app in (secrets-store-csi-driver,secrets-store-provider-azure)' -o wide確認時は、単に Running だけを見るのではなく、次の点も合わせて見ます。
| 確認項目 | 見るべきポイント |
|---|---|
| Pod の配置 | 全ノードで必要な Pod が起動しているか |
| 再起動回数 | RESTARTS が増え続けていないか |
| ノード差分 | 特定ノードだけ Provider Pod が失敗していないか |
| アドオンの ID | addonProfiles.azureKeyvaultSecretsProvider.identity に clientId と objectId があるか |
ネットワーク制限があるクラスタの確認
ネットワーク分離されたクラスタでは、Key Vault への到達性が問題になりやすいです。公式ドキュメントでは、ネットワーク分離クラスタでは Key Vault へのプライベートエンドポイント設定が推奨され、userDefinedRouting とファイアウォールを使う場合は必要な outbound ルールと FQDN を許可する必要があると説明されています。また、Ingress を制限している場合は 9808 と 8095 のポート確認も必要です。(Microsoft Learn)
本番環境では、次のように事前確認を分けるとトラブルを減らせます。
| 環境 | 確認ポイント |
|---|---|
| Private cluster | Key Vault の private endpoint と DNS 解決 |
| Firewall 経由 | Azure Firewall などで必要な FQDN が許可されているか |
| Ingress 制限あり | CSI Driver 関連の通信に必要なポートが塞がれていないか |
| 複数リージョン | Key Vault と AKS のリージョン、レイテンシ、障害時運用 |
SecretProviderClassで失敗しやすいポイント
SecretProviderClass は、Key Vault から何を取得し、どの ID で認証するかを定義する中心的なリソースです。ここで設定ミスがあると、Key Vault 側の権限が正しくても Pod から値を取得できません。
特に確認すべき項目は次の通りです。
| 項目 | 確認内容 | よくあるミス |
|---|---|---|
keyvaultName | Key Vault 名が正しいか | リソース ID や表示名を入れてしまう |
tenantId | Key Vault のテナント ID か | AKS 側のテナントと混同する |
clientID | Workload ID のクライアント ID か | objectId や principalId を入れてしまう |
userAssignedIdentityID | マネージド ID の clientId か | リソース IDを入れて失敗する |
objectName | Key Vault 上のオブジェクト名か | objectAlias を使ったのに参照側を直していない |
objectType | secret、key、cert のいずれか | 証明書を cert と secret のどちらで取るべきか未整理 |
公式ドキュメントでも、objectAlias を使う場合は YAML 側を更新する必要があること、SecretProviderClass で参照する前に Key Vault 側へシークレット、キー、証明書を格納しておく必要があることが示されています。(Microsoft Learn)
移行・展開時の注意点
pod-managed identityからWorkload IDへ移行する場合
既存クラスタで古い Microsoft Entra pod-managed identity を使っている場合、単純に SecretProviderClass の ID を差し替えるだけでは不十分です。Workload ID では、AKS の OIDC issuer、Microsoft Entra のフェデレーション資格情報、Kubernetes のサービスアカウント、Pod のラベルがつながって初めて認証できます。
移行時は、次の順番で検証すると安全です。
| 手順 | 確認内容 |
|---|---|
| 既存棚卸し | どの Pod がどの Key Vault オブジェクトを読んでいるか確認する |
| ID作成 | アプリ単位または namespace 単位でユーザー割り当てマネージド ID を作る |
| RBAC付与 | Key Vault に必要最小限のロールを付与する |
| フェデレーション設定 | serviceAccount の namespace と名前を正確に登録する |
| マニフェスト更新 | serviceAccount、Pod label、SecretProviderClass を更新する |
| 検証 | 既存 Pod と新方式 Pod を並行稼働させ、マウント結果を比較する |
切り替え時に最も多い失敗は、フェデレーション資格情報の subject と Kubernetes 側の serviceAccount が一致していないケースです。namespace の変更、Helm chart の値変更、環境ごとの serviceAccount 名の違いに注意してください。
ロール割り当ての反映待ちを考慮する
Key Vault のロール割り当ては、作成直後にすぐ使えるとは限りません。公式ドキュメントでも、ロール割り当てが有効になるまで数分かかる場合があると説明されています。(Microsoft Learn)
CI/CD で展開する場合は、ロール付与直後に Pod を起動して失敗することがあります。対策として、ロール割り当て確認コマンドを入れる、リトライを設定する、初回起動時の失敗をアプリ側で吸収しない設計にする、といった運用が必要です。
アドオンを無効化する前にSecretProviderClassを確認する
既存クラスタで Azure Key Vault Provider for Secrets Store CSI Driver アドオンを無効化する場合は、SecretProviderClass が使用中でないことを確認する必要があります。公式ドキュメントでは、SecretProviderClass が存在する状態でアドオンを無効化しようとするとエラーになり、アドオン無効化後に Pod が再起動または新規作成されると、Driver が動作していないため Pod が起動に失敗すると説明されています。(Microsoft Learn)
削除や移行の順序は、次のように分けて考えると安全です。
| フェーズ | 実施内容 |
|---|---|
| 事前確認 | SecretProviderClass、CSI ボリュームを使う Deployment、Pod を洗い出す |
| 代替手段 | Workload ID、別 Key Vault、Kubernetes Secret など移行先を準備する |
| 段階移行 | namespace またはアプリ単位でマウント方式を切り替える |
| 動作確認 | Pod 再起動、スケールアウト、ノード再作成時の挙動を確認する |
| 無効化 | 使用中リソースがない状態でアドオンを無効化する |
開発者がリリース前に確認すべきこと
アプリケーション開発者は、Key Vault の権限そのものよりも、Pod から見たマウント結果とアプリの読み込み方式を確認する必要があります。
まず、Pod 起動後にマウント先を確認します。
kubectl exec <pod-name> -- ls /mnt/secrets-store/テスト環境では、取得できる値を一時的に確認できます。
kubectl exec <pod-name> -- cat /mnt/secrets-store/ExampleSecretただし、本番環境でシークレット値を標準出力に表示する運用は避けるべきです。CI/CD のログ、kubectl の履歴、監査ログに機密情報が残る可能性があります。検証では、値そのものではなく「ファイルが存在するか」「アプリが起動できるか」「接続先サービスに認証できるか」を確認するのが安全です。
また、Secrets Store CSI Driver はマウントされた内容や同期された Kubernetes Secret の自動ローテーションをサポートしますが、ConfigMap や Secret を subPath としてマウントしているコンテナは、Kubernetes の制限によりローテーション後の自動更新を受け取れません。変更を反映するには、ファイル変更を監視して再読み込みするか、Pod を再起動する設計が必要です。(Microsoft Learn)
本番展開前のチェックリスト
リリース前は、次のチェックリストを使って確認すると抜け漏れを減らせます。
| チェック | 確認内容 |
|---|---|
| 認証方式 | Service Connector、Workload ID、ユーザー割り当てマネージド ID のどれを使うか決まっている |
| AKS | CSI Driver アドオンが有効で、Provider Pod が正常に起動している |
| Microsoft Entra | Workload ID の場合、OIDC issuer とフェデレーション資格情報が正しい |
| Key Vault | Azure RBAC またはアクセスポリシーのどちらを使うか整理されている |
| ロール | secret、key、cert に応じたロールが対象 ID に付与されている |
| YAML | SecretProviderClass の clientID、tenantId、objectName、objectType が正しい |
| namespace | serviceAccount、Pod、SecretProviderClass が同じ想定 namespace にある |
| ネットワーク | Private Endpoint、Firewall、FQDN、必要ポートを確認している |
| ローテーション | アプリがシークレット変更を再読み込みできる設計になっている |
| IaC | Terraform や Bicep の差分が本番リソースに不要な変更を加えない |
次に取るべき行動
今回の Microsoft Entra と AKS の Key Vault 連携で最初にやるべきことは、既存クラスタの認証方式を棚卸しすることです。SecretProviderClass を一覧化し、どの namespace のどの Pod が、どの Key Vault オブジェクトを、どの ID で読んでいるかを確認してください。
新規構築なら、アプリ単位の最小権限を重視して Microsoft Entra Workload ID を第一候補にします。既存環境の簡易な接続や検証では Service Connector やユーザー割り当てマネージド ID も選択肢になりますが、本番運用では RBAC、OIDC、ネットワーク、ローテーション、IaC の差分まで含めて設計する必要があります。
特に 2026年5月6日前後の更新を踏まえると、Azure CLI 手順だけでなく Terraform を使った作成・更新フローも確認すべきです。AKS、Key Vault、Microsoft Entra の設定は別々に見えるものの、実際には SecretProviderClass を中心に密接につながっています。まずは検証環境で Workload ID またはマネージド ID のどちらか一方を選び、Key Vault の secret を1つだけマウントして、Pod 再起動・ロール変更・シークレット更新時の挙動を確認するところから始めるのが安全です。
コメント