Child lease cleanup after parent token revocation

Question

Child lease cleanup after parent token revocation
Goal: determine whether revoking a parent token invalidates all child leases immediately, or whether applications must tolerate orphaned leases until each lease TTL expires.
Constraint: Vault documents token revocation cascade as best-effort. If a child lease’s secrets engine is unavailable, revocation can fail and the lease may remain valid. Vault exposes no metric for pending or failed child lease revocations; the expiration manager removes leases only at TTL expiry.
Assumes Vault 1.17 or later with integrated storage. Replication lag is out of scope; the question concerns local cascade semantics.
Does Vault retry failed child lease revocations after the parent token revocation completes? Is there a supported way to force cleanup of orphaned child leases before TTL expiry? Should client code treat parent token revocation as proof that child leases are invalid?

Zoha · Answer

Direct Answers Does Vault retry failed child lease revocations? No. The cascade is best-effort and runs once during the parent revocation request. If a secrets engine is unreachable or returns an error for a specific lease, that lease is left untouched and Vault does not schedule a retry. Is there a supported force-cleanup operation? No general operation exists. You can only revoke leases you can identify—by exact lease ID via sys/leases/revoke or by prefix via sys/leases/revoke-prefix—and only while the backing secrets engine is healthy. Both require sudo capability on the lease path. Should clients treat parent revocation as proof child leases are invalid? No. A child lease remains valid and renewable until it is explicitly revoked or its TTL expires. Client code must handle secret-use failures (permission denied, lease not found) as the signal that a lease has been revoked. Why This Happens Token revocation cascade applies to child tokens, not to dynamic-secret leases created by those tokens. Leases are owned by their secrets engine (database, AWS, etc.), not by the token that requested them. The expiration manager only removes leases at TTL expiry; it does not track "pending" or "failed" cascade revocations. Verification Steps (Run in a Test Namespace) Create a parent token with a short TTL (e.g., 1h). Use that token to request a dynamic secret (database creds, AWS IAM) producing a child lease with its own TTL (e.g., 4h). Record the child lease ID from the response. Revoke the parent token: vault token revoke . Immediately look up the child lease: vault lease lookup or API GET /sys/leases/lookup. Confirm revocation_time is absent and renewable is true—the lease is still alive. Optional: stop the secrets engine, attempt explicit revocation, observe failure, restart engine, revoke successfully. Operational Guidance Set lease TTLs short enough that natural expiry is an acceptable cleanup window. If you must revoke immediately, script explicit sys/leases/revoke-prefix against the known engine prefix after confirming the engine is reachable. Monitor vault_audit for lease_revoke failures; they are not retried. One Diagnostic Detail Which secrets engine backs the child leases (database, AWS, Consul, custom)? The engine's availability and its own revocation semantics determine whether explicit revoke-prefix will succeed.

Child lease cleanup after parent token revocation

Child lease cleanup after parent token revocation

1 answer

Direct Answers

Why This Happens

Verification Steps (Run in a Test Namespace)

Operational Guidance

One Diagnostic Detail

Your perspective belongs here.

1 question comment