Token TTL
How long the Vault authorization credential remains usable.
Chapter 4 of 16 · Human user · Priya
Reason about the independent lifetimes of the Vault token and the material obtained with it.
Chapter 3 complete and the constrained learner token available.
Priya can distinguish token and secret lease clocks and revoke a lease without displaying credentials.
| Owner | Consumer-facing responsibility |
|---|---|
| You own | Defines consumption, validation, reload, and stop-using behavior. |
| Platform team owns | Provides trusted runtime identity, protected delivery, network, and telemetry. |
| Vault owns | Operates auth mounts, policies, engines, audit, and recovery. |
How long the Vault authorization credential remains usable.
How long generated material remains valid.
An authenticated extension within configured limits.
Invalidation of a token or lease and supported external credentials.
source learn-vault/.runtime/learner.env
vault token lookup -format=json | jq '{ttl:.data.ttl,renewable:.data.renewable}'
vault read -format=json database/creds/orders-api | jq '{lease_id_present:(.lease_id|length>0),lease_duration,renewable}'| Symptom | Database requests fail although Vault login works. |
|---|---|
| Likely causes | The database lease expired, renewal stopped, or the pool retained revoked connections. |
| Inspect safely | Compare token TTL, lease duration, renewal timestamps, and pool errors. |
| Do not print | Token, leased username, password, or database URL. |
Break it: Revoke the database lease and attempt to reuse it.
Fix it: Obtain replacement material and rebuild the consumer connection rather than extending revoked data.
Escalate with time, endpoint, auth path, role, mount, namespace when relevant, status code, request ID, and sanitized error class. Never attach a credential or response body.
labs/bootstrap owns the disposable server, auth mounts, policies, roles, and engines; learner actions begin after setup.
$0; local containers only
Run labs/bootstrap/setup.sh and source .runtime/learner.env unless the chapter lab says AppRole alone is sufficient.
Request a database lease into ignored storage, inspect metadata, revoke it, and remove the runtime response.
source learn-vault/.runtime/learner.env
umask 077
vault read -format=json database/creds/orders-api > learn-vault/.runtime/db-lease.json
jq '{lease_id_present:(.lease_id|length>0),lease_duration,renewable}' learn-vault/.runtime/db-lease.json
lease_id=$(jq -r '.lease_id' learn-vault/.runtime/db-lease.json)
vault lease revoke "$lease_id"
rm -f learn-vault/.runtime/db-lease.json
Complete every item in the Verify section using metadata-only evidence; no secret value appears in terminal output or tracked files.
Use the Failure drill and Break it / fix it evidence fields. Stop before broadening policy, weakening identity or TLS checks, or copying secret-bearing diagnostics.
Remove runtime lease files and unset VAULT_TOKEN; Vault cleans the revoked database principal.
orders-api has two clocks: auth token and database lease. Readiness needs safe margin on both.
No. Their TTLs and renewal outcomes are independent.
Child tokens and leases, subject to token hierarchy semantics.
Before expiry, with jitter and enough retry margin.
Obtain fresh identity and material or fail closed before expiry.
Treat each credential as a timed capability with a replacement path and an explicit stop-using deadline.