More Info:
Automatically mounting service account tokens into pods that do not call the API server expands the attack surface. Disable token mounting on service accounts and pods that do not need it.Risk Level
MediumAddress
SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify service accounts and pods that auto-mount tokens
- Run on any machine with kubectl access:
- Run on any machine with kubectl access:
-
Select candidates that do not need API access
- Focus on namespaces and workloads that are not control‑plane or infrastructure (e.g., non‑
kube-system, non‑monitoring/ingress). - For each candidate deployment/statefulset/cronjob, inspect its containers for API use:
- Review
/tmp/all-deployments.yaml(or per‑namespace exports) for images and arguments that clearly do not interact with the Kubernetes API (simple stateless apps, frontends, batch jobs with no cluster logic).
- Focus on namespaces and workloads that are not control‑plane or infrastructure (e.g., non‑
-
Confirm with application owners whether API access is required
- For each candidate workload, provide: namespace, resource name, serviceAccountName, and current
automountServiceAccountTokenbehavior (from step 1). - Ask owners if the pod ever: uses in‑cluster config, lists/watches Kubernetes objects, or needs token‑based authentication. If not, mark it safe to disable token mounting.
- For each candidate workload, provide: namespace, resource name, serviceAccountName, and current
-
Disable token auto-mount on service accounts where safe
- For a specific service account confirmed as not needing API access (example: namespace
prod, service accountweb-sa), run: - For new service accounts, ensure manifests include:
- For a specific service account confirmed as not needing API access (example: namespace
-
Override token auto-mount at pod spec level where needed
- For workloads using shared service accounts where some pods need tokens and others do not, set
automountServiceAccountToken: falseon the pod template of the specific workload. Examples: - Persist this in the source manifests/Helm charts so it is not reverted by future deployments.
- For workloads using shared service accounts where some pods need tokens and others do not, set
-
Verify changes cluster-wide
- Re-run the cluster-wide inspection:
- Confirm that pods and service accounts identified as not needing API access now have
automountServiceAccountTokenset tofalseeither on the service account or on the pod spec.
- Re-run the cluster-wide inspection:
Using kubectl
Using kubectl
Using kubectl
1. List all ServiceAccounts and check their token mounting behavior
Run on: any machine with kubectl access./tmp/all-serviceaccounts.yaml and look for automountServiceAccountToken:- If missing on a ServiceAccount, it inherits the namespace/pod default (usually
trueunless overridden). - If explicitly set to
true, that ServiceAccount’s pods will mount tokens by default. - For ServiceAccounts used by workloads that do not need to call the API server,
automountServiceAccountToken: trueor unset is a potential problem; those are candidates to setautomountServiceAccountToken: falseafter review.
- Namespace
- ServiceAccount name
true
2. Find pods that explicitly control token mounting
Run on: any machine with kubectl access./tmp/all-pods.yaml and look for automountServiceAccountToken:- If
automountServiceAccountToken: trueat pod spec level, the pod will mount a token even if the ServiceAccount is more restrictive. - If
automountServiceAccountToken: false, the pod is explicitly protected and will not mount a token. - Pods with
automountServiceAccountToken: truethat do not need to call the API server are potential problems.
- Namespace
- Pod name
- ServiceAccount name
true
3. Identify pods that implicitly mount tokens (likely default behavior)
These pods do not setautomountServiceAccountToken but are still likely getting a token via default behavior.Run on: any machine with kubectl access.- Namespace
- Pod name
- ServiceAccount name
- These pods do not override token mounting; whether they receive a token depends on:
- The ServiceAccount’s
automountServiceAccountTokenfield, or - The namespace/global defaults.
- The ServiceAccount’s
- For workloads that do not need API calls, confirm whether their ServiceAccounts are unnecessarily allowing token mounting.
4. Check if pods actually have token files mounted
This helps confirm effective behavior, independent of spec fields.Run on: any machine with kubectl access.- If you see files such as
token,ca.crt, andnamespaceunder/var/run/secrets/kubernetes.io/serviceaccount, that pod has a service account token mounted. - For pods that do not need to interact with the Kubernetes API, the presence of this directory and token file indicates unnecessary exposure.
5. Verification after making manual changes
After you manually update manifests/ServiceAccounts (outside of this section), re-run:- ServiceAccounts and pods that do not need API access either:
- have
automountServiceAccountToken: false, and/or - no longer show a token directory when checked with the command in step 4.
- have
Automation
Automation
jq block is complex to inline correctly across all clusters; instead, use the following more explicit two-step approach:- Run it from any machine with
kubectlandjqinstalled. - Confirm it completes without errors and prints:
- A table of ServiceAccounts and their
automountServiceAccountToken. - A table of pods showing pod-level and ServiceAccount-level automount values for review.
- A table of ServiceAccounts and their

