Kubernetes ServiceAccount Token Projection

Kubernetes ServiceAccount Token Projection refers to the mechanism by which time-bound, audience-scoped authentication tokens for a pod's service account are generated and mounted directly into the pod as a projected volume, replacing the older pattern of long-lived, automatically mounted tokens stored in a Secret.

Why Projection Replaced Secret-Based Tokens

Limitations of the Legacy Approach

The original mechanism automatically created a kubernetes.io/service-account-token Secret for every service account and mounted it into every pod using that account, producing tokens with no built-in expiration and broad, unscoped validity, a design that projection specifically addresses by generating tokens with defined lifetimes and intended audiences instead.

Reduced Blast Radius From Token Exposure

Because projected tokens expire and are scoped to specific audiences, a token that leaks or is exposed carries meaningfully less risk than the older long-lived equivalent, since its usefulness is bounded both in time and in the set of services willing to accept it, directly motivating the shift toward projection as the default mechanism.

Projection Mechanics

Kubelet-Managed Token Generation

The kubelet requests a token from the API server's TokenRequest API on the pod's behalf, mounting it into the pod's filesystem through a projected volume, and this generation process happens transparently as part of normal pod startup rather than requiring any separate Secret object to be pre-created.

Automatic Refresh Before Expiration

The kubelet monitors the projected token's expiration and proactively refreshes it well before it actually expires, replacing the mounted file's contents in place, meaning consuming applications reading the token file at request time should always observe a currently valid value as long as they re-read it rather than caching it indefinitely in memory.

Configuring Token Properties

Expiration Duration

A pod's projected service account token volume can specify an expirationSeconds value controlling how long each generated token remains valid, and configuration management should balance shorter expiration windows, which reduce exposure risk, against increased load on the token refresh mechanism at very short durations.

Audience Scoping

The audience field restricts which services the token is intended to be presented to, and configuration should set this to match the specific external service or API the token is meant to authenticate against, ensuring a token issued for one purpose cannot be inadvertently accepted by an unrelated service expecting a different audience.

Consumption by Workloads

Reading the Token File Directly

Applications consume the projected token by reading it from its mounted file path, typically used to authenticate outbound calls to the Kubernetes API server itself or to external services configured to trust tokens from the cluster's issuer, and consumption code should read the file fresh for each use rather than caching a potentially stale value beyond its refresh cycle.

Interaction With External Identity Federation

Bridging to Cloud Provider IAM

Projected service account tokens are foundational to workload identity federation patterns, where an external cloud provider's identity system is configured to trust tokens issued by the cluster, allowing pods to authenticate to cloud APIs without any long-lived cloud credential ever being stored as a Kubernetes Secret at all.