Disable Kubernetes service account token automount

The fix

# On the pod (or its ServiceAccount): don't mount a token unless needed
apiVersion: v1
kind: Pod
spec:
  automountServiceAccountToken: false
  # ...

# Or default it off for a whole ServiceAccount:
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: orders
automountServiceAccountToken: false

Why it matters

By default, every pod gets a service account token mounted into it at /var/run/secrets/kubernetes.io/serviceaccount/token. That token authenticates to the API server. Most application pods never use it — they talk to a database and serve HTTP, not the Kubernetes API — but it’s mounted anyway.

That mounted token is a credential sitting inside your workload. If the pod is compromised — an RCE in your app, a malicious dependency, an SSRF that reaches the filesystem — the attacker reads the token and can now query the API server as that service account. What they can do next depends entirely on what the service account’s RBAC grants, and if it’s the default service account with more than it should have, that’s a foothold into the cluster from a single compromised container.

Turning off automount removes the credential from pods that don’t need it. There’s nothing for the attacker to steal, and the pod loses no functionality it was actually using.

The default service account is the specific trap

Every namespace has a default service account, and every pod that doesn’t specify one uses it. So the default SA is mounted into a lot of pods — which means:

• Don’t grant the default service account any permissions. Anything you give it is given to every pod in the namespace that didn’t ask for a specific identity. Keep it empty, and give workloads that need API access their own named service account.
• Set automountServiceAccountToken: false on the default SA in every namespace, so the common case — a pod that never named a service account — gets no token at all.

A workload that genuinely needs API access then opts in: its own service account, its own scoped role, and automount left on for that one.

Where to set it

The setting can go in two places, and the pod spec wins:

• On the ServiceAccount — the default for pods using it.
• On the Pod — overrides the service account’s setting for that pod.

The robust pattern is off-by-default on the service account, on-by-exception on the specific pods that call the API. That’s the same opt-in-to-privilege shape as the rest of this cluster.

Verify it worked

Find pods that have a token mounted — these are the ones carrying a credential:

kubectl get pods -A -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  select([.spec.volumes[]?.name] | any(startswith("kube-api-access"))) |
  "\(.metadata.namespace)/\(.metadata.name) sa=\(.spec.serviceAccountName)"' | head -30

Cross-reference with what those service accounts can do:

kubectl auth can-i --list --as=system:serviceaccount:orders:default

A default service account that can do anything beyond the basics is the finding — combined with automount, every pod in that namespace holds that power.

Check whether the token is actually in a running pod:

kubectl exec -n orders deploy/app -- ls /var/run/secrets/kubernetes.io/serviceaccount/ 2>/dev/null

If that lists a token, the pod can authenticate to the API. If automount is off, the directory isn’t there.

Prove the reduction — from inside a pod with automount off, an API call has no credential:

kubectl exec -n orders deploy/app -- \
  sh -c 'cat /var/run/secrets/kubernetes.io/serviceaccount/token 2>&1' | head -1

Expect “No such file or directory.”

Before you apply this

Disabling automount breaks any pod that actually calls the Kubernetes API — and it’s not always obvious which do. Operators, controllers, service meshes, some logging and monitoring agents, and anything using the in-cluster client library need the token. Turn it off broadly and one of those fails with an authentication error that looks like a bug in the tool.

Find out who uses it before turning it off by default:

# pods whose image or args suggest API usage — a heuristic, not proof
kubectl get pods -A -o json | jq -r '.items[] |
  select(.spec.containers[].command // [] | any(test("kubectl|controller|operator"))) |
  "\(.metadata.namespace)/\(.metadata.name)"'

Better: enable audit logging and see which service accounts actually authenticate to the API. Those are the ones that need automount left on.

Roll it out per namespace, defaulting the default SA off first — that’s the lowest-risk change because well-behaved API-using workloads should have their own named service account, not default. If something breaks after defaulting default off, it was a pod using default for API access, which was itself a smell worth fixing (give it a named SA).

The token change applies to new pods, not running ones — the token is mounted at pod creation. So a workload keeps working until its next restart or redeploy, at which point it loses the token. That delay means the break can surface later than the change, so test with a fresh pod (kubectl rollout restart) rather than assuming the running ones prove anything.

Related

• RBAC least privilege — what a stolen token can do depends on this.
• Restrict privileged containers — reducing how a pod gets compromised in the first place.