Vault Periodic Tokenの実務と試験対策: 長寿命用途と注意点

Periodic Tokenは、明示的に更新し続ける限り有効でいられるサービス用トークンです。長期間稼働するデーモンやエージェントに適しています。

一方で、更新の失敗や盗難時の影響をどう抑えるか、運用・監視・ガバナンスの仕組みが不可欠です。

Periodic Tokenの基礎

Periodic Tokenはサービス用トークンの一種で、一定の期間ごとに明示的な更新を要求します。期限切れ前に更新し続ける限り、上限TTLに達して失効することはありません。更新に失敗すると即時に無効化されます。

作成方法は大きく2つです。1つはauth/token経由でperiodを明示して作成する方法、もう1つは各認証方式（例: AppRole、Kubernetes）のロール側でtoken_periodを設定して発行させる方法です。いずれもサービス用トークンとして発行され、Batch TokenはPeriodicにはなりません。

親子関係のない孤児化（orphan）を併用すると、親トークンの失効に巻き込まれず長期安定運用に向きます。ただし、明示的な失効やロールの変更、ポリシーの更新の影響は受けます。

• 対象: 長期間動作する自動化プロセス、Vault Agent、サイドカーなど
• 必須事項: クライアント側での定期更新（renew）実装またはAgent任せ
• 禁止・非対応: Batch TokenのPeriodic化、max_ttlとの併用
• 推奨: 最小権限ポリシー、CIDR制限、orphan化、監査ログ有効化

基本的な作成・確認（CLI）

vault token create -policy=app -period=24h -orphan
vault token lookup <TOKEN>
# 出力例: renewable: true, period: 24h, orphan: true

長寿命用途の設計パターン

長寿命トークンの安定運用では、更新を人手に頼らず自動化することが必須です。Vault AgentのAuto-Authと自動更新を利用し、ファイルシンクや環境変数でアプリへ安全に受け渡します。Kubernetesではサイドカー運用が分かりやすく、systemdサービスでも同様に常駐更新が可能です。

親子関係は運用方針で選びます。親トークンや上位ジョブのローテーションに影響されたくない場合はorphan化します。逆に、上位のリモート失効で一括停止したい場合はorphanを避けて階層を残します。

• Agent＋ファイルシンク: 再起動後も自動で再取得・更新
• K8sサイドカー: Podライフサイクルに同期、Pod内での安全な受け渡し
• orphan化＋最小権限: 盗難時の被害半径を限定
• CIDR制限・期間短めのperiod設定: 更新頻度とリスクのバランス最適化

Periodic Tokenの取得・更新フロー（orphan推奨）

Vault Agentでの自動更新（抜粋）

auto_auth {
  method "approle" {
    mount_path = "auth/approle"
    config = {
      role_id_file_path   = "/etc/vault/role_id"
      secret_id_file_path = "/etc/vault/secret_id"
    }
  }
  sink "file" {
    config = { path = "/run/secrets/vault.token" }
  }
}
cache { use_auto_auth_token = true }

作成と更新の手順（CLIとHTTP API）

auth/token経由で直接作る場合はperiodを指定します。運用での再現性を確保するには、auth/token/rolesにロールを作り、そのロールから発行するのが定石です。KubernetesやAppRoleなどの認証ロールにもtoken_periodを持つ設定項目があります。

更新はrenew-self（自分自身のトークン）を使うのが安全です。外部のトークンを更新する場合はauth/token/renewに対する特権が必要です。

• auth/token/roles: periodをロール側で強制し、逸脱を防止
• AppRole/Kubernetesロール: token_periodでPeriodic発行を強制
• renew-self優先: 不要な特権を避ける
• incrementはperiod以下で指定。指定なしでもperiodで更新される実装が一般的

CLIとHTTP APIの例

# 1) tokenロールを作成（Periodicを強制）
vault write auth/token/roles/longlife \
  allowed_policies="app" \
  orphan=true \
  period=24h

# 2) ロールからPeriodic Token発行
vault token create -role=longlife

# 3) 直接period指定で作成（必要な能力がある場合）
vault token create -policy=app -period=24h -orphan

# 4) 更新（自分自身）
VAULT_TOKEN=<TOKEN> vault token renew -increment=24h

# 5) HTTP APIでの更新（self）
curl -s \
  --header "X-Vault-Token: $TOKEN" \
  --request POST \
  --data '{"increment":"24h"}' \
  "$VAULT_ADDR/v1/auth/token/renew-self"

# 6) AppRoleロール側でPeriodicを付与
vault write auth/approle/role/webapp \
  token_policies="app" \
  token_type="service" \
  token_period="24h"

# 7) トークン情報の確認
vault token lookup $TOKEN

運用監視とトラブルシューティング

Periodic Tokenの安定運用は、期限の十分手前で確実に更新できているかの監視が肝です。Agent運用ではプロセス生存監視とログ監視、アプリ直更新ならメトリクスと警報を用意します。Vaultの監査ログでauth/token/renew-selfの成功可否を追跡し、異常時に切替・再取得のプレイブックを整備します。

よくある障害は、非更新型トークン（Batchやrenewable=false）を誤使用、親トークン失効に巻き込まれる、増分更新の指定ミス、時刻ずれ、ネットワーク断などです。

• 監査ログでrenew-selfの成功率を可視化
• 期限のX%前に更新、Y回リトライ、失敗で再取得へフォールバック
• サーバ・クライアントの時刻同期（NTP）
• 親トークンのライフサイクルとorphan方針の整合性を確認

自己更新と他者更新の使い分け（ポリシーとAPI）

# 自分自身の更新（特権不要、renewable=trueが前提）
curl -s -H "X-Vault-Token: $TOKEN" -X POST \
  -d '{"increment":"12h"}' \
  "$VAULT_ADDR/v1/auth/token/renew-self"

# 他トークンの更新は管理者向け（sudo相当の権限が必要）
# 参考ポリシー（厳格に限定すること）
path "auth/token/renew" {
  capabilities = ["update", "sudo"]
}

# トークン属性の確認
curl -s -H "X-Vault-Token: $TOKEN" \
  "$VAULT_ADDR/v1/auth/token/lookup-self"

セキュリティ上の注意とガバナンス

長寿命トークンは盗難時の被害が拡大しやすいため、配布と格納の経路を最小化し、最小権限ポリシーを徹底します。CIDR制限やnum_uses制限を適用できる場合は併用してリスクをさらに抑えます。

Periodic Tokenはmax_ttlやexplicit_max_ttlと併用できません。ロール設定ではtoken_periodとtoken_max_ttlは排他です。上限を持つライフサイクルを求める場合は通常のサービス用トークンを選びます。

組織ガバナンスとして、ロール定義のレビュー、監査ログの保全、漏洩時の失効手順（auth/token/revoke-selfと即時のロールローテーション）を手順化します。

• 最小権限ポリシー＋CIDR制限＋短めperiod＋orphan化
• ロールでtoken_periodを強制し、逸脱発行を禁止
• 漏洩時はrevoke-selfまたはrevokeで即時失効、Agentは自動再取得で復旧
• Batch Tokenは長寿命用途に不適（更新不可）

最小権限ポリシー例（HCL）

path "secret/data/app/*" {
  capabilities = ["read", "list"]
}
# 自己更新のみ許可（selfはトークン固有判定に依存）
path "auth/token/renew-self" {
  capabilities = ["update"]
}
# CIDR制限はロールやトークン発行時に付与（例）
# vault write auth/token/roles/longlife token_bound_cidrs="10.0.0.0/8,192.168.0.0/16"

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

Periodic Tokenはサービス用トークンであり、更新し続ける限り有効期限の上限を持ちません。Batch Tokenは更新不可でPeriodicになりません。ロールのtoken_period、auth/tokenのperiod、orphanの意味を正確に押さえてください。

renew-selfとrenewの違い、親子関係の影響、Vault Agentによる自動更新の有無はAssociate/Opsレベルで頻出です。

• 覚えるCLI: token create -period, token renew, token lookup
• 覚えるAPI: auth/token/renew-self, auth/token/lookup-self
• 覚えるロール項目: period または token_period, orphan, allowed_policies
• 落とし穴: token_max_ttlとtoken_periodは排他、Batchは更新不可

チートシート

# Periodic発行（ロール経由）
vault write auth/token/roles/ll allowed_policies=app orphan=true period=24h
vault token create -role=ll

# Periodic発行（AppRoleロール）
vault write auth/approle/role/app token_type=service token_period=24h token_policies=app

# 自己更新と確認
vault token renew -increment=24h $TOKEN
vault token lookup $TOKEN

問題で確認

よくある質問