Kubernetes ServiceAccount Token Access

Kubernetes ServiceAccount Token Access covers how a workload obtains, presents, and uses the credential that proves its service account identity to the API server, and the controls available to limit what that credential can do and how long it remains valid. Because a service account token is effectively a bearer credential — anyone who possesses it can act as the service account — the mechanics of how tokens are issued, mounted, and scoped are a primary attack surface in Kubernetes identity security.

How Tokens Reach a Pod

Automatic Volume Mounting

Unless explicitly disabled, the kubelet mounts a service account token into every pod at a well-known path, /var/run/secrets/kubernetes.io/serviceaccount/token, alongside the namespace name and the cluster's CA certificate. Any process running inside the container, including one introduced by a compromised dependency, can read this file and use it to call the API server as that service account.

The projected Volume Mechanism

Modern clusters mount tokens through a projected volume backed by the TokenRequest API rather than a static Secret, giving each token a bounded audience, a bounded expiry, and a binding to the specific pod that requested it.

spec:
  containers:
  - name: app
    volumeMounts:
    - name: sa-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: sa-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          expirationSeconds: 3600
          audience: api.internal

Controlling Access to the Token

Disabling Automount

Setting automountServiceAccountToken: false on either the ServiceAccount object or the individual pod spec prevents the kubelet from mounting any token at all, which is appropriate for any workload that never calls the Kubernetes API — the majority of application pods in most clusters.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: static-web-frontend
automountServiceAccountToken: false

Audience Restriction

Binding a token to a specific audience means the token is only accepted by services that identify themselves as that audience during validation; a token minted for audience: vault will be rejected by the Kubernetes API server itself if the server's own audience is not included, preventing a token intended for one downstream service from being replayed against another.

Expiration and Refresh

Bound tokens default to a one-hour lifetime and are refreshed automatically by the kubelet before expiry, so the token content on disk changes periodically even though the mount path stays constant — applications that cache the token value at startup rather than re-reading the file on each use will eventually authenticate with an expired credential.

Consuming the Token

In-Cluster API Calls

An application inside the cluster typically reads the token file, the namespace file, and the CA certificate to construct an authenticated HTTPS request to https://kubernetes.default.svc, presenting the token as a bearer token in the Authorization header. Kubernetes client libraries automate this pattern through in-cluster configuration helpers.

curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
     -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
     https://kubernetes.default.svc/api/v1/namespaces/payments/pods

External Consumers via TokenReview

External services that want to accept a Kubernetes service account token as proof of identity — a service mesh control plane, a secrets manager, a CI runner — validate it by calling the TokenReview API, which returns whether the token is valid and which service account it belongs to, without the external service needing to know the cluster's signing keys directly.

Risks of Token Exposure

Container Compromise

Because the token file is readable by any process in the container by default, remote code execution inside a single container — through a vulnerable dependency or an injected script — grants the attacker everything the service account is authorized to do, making the scope of that service account's Role the effective ceiling of the breach.

Token Exfiltration and Replay

A stolen bound token remains valid until its expiry regardless of where it is replayed from, since Kubernetes does not by default bind the token to a specific source IP or node; short expirations and audience restriction reduce, but do not eliminate, the value of an exfiltrated token to an attacker operating outside the cluster.

Legacy Non-Expiring Tokens

Secret-backed legacy tokens have no expiry at all, so a single exposure remains exploitable indefinitely until an administrator manually deletes the backing Secret, which is the primary reason clusters have moved to bound, time-limited tokens as the default.