Kubernetes service-account token mounting deserves an explicit opt-out

Every Kubernetes Pod receives credentials for its assigned ServiceAccount by default. The token is convenient for controllers and operators, but many application Pods never call the Kubernetes API. Leaving an API credential in those containers increases the value of a workload compromise.

The default is useful and broad

The Kubernetes documentation says the kubelet provides a Pod with credentials for the default ServiceAccount unless the Pod selects another one. It also documents automountServiceAccountToken: false on a ServiceAccount or a Pod. The Pod-level setting takes precedence when both are present.

The token is not a generic password for the application. It authenticates to the Kubernetes API as the ServiceAccount, subject to RBAC and admission policy. If the application does not need that identity, the token is an unnecessary credential in the container filesystem.

Modern Kubernetes clusters usually project a short-lived, audience-scoped token instead of the old long-lived Secret token. That improves lifecycle management, but it does not make the token harmless. It can still be read by a process in the Pod and used until it expires if the attacker can reach the API server.

Why teams leave it mounted

The default is easy to inherit. A team copies a Deployment from another service, the Pod starts, and nobody checks whether the application reads /var/run/secrets/kubernetes.io/serviceaccount/token. Operators may also use the mounted token for a sidecar, an init container, or a debug command that is not part of the application design.

ServiceAccount-level settings can hide the issue. A namespace may set automountServiceAccountToken: false on the default account while a workload explicitly selects a privileged account for an unrelated reason. The Pod still gets the selected account's credential. The manifest review needs to consider the effective ServiceAccount and the effective Pod field.

Some workloads use the API for legitimate discovery, custom resources, or operator behavior. Those workloads should keep a narrowly scoped ServiceAccount and use the token explicitly. The goal is not to remove every token. It is to make the token an intentional dependency.

Test the effective mount

Start from the rendered Pod spec rather than the Helm values:

kubectl get pod -n app example-pod -o yaml

Inspect spec.serviceAccountName and spec.automountServiceAccountToken. Then check inside a disposable Pod:

kubectl exec -n app example-pod -- \
  sh -c 'test -f /var/run/secrets/kubernetes.io/serviceaccount/token && echo mounted || echo absent'

Do not use a production application Pod for the test when a read-only diagnostic workload can answer the same question. Check every container and init container that might need the token. A sidecar that requires API access should have its own reviewed identity and permission set.

If the application needs a token only for a small task, use the TokenRequest API or a projected token with the required audience and expiration. That is more explicit than enabling the default mount for the entire Pod. Apply the same decision to CronJobs, batch jobs, and jobs created by CI controllers.

Roll out without breaking controllers

Create a list of workloads that call the API. Include the verb, resource, namespace, and audience they need. Workloads with no calls can move to automountServiceAccountToken: false. Workloads with calls should use a dedicated ServiceAccount whose RBAC can be reviewed.

Canary the change in one namespace and watch for authentication failures, informer startup errors, and failed health checks. A workload may hide its API dependency in a startup library or an admission controller. Log the ServiceAccount name with authentication errors so the failure is easy to attribute.

Use admission policy to flag Pods that mount a token without an approved annotation, but do not make the policy so broad that platform components cannot operate. The control should distinguish application workloads from controllers.

The token mount is a small manifest field with a large blast-radius implication. Making it explicit gives the team a better answer to two questions: which workloads can talk to the API, and which credentials disappear when a container is compromised?

References

• Kubernetes documentation, Service Accounts
• Kubernetes documentation, Configure Service Accounts for Pods
• Kubernetes documentation, Managing Service Accounts