Vault Azure シークレットエンジンで発行する使い捨て Service Principal 実務

Azure の権限を必要とするワークロードに、長期保存のクライアントシークレットを配布する運用はリスクが高い。Vault の Azure シークレットエンジンを使えば、必要な時だけ短命の Service Principal を発行し、TTL 経過やリース取り消しで自動失効させられる。

この記事では、最小権限での権限設計、セットアップから発行・失効、運用の落とし穴までを一気通貫で解説する。Associate / Ops レベルの資格対策ポイントも併記した。

Azure シークレットエンジンの役割と選定ポイント

Vault Azure シークレットエンジンは、Azure AD にアプリ登録と対応する Service Principal を作成し、指定スコープに Azure RBAC を付与したうえでクライアントID・シークレットを払い出す。払い出された認証情報にはリースが付与され、TTL 経過や明示的な取り消しで自動的に無効化される。

運用上の主な利点は、短命クレデンシャルによる露出時間の最小化、RBAC の自動付与・自動剥奪、Vault 監査ログによるトレーサビリティだ。Key Vault のような保管型ではなく、発行とライフサイクル管理に強い点が特徴となる。

• 主要パス: azure/config, azure/roles/<name>, azure/creds/<name>
• ロールで role_name と scope を定義し、RBAC 付与を自動化
• リース/TTL により自動失効。vault lease revoke で即時失効も可能
• 監査: Vault audit デバイスに各払い出しが記録される

前提条件と最小権限の整理

Vault が Azure 側でアプリ登録/Service Principal 作成やロール割当を行うため、構成用の Azure アプリ（Vault 側から利用するクレデンシャル）にはディレクトリとRBAC双方の権限が必要となる。加えて、Vault から Microsoft Graph と Azure Resource Manager へ到達できるネットワーク環境を用意する。

実務では、作成と割当の権限を最小化し、スコープを限定することが肝要。試験でも、どの権限がどの操作に必要かが頻出で問われる。

• アプリ/Service Principal 作成: Azure AD 側の権限（例: Application Administrator など）
• ロール割当: 割当対象スコープで Owner または User Access Administrator
• 必要エンドポイント到達性: login.microsoftonline.com、Microsoft Graph、管理API
• Vault 側: 適切な認証方式（AppRole, OIDC/JWT など）とポリシーでパスを制御

セットアップ手順: 有効化と config 登録

最初にシークレットエンジンを有効化し、tenant_id と構成用の client_id/client_secret を保存する。環境（AzurePublicCloud 等）を明示することでエンドポイントが適切に選択される。続いて、TTL ポリシーを調整する。

ロール定義と発行は次のセクションで扱う。ここでは最短経路で動作確認できる CLI/HTTP API と、運用自動化のための Terraform 定義例を示す。

• 有効化: vault secrets enable azure
• 構成: vault write azure/config tenant_id, client_id, client_secret, environment
• TTL 設定: azure/config/lease でデフォルト TTL/Max TTL を調整可能

CLI/HTTP と Terraform による初期設定と疎通確認

#!/usr/bin/env bash
set -euo pipefail

# 1) 有効化と Azure クレデンシャル設定
vault secrets enable azure || true
vault write azure/config \
  tenant_id="$AZURE_TENANT_ID" \
  client_id="$AZURE_CLIENT_ID" \
  client_secret="$AZURE_CLIENT_SECRET" \
  environment="AzurePublicCloud"

# （任意）デフォルトのリース設定
vault write azure/config/lease ttl=1h max_ttl=24h

# 2) ロール定義（resource group 範囲に Contributor を付与する例）
cat > role-dev.json <<'JSON'
{
  "azure_roles": [
    {
      "role_name": "Contributor",
      "scope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/app-rg"
    }
  ],
  "ttl": "1h",
  "max_ttl": "24h"
}
JSON

curl \
  --silent \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data @role-dev.json \
  "$VAULT_ADDR/v1/azure/roles/dev" | jq '.'

# 3) 認証情報の発行（出力に client_id, client_secret, tenant_id, lease_id など）
vault read -format=json azure/creds/dev | jq '.'

# 4) 取り消し（即時失効）
# vault lease revoke <lease_id>

# ------------------------------
# Terraform 例（抜粋）
# ------------------------------
# provider "vault" {}
# resource "vault_azure_secret_backend" "az" {
#   path          = "azure"
#   tenant_id     = var.tenant_id
#   client_id     = var.client_id
#   client_secret = var.client_secret
#   environment   = "AzurePublicCloud"
# }
# resource "vault_azure_secret_backend_role" "dev" {
#   backend  = vault_azure_secret_backend.az.path
#   role     = "dev"
#   ttl      = "1h"
#   max_ttl  = "24h"
#   azure_roles = [{
#     role_name = "Contributor"
#     scope     = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/app-rg"
#   }]
# }

ロール設計と発行フロー

ロールは、払い出される Service Principal に対してどのスコープにどの Azure RBAC を付与するか、さらに TTL/Max TTL を定義する。スコープはサブスクリプション、リソースグループ、特定リソース単位まで絞り込める。1ロールに複数の role_name/scope を含めることも可能だが、最小権限の原則に従い、環境・用途ごとにロールを分けると運用が安定する。

発行時は azure/creds/<role> を read するだけで、Vault が Azure AD にアプリ登録と Service Principal を作成し、定義済みスコープにロール割当を行う。応答には client_id、client_secret、tenant_id とリース情報が含まれ、TTL を超えると自動失効する。明示的に失効させたい場合は lease_id を指定して取り消しを行う。

• スコープ例: /subscriptions/<subId>/resourceGroups/<rg> または特定リソースの ID
• TTL は短めに設定し、ジョブ実行時間に合わせて renewal を許可
• azure/creds/<role> は read 操作。試験では write と取り違えに注意

Vault による Service Principal 発行フロー

運用: TTL/更新、取り消し、監査とSRE視点の落とし穴

TTL はロール単位やデフォルトの lease 設定で管理する。長時間ジョブの場合はクライアント側からリース更新を行う設計にする。失敗時は取り消しで直ちに失効させ、再発行する。監査は Vault 側の audit デバイスを必ず有効化し、払い出しと失効の責任追跡を担保する。

実運用での落とし穴としては、ロール割当のスコープ過大、Graph API のレート制限、権限不足による作成失敗がある。CI からの利用時は Vault への認証（AppRole/OIDC）とロールの対応関係を明確化し、誤用を防ぐ。

• リース更新の実装方針をジョブ制御と合わせて決める
• スコープは最小化し、環境ごとにロール分割
• 監査ログに基づく定期的な棚卸しとメトリクス化
• レート制限対策としてバッチ実行のスロットリングを考慮

トラブルシューティングと試験対策の要点

作成や割当が失敗する典型原因は権限不足だ。アプリ登録・SP 作成はディレクトリ権限、ロール割当は対象スコープの Owner か User Access Administrator が必要となる。メッセージで Insufficient privileges が出たらまず権限とスコープを確認する。

試験では、エンジンの主要パス、ロールとスコープの関係、リースの概念が頻出。azure/creds/<role> は read 操作である点、取り消しは lease revoke である点を押さえておきたい。

• Insufficient privileges: ディレクトリ権限とスコープ権限の両面を点検
• 429 Too Many Requests: 実行間隔にジッタを入れて再試行
• scope の書式誤り: 完全リソースIDを用いる
• 試験キーワード: azure/config, azure/roles/<name>, azure/creds/<name>, TTL/lease, 最小権限

問題で確認

よくある質問