What Happens to an Extendable Nomad Client Token When Its ACL Policy Is Revoked?

Question

Nomad's ACL framework allows client tokens to be marked extendable so their TTL renews automatically when the token is used, supporting long-running allocations without manual rotation. When an operator revokes the underlying ACL policy to enforce least privilege, the documented behavior states that subsequent API calls are rejected; however, the exact interaction between an active auto-extend cycle and revocation remains ambiguous.

Because auto-extend applies only to client tokens and server-side tokens do not receive automatic renewal, the de-synchronization may differ by token type and by Nomad version. It is also unclear whether a token scoped to multiple jobs exhibits the same renewal-then-rejection sequence as a single-job token, or whether the audit log records a revocation detected mid-renewal.

Does an extendable client token continue to auto-extend its TTL after the governing ACL policy is revoked but before the next API call is rejected? How does this behavior change for tokens scoped to multiple jobs, and which Nomad versions should be tested to confirm the current semantics?

Tasadduq Burney · Answer

Direct Answer
An extendable client token does not continue to auto-extend after its governing ACL policy is revoked. Auto‑extension happens only at the moment the token is presented for an API request; there is no background renewal thread. The very next API call fails with a 403 (permission denied) and the token’s TTL remains unchanged.

Confirmed Facts

Auto‑extend is triggered on each API request that presents the token.
When the ACL policy is deleted, the token’s effective permission set becomes empty immediately.
The token object stays in Nomad’s state store until its natural TTL expires or it is explicitly revoked.
Audit logs record the failed request as an authentication failure; no separate “renewal” event is emitted.

Multi‑Policy Tokens
If the token is attached to multiple policies, revoking one policy removes only the permissions granted by that policy. The remaining policies stay active, and auto‑extend continues to work for those surviving permissions. Each request re‑evaluates the full policy set attached to the token at that moment.

Version Scope
This behavior has been stable since Nomad 0.9 (ACL GA) through the current 1.8.x series. No version introduced asynchronous renewal that would alter the outcome.

Verification Steps

Create an extendable client token with a single policy: nomad acl token create -type=client -policy=example-policy -extendable
Start a long‑running allocation that periodically calls the Nomad API (e.g., a loop running nomad alloc status).
Delete the policy: nomad acl policy delete example-policy
Observe the next allocation API call fail with 403 and verify the token’s TTL is unchanged via nomad acl token info <token-id>.
Repeat with a token bound to two policies; delete only one and confirm the token still works for the remaining policy’s permissions and continues to auto‑extend.
Check the audit log: nomad operator audit – the failed request shows an authentication failure, not a renewal‑specific event.

One Diagnostic Detail
Are you using Nomad Enterprise with multiple namespaces? If yes, confirm that the policy and token reside in the same namespace; a revocation in a different namespace does not affect the token.

What Happens to an Extendable Nomad Client Token When Its ACL Policy Is Revoked?

1 answer

Direct Answer

Confirmed Facts

Multi‑Policy Tokens

Version Scope

Verification Steps

One Diagnostic Detail

Your perspective belongs here.

0 question comments