Vault Auth Methods の概要：選び方と運用の実務チェックリスト

Vault の Auth Methods は、外部の身元情報を Vault トークンに変換する玄関口です。選定を誤ると初期ブートストラップやローテーションで詰まりやすく、逆に適切に設計すれば運用コストとリスクを大きく抑えられます。

本稿は、代表的なメソッドの比較、選択フレームワーク、TTL/period の使い分け、ロール設計・監査までを一気に俯瞰します。Associate 対策として問われやすいポイントも明示します。

Auth Methods の全体像（試験でまず押さえる前提）

Auth Method は「認証」。Secret Engine は「秘密の発行/保管」。役割が違います。Auth Method は外部の認証情報（例：Kubernetes の ServiceAccount JWT、IAM 証明、LDAP 資格情報、AppRole の role_id/secret_id など）を受け取り、検証・クレーム評価・ポリシー付与を行い、Vault トークンを発行します。

発行されたトークンはポリシーと TTL（または period）を持ち、Secret Engine へのアクセスに使われます。複数の Auth Method を並行して使っても、Vault の Identity（Entity/Group）で同一人物・同一ワークロードに統合できます。

• Auth Method は mount/path ごとに有効化する（例: auth/kubernetes, auth/approle）。
• ロール（methodごとの role）でポリシー、TTL、バインド条件（CIDR、クレーム、SA名など）を定義。
• トークンは renew・revoke が可能。periodic トークンは更新し続ける限り有効。
• 試験で頻出：Auth と Secret Engine の違い、TTL と period の違い、ロールでの制約設定。

Vault 認証の標準フロー

選び方のフレームワーク（人/機械、境界、ブートストラップ）

Auth Method 選定は「誰がどこから入るか」「初期資格情報をどう安全に渡すか」「更新と失効をどう回すか」で決めます。技術的に可能でも、運用できなければ破綻します。

以下の観点で候補をスクリーニングし、残った 1〜2案を PoC で検証するのが現実的です。

• 主体の種類: ヒトは OIDC（IdP連携）優先。マシンは Kubernetes、AppRole、クラウド（AWS/GCP/Azure）優先。
• 初期ブートストラップ: SA JWT（Kubernetes）、インスタンスメタデータ/IAM（クラウド）、配布管理が必要な secret_id（AppRole）。
• 境界・到達性: Vault へ直接到達できるか。クラウドメタデータや TokenReview に外向き通信が要るか。
• ローテーション設計: periodic で継続更新するか、短 TTL＋再ログインで回すか。
• 制約と証跡: CIDR、クレーム、SA/Namespace バインド、監査ログの充足度。
• Blast radius: 認証情報が漏れたら被害範囲はどこまでか。使い捨て/回数制限で絞れるか。

代表的 Auth Method の比較（用途別の当てどころ）

主要メソッドを、主対象・ブートストラップ・ローテーション・外部依存・典型ユースケースで比較します。現場では Kubernetes/OIDC/AppRole/クラウドの 4 本柱でほぼカバーできます。

• ヒト=OIDC、機械=Kubernetes/AppRole/クラウドIAM が基本線。
• レガシー互換や一時用途として userpass/LDAP/GitHub を補助的に使うケースはあるが、長期運用は避けたい。

運用設計の要点（TTL/period、バインド条件、監査）

TTL と period は混同されやすい要点です。TTL は最大寿命（max_ttl を超えない）まで更新可能。periodic トークンは期限がなく、指定 period ごとに更新し続ける限り有効（ただし明示的に revoke されれば失効）。どちらを選ぶかは、プロセスの稼働形態と再ログイン容易性で決めます。

ロール設計では、付与ポリシーの最小化に加え、Kubernetes は ServiceAccount/Namespace バインド、AppRole は secret_id の回数・TTL・CIDR 制限、クラウド系はロール/SA/タグ等での厳格なマッチングを設定します。監査ログは少なくとも auth/* の login パスに対して有効化し、誰がどこからどのロールでトークンを得たかを追跡可能にします。

• periodic トークンは token_period をロールに設定。token_ttl と同時設定は不可。
• Kubernetes: token_reviewer_jwt と kubernetes_host/ca を正しく設定し、Role ごとに SA/Namespace を最小権限でバインド。
• AppRole: secret_id_num_uses, secret_id_ttl, secret_id_bound_cidrs を活用。role_id は漏れても致命傷ではないが、secret_id は厳重管理。
• 監査: 必要なら CIDR 制限や User-Agent 制御、アクセス元 IP を含めた監査基盤と連携。
• ローテーション: デプロイパイプラインに login→トークン発行→短TTLで利用→失効（または periodic の更新処理）を組み込む。

AppRole と Kubernetes Auth の最小構成例（CLI）

# 1) ポリシー（例）
vault policy write app - <<'EOF'
path "secret/data/app/*" {
  capabilities = ["read"]
}
EOF

# 2) AppRole を有効化してロール作成
vault auth enable approle
vault write auth/approle/role/app \
  token_policies="app" \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_ttl=24h \
  secret_id_num_uses=10 \
  secret_id_bound_cidrs="10.0.0.0/24"
# ログイン用のID取得
ROLE_ID=$(vault read -field=role_id auth/approle/role/app/role-id)
SECRET_ID=$(vault write -f -field=secret_id auth/approle/role/app/secret-id)
# ログイン
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"

# 3) Kubernetes Auth を有効化して Role 作成
vault auth enable kubernetes
vault write auth/kubernetes/config \
  token_reviewer_jwt="$($(command -v cat) /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  kubernetes_host="https://${KUBERNETES_PORT_443_TCP_ADDR}:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
vault write auth/kubernetes/role/demo \
  bound_service_account_names="vault-demo" \
  bound_service_account_namespaces="default" \
  policies="app" \
  ttl=1h

よくある落とし穴と Associate 試験での観点

試験では「この要件ならどの Auth Method が妥当か」「TTL/period の設定はどれか」といった設問が中心です。運用では誤設定や過大権限が事故の典型原因です。

• AppRole の secret_id を無制限にする → 使い回しリスク増大。回数・TTL・CIDR を設定する。
• Kubernetes の Role を Namespace ワイルドカードで緩く縛る → テナント越境の危険。SA と Namespace は厳密に。
• 人に Token を直配布 → 失効が遅れる。OIDC で IdP 連携し、グループベースでポリシー管理。
• periodic と TTL を混同 → 更新不能や無期限化の誤設定に注意。token_period は単独で使う。
• 監査無効や不足 → login パスを含め必ず有効化。

移行とフェデレーション（段階的置き換えの勘所）

レガシー環境からの移行は、ヒトは OIDC、機械は K8s/クラウドIAM/AppRole へ段階的に寄せるのが現実解です。既存の userpass/LDAP/GitHub は当面併用しても、ポリシーと TTL を厳しめにし、監査を厚くしてリスクを抑えます。

マルチクラウド/ハイブリッドでは、クラウドネイティブの Auth Method を各環境で使い分け、Vault 側の Identity で同一 Entity に束ね、グループでポリシー配布を共通化すると運用が安定します。

• 人: userpass/GitHub → OIDC（グループ連携）へ移行、並行期間は短 TTL。
• K8s: Sidecar/Init で login を自動化、SA/Namespace バインドを IaC 化。
• VM/バッチ: 可能ならクラウド Auth、難しければ AppRole＋secret_id ローテーションを自動化。
• 共通: トークン利用は短 TTL か periodic＋定期更新、revoke を運用手順に組み込む。

問題で確認

よくある質問