Reload projected Kubernetes ServiceAccount tokens after rotation

A short-lived token file does not help if the application keeps using an old in-memory copy.

Source facts

Kubernetes can project a ServiceAccount token into a Pod. The kubelet requests, stores, exposes, and refreshes it as expiration approaches. The application is responsible for reloading the token when it rotates. The documentation also describes audience binding, which constrains where a token is intended to be accepted.

Source: Kubernetes documentation — Configure Service Accounts for Pods.

Applicability

Review projected ServiceAccount token rotation and the application’s responsibility to reload it.

DSE recommendation

DSE recommends checking the client library’s credential-refresh behavior before deploying a long-running API integration. Avoid copying the projected token into an immutable startup variable or an unrelated file without a refresh design. Record the intended audience, credential path, and identity without retaining token values. Treat periodic authentication failures after an otherwise successful startup as a reason to inspect refresh behavior and expiry. Keep diagnostics limited to metadata so investigation does not create a reusable credential in a ticket.

Verification

In a test workload, run the integration long enough to observe token rotation and confirm requests continue using refreshed credentials. Inspect safe metadata and application behavior rather than printing the token. Test that an unintended audience is rejected where the receiving service supports that validation. Record the refresh event and subsequent authorized operation through sanitized metadata. Have the integration owner identify the code or supported library behavior that reloads the file, so a successful short startup check is not the only credential-lifecycle evidence.

Official reference

Kubernetes documentation — Configure Service Accounts for Pods. Reviewed October 20, 2026.