Vault Tokens の基礎: 認証の起点となる概念

Vault で実際にリクエストを許可するのは「トークン」です。どの認証方式（OIDC/Kubernetes/AppRole など）でログインしても、最終的にクライアントが手にするのは Vault が発行したトークンであり、これが権限の実体になります。

本稿では、安定機能を軸にトークンの基本、タイプ/属性の違い、更新と失効、ポリシーとの関係、よくある設計パターンを整理します。Associate レベルの試験で頻出のポイントも明示します。

トークンはなぜ“認証の起点”なのか

Vault では、認証バックエンド（例: userpass, OIDC, Kubernetes, AppRole）は“ログイン手段”であり、最終的にはクライアントにトークンを発行します。このトークンにポリシーと有効期限が結び付けられ、以降のすべてのリクエストはこのトークンで評価されます。

つまり、認証の成否だけでなく、アクセス制御（どのパスに何ができるか）や有効期限、取り消しの影響範囲もトークンが担います。試験では「どの方式でログインしても最終的にトークンが権限を表現する」という前提を問われやすい点に注意してください。

• トークンはポリシーの束を運ぶコンテナ（capabilities の実体）
• TTL/最大TTL/更新可否はトークン側で管理
• 親子関係があり、親の失効は子に伝播（オーファンは例外）
• サービス運用では短寿命・自動更新が基本設計
• 人間利用はSSO(OIDC)などでログイン → 最終的にトークン取得

認証からトークン発行、リクエスト評価までの流れ

ライフサイクル: 発行・更新・失効・親子関係

トークンは発行時に TTL（有効期限）が設定され、更新可能かどうか、最大TTLがあるか、使用回数制限（use-limit）があるか等が決まります。通常のサービス・トークンはストレートなTTL消費型で、更新APIで延長できます（上限は最大TTL）。

親子関係は失効の伝播に関係します。親トークンを取り消すと、その親から作った子トークン（さらに孫…）が一括で失効します。-orphan で作られたオーファン・トークンは親を持たないため、親の失効の影響を受けません。Periodic トークンは設定した period ごとに更新を要求され、最大TTLの制限を受けずに運用できる一方、更新を止めると期限で失効します。

• 更新可能: renewable フラグが true のサービス・トークン
• 最大TTL: 通常のサービス・トークンは max_ttl を超えて更新不可
• Periodic: period で更新必須、最大TTLなし（明示的な失効が必要）
• Use-limit: 規定回数の API 呼び出しで自動失効
• 親子関係: revoke 親 → 子孫まで伝播、ただしオーファンは対象外

タイプ/属性の比較（サービス/バッチ、オーファン、Periodic）

Vault のトークンは主にサービス・トークンとバッチ・トークンに大別され、加えてオーファン（親なし）や Periodic（更新必須）といった属性を付与できます。タイプは機能面、属性は挙動面に効くと捉えると混乱しにくくなります。

バッチ・トークンは高スループット用途向けに軽量化されており、更新不可・子トークン不可・アクセサなし等の制約があります。サービス・トークンは運用機能（更新/取り消し/アクセサ/子作成）が揃っており、一般的な常駐サービスに向きます。

• サービス: ストレージに状態を持ち、Lookup/Accessor/Renew/Revoke が豊富
• バッチ: 非永続・軽量・更新不可、TTL満了での自然失効を前提に
• オーファン属性: 親の失効が伝播しない独立トークン
• Periodic属性: 最大TTLの代わりに period による定期更新を要求
• default ポリシーは既定で付与（除外するオプションあり）

ポリシーと Capabilities: 何ができるかを決める軸

トークンは1つ以上のポリシーを保持し、各ポリシーがパス単位で read/create/update/delete/list/sudo 等の capabilities を定義します。Vault は各リクエストの対象パスをポリシーに照らして可否を判定します。

デフォルトでは default ポリシーが付与されますが、トークン作成時に除外もできます。試験では「ポリシーは許可の集合であり、最小権限で設計する」「capabilities の自己点検が可能」の2点が頻出です。

• ポリシーは HCL または JSON で定義
• capabilities の確認: token capabilities コマンド
• 最小権限: 書き込み不要なら read/list のみに限定
• 名前空間やマウントパスのタイポは典型的な失敗原因
• default の自動付与は不要なら明示的に外す

設計パターンと運用の押さえどころ

サービス向けには短寿命トークン＋自動更新が基本です。Periodic を選ぶと最大TTLに縛られず、更新のヘルスチェックで監視もしやすくなります。更新失敗時に安全に停止するパターンを組み込みましょう。

高スループットのリードオンリー・プロキシや短時間のバッチ処理ではバッチ・トークンが有効です。更新不可を前提に TTL を厳格に短くし、必要に応じて新規発行でローテーションします。

• 人間系は OIDC/SAML でSSO → セッション短期化＋MFA
• Kubernetes は ServiceAccount をロールに結び付け、短TTLに
• アクセサでの取り消し運用（トークン本体をログに残さない）
• use-limit で万一の漏えい時の被害範囲を限定
• 監査ログでの TokenAccessor 追跡を定例化

CLI 実例と落とし穴

以下は典型的な操作例です。試験ではオプションの意味（-policy, -ttl, -period, -use-limit, -orphan, -type=batch）を押さえ、更新/失効/Lookup/Accessor の関係を整理しておくと得点源になります。

バッチ・トークンは更新不可・アクセサなし・Lookupに制限がある点に注意。Periodic は period ごとに必ず更新が必要で、更新停止で期日失効します。

• 既定で default ポリシーが付く。不要なら -no-default-policy
• アクセサを使うとトークン本体を扱わずに失効できる
• renew は更新可能なサービス・トークンにのみ有効
• revoke は親に行うと子孫まで一括で失効（オーファン除く）

よく使う vault トークン操作

# ログイン（例: userpass/OIDC など）
$ vault login

# サービス・トークンを発行（30分TTL、100回まで、オーファン、ポリシーapp付与）
$ vault token create -policy=app -ttl=30m -use-limit=100 -orphan

# Periodic トークン（24時間 period、更新必須）
$ vault token create -policy=svc -period=24h

# バッチ・トークン（更新不可・軽量）
$ vault token create -type=batch -policy=read-only -ttl=5m

# トークンの能力確認（自分自身のcapabilitiesを確認）
$ vault token capabilities secret/data/*

# Lookup（サービス・トークン向け）
$ vault token lookup s.Ku1...

# アクセサ取得（ログに残すのはアクセサ推奨）
$ vault token lookup -format=json s.Ku1... | jq -r .data.accessor

# アクセサで取り消し（トークン文字列を扱わない）
$ vault token revoke -accessor A1bC2...

# 更新（更新可能なサービス・トークンのみ）
$ vault token renew s.Ku1...

# 親トークンの取り消しは子孫まで伝播
$ vault token revoke s.Parent...

問題で確認

よくある質問