Vault Token Types Done Right: A Practical Guide to service vs batch

Vault attaches access policies to tokens. The distinction between service and batch tokens shows up constantly in day-to-day operations and is also a frequent Associate exam topic.

This article organizes the lifecycle, constraints, representative use cases, and selection criteria from a practitioner's perspective. Minor behavior may shift between versions, but the fundamentals covered here are stable.

The Big Picture of Token Types

Vault tokens come in two broad flavors: service and batch. A service token is a persistent token with server-side state that you can renew, revoke, and look up. A batch token is a lightweight token that is not stored server-side; its expiry and permissions are fixed at issuance, and it cannot be renewed or individually revoked.

Their verification flows differ. Service tokens consult the token store on every request, while batch tokens are verified by signature and the metadata embedded in the token itself. Batch is the default pick for high-throughput, short-lived workloads; service is the default for long-running services.

• Every auth method lets you set token_type to service or batch via a role or config (most defaults are service when left unspecified)
• Service tokens are stored in the token store and support lookup / renew / revoke
• Batch tokens are non-stored, non-renewable, and non-revocable (they expire only when their TTL elapses). Policies are frozen at issuance

Service vs batch verification flow

Start by issuing a default (service) token and inspecting it

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

Service Token Characteristics and Operations

Because service tokens are kept in the token store, you can look them up, renew them, revoke them immediately, perform partial revocation by accessor, or cascade-revoke a token tree. Use them for long-running applications, daemons, and Vault Agent auto-renewal scenarios.

They support management features like periodic tokens (usable indefinitely as long as they keep being renewed) and orphan tokens (unaffected by parent revocation). The cubbyhole, a per-token transient KV store, is also a service-token-only feature.

• renewable: can be renewed within TTL (up to max_ttl)
• revoke: immediate revocation by ID, accessor, or prefix
• periodic: when -period is set, the token stays valid as long as it is renewed
• orphan: can be issued without a parent in the token hierarchy
• cubbyhole: per-token transient KV available

Typical operations (renew, revoke, 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 Token Characteristics and When to Use Them

Batch tokens are lightweight tokens that are not recorded in server storage. Verification relies on a signature and embedded metadata. They cannot be renewed, individually revoked, or looked up. They fit short-lived, high-throughput workloads such as CI/CD, serverless, batch processing, and map-reduce jobs.

A key distinction: the TTL and policies determined at issuance are frozen for the token's lifetime. Subsequent changes to roles, identity groups, or policies do not modify the permissions of previously issued batch tokens.

• renew / revoke / lookup: none are supported (the token expires only by TTL)
• Use-count limits like num_uses are not supported
• No cubbyhole support (there is no server-side state for the token)
• Policy is frozen at issuance (later policy changes are not reflected)
• Designed for highly concurrent, short-lived workloads (issuance and verification are cheap)

Issuing a batch token and confirming the constraints

# 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 不可

Selection Criteria and Representative Use Cases

Pick based on whether you need lifecycle management and whether policy changes must propagate. If you need long-running tokens, immediate permission changes, or forced revocation, choose service. If you want per-job, short-lived, high-volume issuance with minimal overhead, choose batch.

For exam preparation, lock in the fact that batch tokens cannot be renewed, revoked, or looked up, and that their policy is fixed.

• Long-running workloads, rolling renewals, or forced revocation needed → service
• Short jobs, high-volume issuance, throughput-sensitive paths → batch
• Need policy changes to take effect immediately → choose service

Example: using token_type with AppRole

# 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

Operations and Security Considerations

Renewal and revocation are the operational pillars for service tokens. Use Vault Agent auto-renewal, design max_ttl thoughtfully, and standardize accessor-based partial revocation. Tree and prefix revocation are powerful for mass invalidation during incidents.

Batch tokens lean on short TTLs to time-box leak exposure. Because you cannot revoke them individually, contain leaks by disabling the role or issuance path and temporarily isolating the affected system. Also consider your Vault token verification key rotation policy (any operational change must be validated carefully ahead of time).

• Service: design TTLs, automate renewal with Agent, manage accessors, and document immediate revocation procedures
• Batch: short TTLs, least privilege, audited issuance paths, and a containment plan for leaks
• For both types, detect anomalies via audit logs and metrics

Minimal example: auto-renew a service token with Vault Agent

# 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 Exam Pitfalls Checklist

When you see keywords like renew, revoke, lookup, or cubbyhole, instantly recognize that batch does not support them. Another frequent topic is whether policy changes after issuance propagate (service tends to propagate; batch is frozen).

Watch for use-case translation questions, too. Long-running services and Agent flows belong to service tokens; CI/CD and serverless workloads belong to batch tokens.

• Batch: non-renewable, non-revocable, no lookup, frozen policy
• Service: renewable, immediate revocation, lookup-capable, supports cubbyhole
• When asked about use cases, decide based on whether lifecycle management is required

Minimal commands to validate your understanding

# 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> # 成功するはず

Check Your Understanding

Frequently Asked Questions