Vault のコア概念を一気に整理：Secret / Auth / Policy / Token

Vault を業務に入れるときに最初に迷いやすいのが、Secret・Auth・Policy・Token の境界です。用語を正確に分けて理解すると、設計の選択肢や試験対策が一気に楽になります。

この記事は Vault Associate レベルで問われやすい安定概念に絞り、CLI 例と注意点を交えつつ、実運用でもそのまま使える形でまとめます。

全体像と用語の地図：4本柱の関係を先に掴む

Vault は「どの入口から入るか(Auth)」「入った人に何を許すか(Policy)」「実体の秘密はどこにあるか(Secret)」「入場券そのもの(Token)」という4要素で整理すると迷いません。Auth は認証の入口、Policy は入口を通った主体の行動許可、Secret は保護対象のデータや機能、Token はセッションと権限を持つクレデンシャルです。

設計の原則はシンプルです。Auth は Token を発行するだけで Secret には触れません。Secret は Lease と共に発行・破棄され、Policy は常にパス単位で許可/拒否を定義します。Token は Policy を担保に Secret にアクセスし、TTL/更新/失効が管理されます。

• Auth は「誰か」を証明し Token を発行する。Secret は「何か」を保護・発行する。
• Policy は常にパスベースの ACL。deny が最優先、allow は積み上げ、root は全許可。
• Token は認証の結果であり、権限は Token に付与された Policy に依存する。
• Lease は Token と動的シークレットの時間的ライフサイクルを管理する枠組み。

Secret/Auth/Policy/Token の関係図

最初に眺めるコマンド（状態・有効化済みエンドポイント）

export VAULT_ADDR=http://127.0.0.1:8200
# sealed/unsealed, HA 状態など
vault status
# シークレットエンジン一覧（/ 下にどれがマウントされているか）
vault secrets list
# 認証メソッド一覧（/auth 下）
vault auth list

Secret と Lease：静的 vs 動的、TTL/更新/失効の実務

Secret は「静的」と「動的」に大別されます。kv v2 のような静的シークレットは更新まで内容が固定で Lease を伴いません。一方、database や aws などの動的シークレットは、要求のたびに一時的な資格情報を発行し、Lease（TTL、更新可否、最大 TTL）で寿命を管理します。

重要なのは、Lease はトークンだけでなく動的シークレット自体にも付く点です。renewable なら期限前に renew、不要になったら revoke、インシデント時は prefix 単位でまとめて revoke して被害を素早く収束できます。

• 静的シークレット: バージョン管理（kv v2）、ポリシーで読み取り面を最小化。
• 動的シークレット: 最小権限かつ短命。期限切れで自動失効、侵害面積を小さく。
• lease revoke -prefix は緊急遮断の即効薬。DB ローテーション戦略と合わせる。

静的と動的の基本操作（概念把握用）

# 静的: kv v2 にアプリ設定を書き込む
vault secrets enable -path=secret kv-v2
vault kv put secret/app/config username=svc-user password=s3cr3t
vault kv get secret/app/config

# 動的: database でロールから一時資格情報を取得（実環境では接続先の設定が必要）
# ロール作成例（概念）
# vault write database/roles/app-role db_name=mydb [email protected] default_ttl=1h max_ttl=24h
# 一時資格情報の払い出し（Lease 付き）
vault read database/creds/app-role
# Lease の確認・更新・失効
vault lease lookup <lease_id>
vault lease renew <lease_id>
vault lease revoke <lease_id>
# 影響範囲を一括遮断（プラグイン別やパス単位など）
vault lease revoke -prefix database/creds/

Auth（認証）とトークン発行の流れ：AppRole/Kubernetes/OIDC の要点

Auth メソッドは入口です。認証が成功すると Vault は Token を発行します。Auth は Secret に直接アクセスしません。代表例は userpass（検証/学習用途）、AppRole（サーバ・ジョブ向け）、Kubernetes（ServiceAccount JWT と連携）、JWT/OIDC（IdP 連携）です。

各 Auth は「ロール」や「マッピング」を通じて発行 Token に付与するポリシー、TTL、制約を定義します。設計では「どのワークロードがどのロールで入り、どのポリシーを付与するか」を先に決めると、境界が明確になります。

• Auth は /auth/* にマウント。無効化すれば以降のログインは不可。
• 発行された Token の権限はロールで付与した Policy に完全依存。
• Kubernetes 連携は SA JWT を検証。OIDC は IdP 側クレームを Vault のロールにマッピング。

AppRole でのログインから Token 取得（最小構成）

# AppRole を有効化
vault auth enable approle
# ロール作成（発行 Token に app-read ポリシーを付与、TTL は 1h）
vault write auth/approle/role/myapp token_policies="app-read" token_ttl=1h token_max_ttl=24h
# ロールID と SecretID を取得
ROLE_ID=$(vault read -field=role_id auth/approle/role/myapp/role-id)
SECRET_ID=$(vault write -field=secret_id -f auth/approle/role/myapp/secret-id)
# 認証して Token を得る
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"
# 出力 JSON の auth.client_token が以降の API/CLI に利用する Token

Policy（ACL）の基礎：パスベース、capabilities、優先順位

Policy はパスに対する操作権限の集合です。capabilities は主に create, read, update, delete, list, sudo。deny は最優先で、allow を上書きします。root は全許可で、本番では使用を避けます。

設計のコツは「Secret の論理境界＝パス構造」に落とし、アプリ単位ロールと読み取り専用/書き込み境界を分離すること。Enterprise の Namespaces は別機能（Associate では前提外にしても可）なので混同しないようにします。

• default ポリシーは全 Token に付与（sys/capabilities の一部に必要最低限）。
• パスのワイルドカードは意図を明確に。list は read とは別権限。
• sudo は限定的に使用（例: auth/* 管理や一部 sys/* 操作）。

最小ポリシー例（HCL）と適用

# app-read.hcl
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}
# ロール/ユーザーに付与する管理用の最小限
path "sys/leases/*" {
  capabilities = ["read", "list"]
}

# ポリシーを登録
vault policy write app-read app-read.hcl
# Token の権限を検証
vault token capabilities -policy=app-read secret/data/app/config

Token の種類とライフサイクル：service/batch/periodic、orphan、ラッピング

Token は権限と TTL を持つクレデンシャルです。service は標準の永続型で更新/失効/親子関係あり。batch は軽量・非永続・非更新（高スループット用途）。periodic は最大 TTL を持たず、定期的な更新が必須です。必要に応じて orphan（親なし）で作れば親失効のカスケードを避けられます。

レスポンスラッピングは、API 応答を一度きりの wrapping token で包む仕組みです。unwrap するまで中身は cubbyhole（Token 固有の一時領域）に保存され、横取りリスクの軽減に役立ちます。

• token renew は renewable かつ上限内でのみ成功。periodic は renew 前提で運用する。
• 親 Token の revoke は子 Token を連鎖的に revoke。orphan は連鎖しない。
• wrapping token は一度きり、短 TTL。unwrap 後は無効化。

Token 作成・更新・失効とレスポンスラッピング

# 標準の service トークン
vault token create -policy=app-read -ttl=1h
# batch（非永続・非更新）
vault token create -type=batch -policy=app-read -ttl=15m
# periodic（上限なし、更新必須）
vault token create -policy=app-read -period=24h
# orphan（親なしで連鎖失効を避ける）
vault token create -policy=app-read -orphan -ttl=1h

# 更新・失効
vault token renew <token>
vault token lookup <token>
vault token revoke -accessor <accessor>

# レスポンスラッピング（例: 動的資格情報を 60s で包む）
vault write -wrap-ttl=60s database/creds/app-role
# 別ホップで unwrap（1回限り）
vault unwrap <wrapping_token>

Associate 試験向け要点と実務チェックリスト

試験では、Auth と Secret の責務分離、Policy の優先順位、Token/Lease の更新と失効、動的シークレットの利点、ラッピング/キュビーホールの用途が頻出です。実務では、緊急時の revoke 手順と、誰がどのロールで入るかを明文化するのが肝です。

現場チェックとして、Auth ロール→ポリシー→パスの対応表を作り、最小権限で通ることを capabilities で検証し、Lease の prefix revoke で遮断できることを演習しておきましょう。

• 区別: Auth=入口/Token発行、Secret=保護対象、Policy=権限、Token=持ち物。
• 優先: deny が最優先、root は本番禁止、default は常時付与に注意。
• TTL: Token と Secret の Lease は別管理。renew は上限内のみ成功。
• 動的シークレット: 期限自動失効と短命性でリスク低減。
• ラッピング: 一度きりの安全受け渡し。cubbyhole を理解する。

確認に使えるワンライナー集

# このトークンでどこまで許可されているか（ポリシーデバッグ）
vault token capabilities -token=$VAULT_TOKEN secret/data/app/*
# パスのヘルプ（利用可能操作の確認）
vault path-help database/creds
# 失効の安全弁（プレフィックス単位）
vault lease revoke -prefix database/creds/
# アクセサでの失効（ログに残したアクセサから）
vault token revoke -accessor <accessor>

問題で確認

よくある質問