Vault Orphan Token徹底整理: 親子関係のないトークンを安全に使いこなす

Vaultでは通常、トークンは親子ツリーに属し、親を失効すると子も連鎖的に失効します。しかしOrphan Tokenはこのツリーに属さず、親の失効に連鎖しません。

本稿では、Orphan Tokenの定義、Periodicトークンとの関係、検出と是正方法、設定の落とし穴までを、資格対策と運用の両面から解説します。

Orphan Tokenの定義とトークン階層の基礎

Vaultのトークンはデフォルトで親子関係を持ち、親トークンの失効が子トークンに連鎖します。これに対してOrphan Tokenは親を持たず、親の失効連鎖の対象外です。CLIではvault token create -orphan、APIでは/auth/token/create-orphanで作成します。

注意点として、Rootトークンはシステム起動直後に作られる特別なトークンで、広範な権限を持ちます。概念的には親を持たない点でOrphanに近いですが、用途・リスクは全く異なります。試験や実務では「Orphanは失効連鎖から独立する性質」「Rootは非常時・初期設定用の強力トークン」という観点を分けて覚えてください。

• Orphan Tokenは親の失効で影響を受けない（連鎖失効しない）
• 作成パスは/auth/token/create-orphan（CLIは -orphan）
• デフォルト作成の子トークンは親のrevokeで連鎖失効
• Rootは強力で特別。Orphanの一般論と混同しない

Vaultトークン階層とOrphanの位置づけ（概念図）

子トークンとOrphanトークンの作成と確認

## 子トークン（デフォルト: 親あり）
$ vault token create -policy=app -ttl=1h

## Orphanトークン（親なし）
$ vault token create -policy=app -ttl=1h -orphan

## トークン属性の確認（orphanフラグなど）
$ vault token lookup s.xxxxxx
Key                 Value
---                 -----
orphan              true
policies            ["app" "default"]
ttl                 1h

Orphan・子・Periodicの違い（試験で狙われやすいポイント）

Associateレベルでは、失効連鎖・更新（renew）・作成パスの違いが頻出です。特にPeriodicトークンは親子ツリーに属さず（実質的にOrphan特性を持つ）、親トークンのrevokeに連鎖しません。

作成時にどのAPIパス／CLIオプションを用いたか、どのTTL/periodを与えたかで挙動が変わります。下の比較で素早く見分けられるようにしましょう。

• 子トークン: デフォルト。親のrevokeで失効
• Orphan: 親なし。連鎖失効対象外。TTLや明示revokeで統制
• Periodic: periodで永続更新型。親のrevokeに非連鎖（実質Orphan的）

APIパスの差異（子/Orphan）とPeriodicロール例

# 子トークン（デフォルト）
curl -sS -H "X-Vault-Token: $PARENT" \
  -d '{"policies":["app"],"ttl":"1h"}' \
  $VAULT_ADDR/v1/auth/token/create

# Orphanトークン
curl -sS -H "X-Vault-Token: $PARENT" \
  -d '{"policies":["app"],"ttl":"1h"}' \
  $VAULT_ADDR/v1/auth/token/create-orphan

# Periodicトークンのためのロール
vault write auth/token/roles/ci \
  allowed_policies=build \
  period=24h

# ロールから発行（Periodic）
vault token create -role=ci

Orphanトークンの発生要因と検出方法

Orphanは明示的に-orphan（または/auth/token/create-orphan）を使った場合、またはPeriodicロールから発行した場合に生じます。既存の子トークンが途中でOrphanに“変化”することは基本的にありません。

検出はlookupが確実です。監査の観点ではアクセサで列挙→個別lookupが実務的です。Periodicはlookupでperiodが設定され、orphanもtrueで示されます（Vaultの出力項目名はバージョンで表記が変わる可能性があるため、実環境で確認してください）。

• 作成パスの違いがそのままOrphanの有無に直結
• lookupでorphanフラグ、（Periodicなら）periodを確認
• アクセサ経由で一括点検し、不要トークンを棚卸し

アクセサ列挙と属性確認（棚卸しの基本）

# アクセサの一覧
$ vault list auth/token/accessors
Keys
----
accessor-AAAA
accessor-BBBB

# アクセサでlookup（トークン本体を知らなくても確認可能）
$ vault token lookup -accessor accessor-AAAA
Key                 Value
---                 -----
orphan              true
period              24h
policies            ["app" "default"]

# 必要に応じてアクセサでrevoke（漏えいリスク低減）
$ vault token revoke -accessor accessor-AAAA

リスクと運用影響：連鎖失効しないことの代償

Orphan/Periodicは親に依存しない安定性をもたらす一方、親revokeで止まらないため、意図せず長生きしやすい点がリスクです。漏えい時も親revokeでは止まらないため、TTL/period設計と監視・明示revokeが前提になります。

監査デバイスの有効化、定期棚卸し（アクセサ列挙とlookup）、トークンロールでの最小権限化と短い更新間隔の設定が実務では有効です。

• 長寿命化と権限残存リスク（特にPeriodic）
• 親revokeが効かないため、明示revokeと短いTTL/periodで統制
• 監査ログとアクセサ運用で可視化を担保

Periodicロールの保守的設定（短いperiodと最小権限）

vault write auth/token/roles/automation \
  allowed_policies="read-only" \
  period=1h

# 1時間ごとに明示更新が必要。未更新なら自動失効し、残存リスクを縮小。
# 更新例
vault token renew $(vault token lookup -format=json | jq -r .data.id)

是正と予防：置換・失効・サーバ既定の見直し

既存のOrphanを子トークン化する“変換”はできません。正攻法は新トークンを望ましい親関係で再発行し、旧トークンをrevokeする置換です。運用停止が許容されるメンテナンス時間に計画的に行います。

予防として、トークンロールでの標準化（allowed_policies、ttl/period、renewポリシー）と、Vaultサーバ設定のtoken_ttl/token_max_ttlの見直しが有効です。必要な場合にのみ-orphanやperiodを使うルール化が肝要です。

• Orphanの是正＝新発行＋旧revoke（アクセサrevokeが安全）
• ロールとサーバ既定TTLで逸脱を抑止
• 定期的な棚卸しとアラート（長寿命検知）を合わせる

置換とサーバ既定TTL（例）

# 1) 望ましい親関係で新トークン発行（親あり=デフォルト）
NEW=$(vault token create -policy=app -ttl=30m -format=json | jq -r .auth.client_token)

# 2) 旧Orphanをアクセサで失効
OLD_ACCESSOR=accessor-BBBB
vault token revoke -accessor $OLD_ACCESSOR

# 3) Vaultサーバ設定（HCL）の既定TTL再確認（例）
# token_ttl   = "30m"
# token_max_ttl = "24h"
# 実際の適用はサーバ設定ファイルで行い、再起動が必要

試験対策の要点と落とし穴

頻出テーマは「親revokeの連鎖が及ぶか」「作成パス（create vs create-orphan）」「Periodicの更新要求（period）」。具体的なコマンド・APIパスとセットで記憶してください。

RootとOrphanの混同、Periodicを通常TTLと同様に考える誤解、lookupでの属性確認を失念する、といった落とし穴に注意。

• create-orphanを使うと親連鎖に入らない
• Periodicは親revokeに非連鎖。periodで更新必須（max_ttlなし）
• lookupでorphan/periodを確認。棚卸しはaccessorが有効

最小セットの確認コマンド（暗記推奨）

# 作成
vault token create -policy=app                    # 子
vault token create -policy=app -orphan            # Orphan
vault write auth/token/roles/ci period=24h        # Periodicロール
vault token create -role=ci                       # Periodic

# 検出
vault token lookup <token>
vault token lookup -accessor <accessor>

# 失効
vault token revoke <token>
vault token revoke -accessor <accessor>

問題で確認

よくある質問