Q: Should we use batch tokens or service tokens for applications?

Service tokens for: long-running applications (web servers, APIs, daemons), need renewal (token lives longer than TTL through renewal), token needs additional capabilities (create child tokens, update leases). Batch tokens for: short-lived operations (CI/CD jobs, Lambda functions), no renewal needed (job finishes before token expires), minimize token footprint (batch tokens are encrypted blobs, can't be inspected). Batch advantages: lightweight (smaller storage in Vault), can't be listed (enumerate tokens in Vault won't show batch tokens), can't be renewed/revoked individually (managed as group). Service advantages: full features (renewability, child tokens), visible in Vault (can audit/revoke), more flexible. Use service tokens by default, batch tokens for specific use cases (ephemeral workloads, minimize token storage). Most applications: service tokens (need renewal for long-running services). CI/CD pipelines: batch tokens (job completes quickly, don't need renewal).

Q: How do we revoke all tokens for a compromised user?

Revoke accessor: each token has accessor (non-sensitive token identifier). When user leaves/compromised: `vault token revoke -accessor ` revokes specific token, `vault token revoke -mode path auth/userpass/login/ ` revokes all tokens created by that user. This immediately invalidates all user's tokens (they can't access Vault anymore). Verify: user tries to access Vault → gets 403 permission denied. Revocation cascades: revoking parent token revokes all child tokens (if user created service account tokens, those are revoked too). Preventive measures: short TTL for human tokens (8-12 hours max—if account compromised, tokens expire quickly), require re-authentication for sensitive operations (can't modify policies with stale token), audit logging (track who accessed what, when). Automate: offboarding script that revokes all user tokens + disables user account. Don't rely on manual revocation—integrate with HR offboarding process.

Question 1

What's the difference between root tokens and regular tokens in Vault?

Accepted Answer

Root tokens: unlimited access to Vault (can do anything—create policies, delete secrets, modify configuration), no expiration (last forever unless revoked), dangerous (if compromised, attacker owns entire Vault). Regular tokens: scoped permissions (can only do what policies allow), expiration (TTL after which token stops working, typically hours/days), renewable (can extend lifetime without recreating). Use root token only: initial Vault setup, emergency recovery (when policies break something). Delete root token immediately after use. Use regular tokens for: applications accessing secrets (limited permissions), humans accessing Vault (scoped to their role), automation (specific permissions for CI/CD). Common mistake: using root token for applications (massive security risk—compromise gives attacker everything). Always use least-privilege regular tokens.

Question 2

How long should Vault tokens live before expiring?

Accepted Answer

Short-lived for humans: 8-12 hours (length of work day), renewable if needed. Medium for applications: 24 hours - 7 days, auto-renewed by application. Long-lived service accounts: 30-90 days (but prefer short-lived with auto-renewal). Never: forever/no-expiration (if token leaks, it's valid indefinitely). Renewal pattern: app gets token with 24-hour TTL, renews at 50% lifetime (12 hours), gets 24 more hours. This maintains continuous access while tokens eventually expire if app stops renewing (abandoned app won't leak valid tokens forever). Shorter TTL: more secure (leaked tokens expire quickly), more overhead (frequent renewal). Longer TTL: less secure (leaked tokens valid longer), less overhead. Balance: 24-hour TTL with auto-renewal is sweet spot for most applications. Humans: 8-12 hour non-renewable (re-authenticate daily). Batch jobs: exact job runtime + buffer (if job takes 2 hours, 3-hour token is sufficient).

Question 3

What happens when a Vault token expires—do apps break?

Accepted Answer

Yes, unless configured for renewal. Token expires → subsequent Vault requests fail with 403 permission denied → app can't access secrets → app breaks. Prevention: applications must renew tokens before expiration. Vault SDKs handle renewal automatically (renew at 50% of TTL—24-hour token renewed at 12 hours). Manual renewal: check token TTL periodically, renew when <25% remains. Renewal process: `vault token renew` extends TTL (gets another full period, e.g., 24 hours). Renewal limits: tokens can be renewed N times (configured in policy), eventually must re-authenticate. Failure scenarios: app doesn't renew token → expires → app crashes (fix: implement renewal), network interruption during renewal → renewal fails → token expires (fix: retry renewal with exponential backoff). Monitoring: alert when tokens are close to expiration without renewal (indicates app problem before it breaks).

Question 4

Should we use batch tokens or service tokens for applications?

Accepted Answer

Service tokens for: long-running applications (web servers, APIs, daemons), need renewal (token lives longer than TTL through renewal), token needs additional capabilities (create child tokens, update leases). Batch tokens for: short-lived operations (CI/CD jobs, Lambda functions), no renewal needed (job finishes before token expires), minimize token footprint (batch tokens are encrypted blobs, can't be inspected). Batch advantages: lightweight (smaller storage in Vault), can't be listed (enumerate tokens in Vault won't show batch tokens), can't be renewed/revoked individually (managed as group). Service advantages: full features (renewability, child tokens), visible in Vault (can audit/revoke), more flexible. Use service tokens by default, batch tokens for specific use cases (ephemeral workloads, minimize token storage). Most applications: service tokens (need renewal for long-running services). CI/CD pipelines: batch tokens (job completes quickly, don't need renewal).

Question 5

How do we revoke all tokens for a compromised user?

Accepted Answer

Revoke accessor: each token has accessor (non-sensitive token identifier). When user leaves/compromised: `vault token revoke -accessor ` revokes specific token, `vault token revoke -mode path auth/userpass/login/` revokes all tokens created by that user. This immediately invalidates all user's tokens (they can't access Vault anymore). Verify: user tries to access Vault → gets 403 permission denied. Revocation cascades: revoking parent token revokes all child tokens (if user created service account tokens, those are revoked too). Preventive measures: short TTL for human tokens (8-12 hours max—if account compromised, tokens expire quickly), require re-authentication for sensitive operations (can't modify policies with stale token), audit logging (track who accessed what, when). Automate: offboarding script that revokes all user tokens + disables user account. Don't rely on manual revocation—integrate with HR offboarding process.

HashiCorp Vault Token Management: Complete Authentication Guide

Token Authentication Fundamentals

Basic Authentication Command

Frequently Asked Questions

Need Expert IT & Security Guidance?

HashiCorp Vault Authentication Setup | LDAP, Userpass, Certificate & Token Methods

HashiCorp Vault CLI Installation Guide: Windows, macOS, Linux

HashiCorp Vault: How to Read and Write Secrets Securely (CLI & API Guide)