Azure 認証: Managed Identity 連携で Vault を安全に使う（Associate 向け）

Azure の Managed Identity を使えば、アプリや VM がシークレットを保持せずに Vault へ認証できます。漏洩リスクを下げつつ、運用の手間も小さくできます。

本稿は Vault Associate レベルで押さえるべき公式ドキュメント準拠の概念と、現場でそのまま使える最短構成手順を整理します。

なぜ Managed Identity で Vault に認証するのか

Managed Identity（MI）は Azure AD によって自動管理される ID で、資格情報の作成・保存・ローテーションが不要です。Vault の Azure 認証メソッドと組み合わせると、ワークロードは Azure AD から取得したアクセストークンを使って Vault にログインできます。

試験観点では「認証（Auth Method）と認可（Policy）の分離」「ロールでのバインド条件（どの MI/どのリソースから来たリクエストか）」「トークン TTL/Max TTL/再認証」の基礎が頻出です。

• 対象ワークロード: VM/VMSS、App Service、Functions、AKS ノードや Pod（Workload Identity 経由）
• 利点: シークレットレス、ローテーション不要、スケールしやすい RBAC 設計
• Vault 側: Azure Auth Method によるトークン検証 + Policy での最小権限付与

アーキテクチャとフロー

Vault の Azure Auth Method は、Azure AD が署名したアクセストークン（MI または Service Principal で取得）を受け取り、署名検証とクレーム検査を行います。ロールに設定したバインド条件（例: サブスクリプション ID、リソースグループ、VM/VMSS 名など）に合致すれば、Vault はポリシー付きのクライアントトークンを発行します。

ポイントは Audience（resource）の一致、トークン有効期限内であること、そしてロール側の制約条件に合致していることです。

• Azure IMDS から MI のトークンを取得（resource は通常 https://management.azure.com/）
• Vault は Azure AD の公開鍵で署名検証し、クレーム（xms_mirid 等）からリソース属性を突き合わせる
• 認可は Vault Policy で制御（パス単位の最小権限）

Managed Identity を用いた Vault 認証フロー

Vault 側の設定手順（Azure Auth Method + Policy）

まず Azure 認証メソッドを有効化し、テナント情報やリソース（audience）を設定します。次に、どの Azure リソースからのトークンを許可するかをロールで定義し、最後にアクセス権限を与える Vault ポリシーを関連付けます。

以下は最小構成の例です。環境や要件（サブスクリプション/リソースグループ/VM 名などの制約）は実際のリソース ID に置き換えてください。

• auth/azure/config: tenant_id と resource（通常 https://management.azure.com/）を設定
• auth/azure/role/<name>: サブスクリプション/リソースグループ/VM/VMSS などのバインド条件と token_policies を設定
• ポリシー: 最小権限のパス許可（read/list/write を必要最小限）

Vault 設定例（CLI と HTTP API）

# 1) Azure 認証メソッドの有効化
vault auth enable azure

# 2) テナントと audience(resource) の設定
vault write auth/azure/config \
  tenant_id="00000000-0000-0000-0000-000000000000" \
  resource="https://management.azure.com/"

# 3) ロール定義（例）
#   - 実運用では、サブスクリプション/リソースグループ/VM(SS)名などで厳格に縛る
#   - token_policies で付与するポリシーを指定
vault write auth/azure/role/app-role \
  bound_subscription_ids="11111111-1111-1111-1111-111111111111" \
  bound_resource_groups="rg-app-prod" \
  # 必要に応じて VM/VMSS 名、スケールセット、SPN ID などの制約を追加 \
  token_policies="app-kv-read" \
  token_ttl=1h token_max_ttl=4h

# 4) 最小権限ポリシー例（読み取りのみ）
tee /tmp/app-kv-read.hcl <<'POLICY'
path "kv/data/app/*" {
  capabilities = ["read"]
}
POLICY
vault policy write app-kv-read /tmp/app-kv-read.hcl

# 参考: HTTP API でのログイン例（後述のワークロード側で実行）
# curl --request POST \
#   --data '{"role":"app-role","jwt":"<AAD_access_token>"}' \
#   http://<vault_addr>/v1/auth/azure/login

Azure/ワークロード側の設定（MI でトークン取得し Vault へログイン）

ワークロードは Azure IMDS を通じて Azure AD のアクセストークンを取得します。resource は Vault 側の auth/azure/config で指定した値（既定では https://management.azure.com/）と一致させます。一致しないと Audience mismatch で拒否されます。

System-assigned MI の場合はそのまま、User-assigned MI を使う場合は client_id を付与して IMDS から該当 MI のトークンを取得します。その後、取得した jwt を Vault の /auth/azure/login に渡して Vault トークンを受け取ります。受け取った Vault トークンで kv/ や他エンジンのシークレットを取得します。

• IMDS エンドポイント: http://169.254.169.254/metadata/identity/oauth2/token
• 必須ヘッダ: Metadata: true
• クエリ: api-version、resource（および必要に応じて client_id）
• Vault 側 audience(resource) と一致していることを確認

ロール設計とポリシー最小権限のコツ

ロールは「誰が Vault に来てよいか」の境界であり、ポリシーは「来た人に何を許すか」です。これを混同しない設計が安定運用の鍵です。

同じアプリでも環境（dev/stg/prd）ごとにロールとポリシーを分割し、攻撃面積と blast radius を小さくします。

• 1 ワークロード 1 ロールを原則にし、リソースグループや VM/VMSS 名で厳格にバインド
• ポリシーはパスの粒度を小さく（例: kv/data/app/prod/* の read のみ）
• TTL は短め、定期再認証を前提にする（token_ttl と token_max_ttl の差を理解）
• 監査ログ（audit device）を有効化し、role_name と path の突合で事後分析可能に

トラブルシューティングと試験に出やすい要点

Audience mismatch: IMDS から取得するトークンの resource と Vault の auth/azure/config の resource が一致していない。両方を https://management.azure.com/ に合わせるのが無難。

User-assigned MI: IMDS でトークンを取る際に client_id を指定しないと 403 になる。正しい MI の client_id を使う。

時計ずれ: AAD トークン検証は有効期限と発行時刻に厳密。NTP を整える。

• ログ確認: Vault サーバの監査ログと auth/azure のログレベルを上げる
• 最小再現: 単純な kv 読み取りに絞ったポリシーでまず疎通確認
• クラウド環境: Public/China/Gov などクラウドごとのエンドポイント差異に注意

問題で確認

よくある質問