Expired API keys in Elasticsearch: rejected on use, but do they linger in the cluster?

Question

Least-privilege access in Elasticsearch typically combines role-based access control with short-lived API keys: each service holds a role scoped to the indices and cluster actions it needs, and the key carries an expiration so credentials rotate on a schedule.

The documented part is straightforward: a request presenting an expired key is rejected. Less clear is the lifecycle of the key record afterward. Expired keys appear to remain in the internal security index until explicitly invalidated or deleted, and cleanup behavior seems to differ between the 7.x and 8.x release lines, with newer versions adding more automation around invalidation. Exact semantics for a specific minor version deserve verification against current documentation.

This matters for credential hygiene: an audit listing can mix valid, expired, and invalidated keys, and a client that caches its token can keep presenting a stale credential after expiration has already passed.

Assuming an Elasticsearch 8.x cluster with API keys enabled:

Does the cluster ever remove expired key documents on its own, or is removal always an explicit invalidate-and-delete operation?
Is there a supported way to list only keys that have expired but not yet been removed?
Do any 8.x settings govern retention or automatic cleanup of expired API keys?

Tasadduq Burney · Answer

AnswerElasticsearch 8.x does not automatically remove expired API key documents. They remain in the internal .security index until you explicitly delete them (via the delete‑API‑key or invalidate‑and‑delete API). There is no cluster‑level setting that controls retention or triggers a background purge.Confirmed factsExpired keys are rejected on use (401 Unauthorized).The key’s document stays in .security with a past expires_at timestamp.Removal requires an explicit call: DELETE /_security/api_key/ or the invalidate‑and‑delete endpoint.No setting such as xsecurity.api_key.expire or similar exists to automate cleanup.Steps to list and clean expired keysRetrieve all API keys:GET /_security/api_keyLocally filter the response for entries where expires_at (epoch milliseconds) is earlier than the current time.For each expired key, delete it:DELETE /_security/api_key/Verification (optional)To confirm the behavior in your cluster:Create a short‑lived key (e.g., 1‑minute TTL).Wait for it to expire.Run GET /_security/api_key and verify the key still appears with a past expires_at.Attempt a request with that key and observe a 401 response.Delete the key via the API and confirm it no longer appears in the list.

Expired API keys in Elasticsearch: rejected on use, but do they linger in the cluster?

1 answer

Answer

Confirmed facts

Steps to list and clean expired keys

Verification (optional)

Your perspective belongs here.

0 question comments