If your secret lease is expiring earlier than you expect, there are a number of configuration options to check.
Token that created the secret
All dynamic secret leases are tied to the token that generates the secret. When that token expires, any leases created with that token are also revoked - regardless of the secret’s lease TTL.
The best practice is to use a workflow that keeps your token valid as long as your application needs it. If you do so, lease lifetimes should never be shortened due to token expiration.
If the tokens belong to applications, you may want to look into either creating long max TTLs on those tokens or using periodic tokens to tie the token lifetime closely to application lifetime.
Hierarchy of TTLs
The Token Time-To-Live, Periodic Tokens, and Explicit Max TTLs documentation outlines the hierarchy of TTLs in Vault configuration.
It’s important to examine this document and your configuration settings in order to understand what default_ttl is being applied and what max_ttl is being evaluated at lease renewal.
- To find your System TTLs: See your Vault configuration file or refer to the document above for the default
-
To determine the TTLs of your Mount: Run
vault read sys/auth/<auth_mount_name>/tuneorvault read sys/mounts/<auth_mount_name>/tuneto see current mount settings - To determine if you have TTLs set at a more specific configuration point: Depending on the backend, you may have roles, groups, users, etc that allowed you to configure TTLs. You can use the HTTP API of your backend to view these settings.