Manage Tokens
Two token types
Service tokens are persisted in the token store: renewable, with accessors, child tokens, and cubbyhole storage. Batch tokens are lightweight encrypted blobs: no storage entry, no renewal, no accessors, no children - suited to high-volume short-lived workloads. Know which limitations belong to which type.
TTLs
Every token has ttl (initial lease) and max_ttl (hard cap). vault token renew extends by an increment but never past max_ttl; explicit_max_ttl cannot be extended at all. A token created with period is periodic: renewable indefinitely as long as it is renewed within its period.
Hierarchy and revocation
Tokens created by a token are its children; revoking a parent revokes the whole subtree. vault token revoke -self kills your own token; vault token revoke -accessor <id> revokes a token when you hold only its accessor, which is how operators audit and revoke without possessing the token. Accessors are safe to log; the token itself is not. Orphan tokens (-orphan) have no parent and survive parent revocation, but creating them requires sudo on auth/token/create-orphan.
Traps
- Root tokens have no TTL and cannot be renewed - create them rarely and revoke them.
- Batch tokens cannot be renewed and do not appear in
vault list auth/token/accessors. - Logging in again produces a new token; it does not extend the old one.
- Revoking a token also revokes the leases it created.
Rule of thumb: short TTLs plus periodic tokens for long-running services; use accessors for auditing and revocation.