Token Projection and Automount

You know that Pods authenticate using ServiceAccounts. But how does the token actually get into the Pod? It is not injected by magic. Kubernetes mounts it as a set of files inside every container’s filesystem, automatically, every time a Pod starts with a ServiceAccount assigned.

What Kubernetes injects

When a Pod is created with a ServiceAccount, Kubernetes automatically adds a projected volume to the Pod spec. That volume is mounted inside every container at a fixed path.

Three files always appear at that mount path. The token file holds the JWT the container uses to authenticate to the API server. The ca.crt file holds the cluster’s certificate authority certificate, which the container uses to verify the API server’s TLS identity. The namespace file holds the name of the namespace the Pod runs in. Together, these three files give a container everything it needs to make authenticated API calls without any additional configuration.

Inspect a running Pod to see this in action.

kubectl get pod app-pod -o yaml

Scroll through the output and find the volumes section near the bottom. You will see an entry of type projected with a serviceAccountToken source. In the containers section, look for volumeMounts. You will find an entry mounting that projected volume at /var/run/secrets/kubernetes.io/serviceaccount.

Describing the projected volume

The describe command shows the same information in a more readable form.

kubectl describe pod app-pod

Under the Volumes section, look for a volume of type Projected. It lists the sources: a ServiceAccountToken entry, a ConfigMap entry for the CA, and a DownwardAPI entry for the namespace name. This is the complete picture of what lands at that mount path.

Why does Kubernetes inject these files automatically instead of requiring the application to fetch a token itself? Because the injection makes applications portable. Any application that knows the standard path can authenticate without environment-specific configuration. The path is the same in every cluster, on every cloud, in this simulated cluster and in a real one.

Disabling automount

Not every Pod needs to call the Kubernetes API. A Pod that serves HTTP traffic, reads from a database, and returns responses to users has no reason to carry API credentials. Leaving the token mounted in such a Pod is an unnecessary risk: if the container is ever compromised, the attacker finds a valid Kubernetes credential ready to use.

Kubernetes lets you disable the automatic token mount at the Pod level with one field.

nano no-token-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: no-token-pod
  namespace: default
spec:
  serviceAccountName: my-app
  automountServiceAccountToken: false
  containers:
  - name: app
    image: nginx:stable

kubectl apply -f no-token-pod.yaml

Now describe the Pod and look at the Volumes section.

kubectl describe pod no-token-pod

You can also set automountServiceAccountToken: false on the ServiceAccount object itself. When set there, it applies as a default for all Pods that use that SA. A Pod can override the SA-level setting by declaring its own automountServiceAccountToken field.

With token projection and automount fully understood, you are ready to apply these mechanics to realistic workload designs. Lesson 04 walks through two practical scenarios where ServiceAccount decisions have direct security consequences.