Vault のトークン種類を正しく使い分ける: service / batch 実践

Vault のアクセスポリシーはトークンに紐づきます。中でも service トークンと batch トークンの違いは、日々の運用だけでなく Associate 試験でも頻出です。

本稿では、両者のライフサイクルと制約、代表ユースケース、選定基準を実務目線で整理します。細部の挙動はバージョンによって微差があり得ますが、ここで扱う基本動作は安定的に利用できます。

トークン種類の全体像

Vault のトークンは大別して service と batch の 2 種類です。service はサーバ側に状態を持つ永続的なトークンで、更新・失効・参照が可能です。batch はサーバ側に保存されない軽量トークンで、発行時点で有効期限と権限が固定され、更新や個別失効はできません。

両者は検証フローが異なります。service は都度トークンストアを参照しますが、batch は署名検証と埋め込み情報の確認で完了します。高スループットの一時的ワークロードでは batch、長期運転のサービスでは service が基本の選択肢です。

• どの認証メソッドでも、role や設定で token_type を service か batch に指定可能（未指定は多くのケースで service）
• service はトークンストアに保存され、lookup/renew/revoke が可能
• batch は非保存・非更新・非失効（期限到来でのみ失効）。ポリシーは発行時点で固定

サービス vs バッチの検証フロー

まずはデフォルト（service）でトークンを発行して確認

vault token create -policy=default -ttl=1h
# 出力されたトークンを lookup（service は可能）
vault token lookup s.XYZ...

service トークンの特性と運用

service トークンはトークンストアに保持されるため、アクティブなトークンの参照、更新、即時失効、アクセサーによる部分失効、ツリー失効などが可能です。長時間稼働するアプリケーションやデーモン、Vault Agent の自動更新シナリオで使います。

periodic（更新を前提に無期限に使える）や orphan（親の失効の影響を受けない）といった管理機能を備えます。cubbyhole はトークン単位の一時ストレージで、service トークンで利用できます。

• renewable: TTL 以内で更新可能（max_ttl 上限まで）
• revoke: ID または accessor、prefix で即時失効が可能
• periodic: -period を指定すると更新を続ける限り有効
• orphan: 親との階層を持たないトークンとして発行可能
• cubbyhole: トークン専用の一時 KV を利用可能

典型操作（更新・失効・periodic・orphan）

# service トークン発行（1時間）
vault token create -policy=app -ttl=1h

# 更新（さらに30分延長、max_ttl に依存）
vault token renew s.ABC... 30m

# 即時失効（ID で）
vault token revoke s.ABC...
# アクセサーで失効
evault token revoke -accessor hvs.abc...

# periodic トークン（24時間周期で更新必須）
vault token create -policy=agent -period=24h

# orphan トークン
evault token create -policy=ops -orphan

batch トークンの特性と使いどころ

batch トークンはサーバストレージに記録されない軽量トークンです。検証は署名と埋め込みメタデータで行われます。更新不可・個別失効不可・lookup 不可が基本動作です。短時間・高スループットな処理（CI/CD、サーバレス、バッチ処理、マップリデュース）に適します。

重要な違いとして、発行時に確定した有効期限とポリシーが、そのトークンの寿命中は固定されます。後から role/identity グループやポリシーを変更しても、既に発行済みの batch トークンの権限は変わりません。

• renew/revoke/lookup: いずれも不可（期限到来のみで失効）
• num_uses のような使用回数制限は非対応
• cubbyhole は非対応（サーバ側にトークン状態が無いため）
• 発行時点のポリシーが固定（後続のポリシー変更は反映されない）
• 高並列・短時間ワークロード向け（発行/検証が軽量）

batch トークンの発行と制約の確認

# batch トークンを 15 分で発行
vault token create -type=batch -policy=build -ttl=15m

# lookup は失敗（batch は参照不可）
vault token lookup s.BATCH...   # => エラー: batch token は lookup 不可

# revoke も不可（期限到来を待つ）
vault token revoke s.BATCH...   # => エラー: batch token は revoke 不可

選定基準と代表ユースケース

選定はライフサイクル管理の要否と、ポリシー変更の追従要否で決めます。長期稼働・権限の即時切替・強制失効が必要なら service。ジョブ単位・短寿命・多数発行でオーバーヘッドを避けたいなら batch。

試験対策の観点では、batch の非更新・非失効・lookup 不可、そしてポリシー固定という点を確実に押さえてください。

• 長期運転/ローリング更新/強制失効が必要 → service
• 短時間ジョブ/高頻度発行/スループット重視 → batch
• ポリシー変更を即時反映したい → service を選ぶ

AppRole で token_type を使い分ける例

# AppRole で batch を発行する role を作成
vault write auth/approle/role/ci \
  token_policies=build \
  token_ttl=15m \
  token_max_ttl=30m \
  token_type=batch

# 長期運転サービス向けの service 役割
evault write auth/approle/role/app \
  token_policies=app \
  token_ttl=1h \
  token_max_ttl=24h \
  token_type=service

運用とセキュリティ考慮

service トークンは更新と失効が運用の要です。Vault Agent の自動更新を利用し、max_ttl の設計とアクセサー運用（部分失効）を確立します。ツリー失効やプレフィックス失効はインシデント時の一斉無効化に有効です。

batch トークンは短 TTL を前提に、漏えいリスクを時間で限定します。個別失効ができないため、万一の漏えい時はロールや発行経路の停止、該当システムの一時遮断で被害を最小化します。Vault のトークン検証鍵のローテーション方針もあわせて検討してください（運用変更は慎重な事前検証が必須）。

• service: TTL 設計、更新自動化（Agent）、アクセサー管理、即時失効手順を整備
• batch: 短 TTL、最小権限、発行経路の監査、漏えい時の封じ込め計画
• どちらも監査ログとメトリクスで異常検知を行う

Vault Agent で service トークンを自動更新する最小例

# agent.hcl の一例
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 = "/var/run/vault/token" }
  }
}
cache {
  use_auto_auth_token = true
}
listener "tcp" { address = "127.0.0.1:8200" tls_disable = true }

Associate 試験の落とし穴チェック

問題文に renew、revoke、lookup、cubbyhole といったキーワードが出たら、batch では不可であることを即答できるようにしておきます。もう一つの頻出は、発行後のポリシー変更の反映有無です（service は反映されやすく、batch は固定）。

ユースケースの読み替え問題にも注意。常駐サービスや Agent は service、CI/CD やサーバレスは batch が定石です。

• batch: 非更新・非失効・lookup 不可・ポリシー固定
• service: 更新・即時失効・lookup 可能・cubbyhole 利用可
• ユースケースを聞かれたらライフサイクル管理要否で切る

知識チェック用の最小コマンド

# batch かどうかの違いを体で覚える
vault token create -type=batch -policy=dev -ttl=10m
vault token lookup <batch_token>   # 失敗するはず
vault token create -policy=dev -ttl=10m
vault token lookup <service_token> # 成功するはず

問題で確認

よくある質問