How to stop Kubernetes from mounting a service account token in a pod

To stop Kubernetes injecting an API credential into a pod, set automountServiceAccountToken to false, either on the pod or on its ServiceAccount. A pod-level setting overrides the service account setting, so workloads that do need a token can still opt back in.

Why bother

By default, a pod gets the token of its ServiceAccount. If the application never talks to the Kubernetes API, that token is an unused credential sitting in the container. If an attacker gets code execution, it is one more thing to steal. The RBAC good practices page lists disabling automatic mounting under hardening, and also says pods should not use service accounts with powerful permissions unless required.

Option one: on the pod

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  containers:
  - name: app
    image: nginx

This overrides whatever the ServiceAccount says, in both directions. A pod can turn mounting off even if the account allows it, and turn it on even if the account disables it.

Option two: on the ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
  namespace: default
automountServiceAccountToken: false

Pods that use this account get no injected token unless they set the field to true themselves. The docs say you can do the same for the namespace's default ServiceAccount.

Which one to choose

Set it on the ServiceAccount when the identity is for workloads that should never call the API, and set it on the pod when a single workload needs an exception. For a namespace full of ordinary web services, turn it off on the default account and create named accounts only for the few controllers that need API access.

Checking the result

Look at the pod spec and then exec in only if your policy allows it. The mount path is the standard service account directory, and it should not exist when mounting is off.

kubectl get pod app -o jsonpath='{.spec.automountServiceAccountToken}'

An empty answer means the pod did not set the field, so the ServiceAccount's setting applies.

Add a guardrail

This is a natural fit for an admission rule: warn or deny pods that leave the field unset and use the default account. Our post on rolling out admission policy with warn and audit first shows how to introduce it without breaking deployments.

Safeguard can check manifests in pull requests through policies and gates, so a missing setting is caught before merge. It does not change running pods.

What can still go wrong

Turning off mounting removes the default credential. It does not stop a workload from being given a token another way, for example through a projected volume you add yourself, or a Secret holding a token. Search your manifests for those as well. Also keep in mind that people who can create pods in the namespace can choose which service account a pod runs as, so the mount setting is one layer, not the whole defense.

Quick check

Sources

• Configure Service Accounts and service account concepts, Kubernetes docs
• Role Based Access Control Good Practices, Kubernetes docs

Last reviewed: 19 October 2026.