Vault tokens aren’t all created equal, and the most surprising thing is that by default, most tokens don’t have an expiration time.
Let’s see what that looks like in practice. Imagine we have a Vault server running, and we want to interact with it using a token. We can authenticate with a username and password (or any other auth method) to get an initial token.
vault login -method=userpass username=myuser password=mypass
This command will output something like:
Success! You are now authenticated. Your token is: s.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This s.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is a service token. By default, it’s good for 30 days (720 hours). You can see its properties:
vault token lookup s.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Output:
Accessor: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Audience: <nil>
Creation Time: 2023-10-27 10:00:00 +0000 UTC
Creation TTL: 720h0m0s
Expiration: 2023-11-26 10:00:00 +0000 UTC
ID: s.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Renewable: true
Subject: <nil>
TTL: 719h59m59s
Notice the TTL is slightly less than Creation TTL. That’s because the lookup command itself consumed a tiny bit of the token’s lifetime. This token is also Renewable: true. This means if we use it before it expires, we can extend its life.
vault token renew s.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This will give us a new token with a fresh TTL, effectively resetting the clock. This is how long-lived applications can maintain access to Vault without needing to re-authenticate with credentials constantly.
So, what problem does this solve? It provides a mechanism for services and applications to authenticate with Vault and access secrets without embedding long-lived credentials directly in their code. The renewable nature of service tokens allows for a balance between security and operational convenience.
The mental model here is that a token is a credential with a specific set of permissions and a lifespan. When you authenticate, Vault issues a token. This token can be used to perform actions within Vault up to the limit of its policies. It also has an expiration time, and crucially, it can often be renewed.
The core levers you control are the ttl and max_ttl parameters when creating tokens. ttl is the initial duration, and max_ttl is the absolute maximum duration the token can ever live, even with renewals. For example, if you create a token with ttl=30m and max_ttl=1h, you can renew it multiple times, but it will never live longer than one hour from its original creation time.
What most people don’t realize is that the vault token create command, when used without specifying ttl or renewable flags, will create a token with a default ttl and max_ttl inherited from the parent token or the Vault server’s configuration. This often results in tokens that are effectively permanent if they are never explicitly renewed or if the max_ttl is set very high.
The next concept you’ll run into is how to manage these tokens at scale, especially when dealing with dynamic secrets or short-lived access for ephemeral workloads.