HashiCorp Certified: Vault Associate Certification

Assess Vault Tokens

Create a Token based on Use Cases

When working with HashiCorp Vault, selecting the right token type ensures secure, efficient access for your applications and users. Whether you’re architecting a long-running service, enforcing strict usage limits, or preparing for the Vault Associate exam, this guide walks you through the five main Vault token types and their optimal use cases.

Token TypeIdeal ForKey Feature
Periodic TokenLong-running applicationsRenewable indefinitely without reissuance
Service Token (Use-Limit)Short-lived tasks with fixed invocation countAutomatically revoked after a set number of uses
Orphan TokenChild tokens that outlive their parentIndependent lifecycle—cannot be revoked by parent token repeal
CIDR-Bound TokenNetwork-restricted accessBound to specific IP or CIDR range
Batch TokenMulti-cluster replicationEphemeral — not persisted to storage, minimizing overhead

1. Periodic Token

Use a periodic token when you have a service that cannot handle token replacement mid-flight but still requires ongoing authentication. These tokens come with a finite TTL but no maximum TTL, allowing endless renewals.

Note

To renew a periodic token:

vault token renew <your-periodic-token>

The image is a slide titled "Create a Token Based on Needs," listing requirements for a periodic token, including handling long-running apps and indefinite renewal.


2. Service Token with Use Limits

When you need to enforce a fixed invocation count—regardless of how much TTL remains—opt for a service token configured with a usage limit. Vault will automatically revoke it after the specified number of successful requests.

ConfigurationExample
Max uses3
TTL1h

The image is a slide titled "Create a Token Based on Needs," detailing a requirement to limit a token's use to three times regardless of its remaining TTL, with a highlighted section labeled "Service Token with Use Limits."


3. Orphan Token

An orphan token has no parent association—making it immune to parent token revocation. Use it when you need a child token to survive beyond its creator’s lifecycle.

Note

Orphan tokens are ideal for background jobs or off-line processes that must persist independently.

The image is a slide titled "Create a Token Based on Needs," listing requirements for an "Orphan Token," which is not impacted by its parent's lifecycle and has an extended expiration.


4. CIDR-Bound Token

To restrict token usage to a specific IP or network block, create a CIDR-bound token. This is simply a service token with additional --cidr parameters:

vault token create \
  --period=24h \
  --cidr=10.3.5.16/32 \
  --policy=my-policy

Even if the token is exfiltrated, it won’t work outside the defined network.

The image is a slide titled "Create a Token Based on Needs," explaining the concept of a CIDR-Bound Token, which is a token used by a specific host or within a certain network block. It includes a note that it's a regular service token with additional CIDR-bound configuration.


5. Batch Token

For global, multi-cluster environments, batch tokens automatically propagate across replication sets without ever hitting the storage backend. This reduces write amplification and storage load when you need to issue large volumes of tokens.

Warning

Batch tokens are not persisted. If a Vault node goes down before replication completes, the token may not be recoverable.

The image is a slide titled "Create a Token Based on Needs," listing requirements for token replication and storage efficiency, with a highlighted "Batch Token" button.


Additional Resources

Watch Video

Watch video content

Practice Lab

Practice lab

Previous
Explaining Time to Live TTL