Tokens, leases, and renewal | Vault Associate 003: secrets and operations

Concept and mechanism

A token authorizes Vault requests; a dynamic credential can have its own lease. These lifecycles relate but should not be treated as one timer. Service tokens support renewal, accessors, and individual revocation. Batch tokens are lighter but do not offer those same functions. An accessor references a token for limited operations rather than authenticating as its holder. The caller still needs management authorization. In the normal hierarchy, revoking a parent revokes non-orphan children and associated leases. Creating an orphan changes that dependency without removing TTL or policies. The decision should reflect who must control workload lifecycle.

Guided application

In a fictional 90-minute batch with an initial 30-minute lease, copying the password to disk does not extend validity. Renew when allowed and handle replacement when the maximum is reached. Requested renewal increment is time from now and can be limited by the backend: if the response returns 900 seconds, use 15 minutes rather than adding the previous TTL. Timely renewed periodic tokens can remain valid, but an explicit max TTL still imposes an end of life. Reserve root for bootstrap or emergencies and revoke it when no longer needed. An arbitrary password stored in KV does not become a dynamic credential: expiring the read token does not automatically change the external-system password.

IN PRACTICE

Requested TTL 1800, returned TTL 900: the consumer plans with 900 seconds.

Common pitfalls

Accessor as token; orphan as immortal; renewal as addition; renewed token as every lease renewed.

Related topics: Authentication and identity · Policies, paths, and capabilities · KV, database, and wrapping secrets

Take this idea with you

Use returned validity and exercise renewal, replacement, and revocation.

Create account

Reference: Lease renewal and revocation · Vault Associate (003); product version tested: Vault 1.19