More Info:
Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API serverRisk Level
MediumAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify pods and service accounts that are not compliant
- Run on any machine with kubectl access:
- Review the non-compliant pods and decide which workloads actually need API server access. Only those should keep
automountServiceAccountToken: trueornotsetas appropriate.
- Run on any machine with kubectl access:
-
Disable token automount at the ServiceAccount level where API access is not needed
- For each namespace and service account that should not get tokens by default, run on any machine with kubectl access:
- Edit
/tmp/serviceaccount-NAMESPACE-SERVICEACCOUNT.yamland ensure this field is present undermetadata(top level of the ServiceAccount): - Apply the change:
- For each namespace and service account that should not get tokens by default, run on any machine with kubectl access:
-
Override specific Pods to allow token mount when needed
- For workloads that truly require API access and use a ServiceAccount you have set to
automountServiceAccountToken: false, explicitly set pod-levelautomountServiceAccountToken: trueso they keep a token: - Edit
/tmp/deployment-NAMESPACE-DEPLOYMENT_NAME.yamland, underspec.template.spec, add or set: - Apply the change:
- This will trigger a rollout; existing pods in that workload will be recreated.
- For workloads that truly require API access and use a ServiceAccount you have set to
-
Disable token automount at the Pod level for workloads that do not need API access
- For each non-compliant workload you determined does not need API access, edit the controller manifest (Deployment/StatefulSet/DaemonSet/CronJob, etc.):
- Under
spec.template.spec, add or set: - Apply the manifest:
- This will recreate pods for that workload without mounting service account tokens.
- For each non-compliant workload you determined does not need API access, edit the controller manifest (Deployment/StatefulSet/DaemonSet/CronJob, etc.):
-
For bare Pods (not managed by a controller), recreate them with the correct setting
- Export and edit the Pod definition:
- Remove
metadata.resourceVersion,metadata.uid,metadata.creationTimestamp,status, and other server-generated fields from the file. - Under
spec, set: - Delete and recreate the Pod:
- Export and edit the Pod definition:
-
Verification
- After changes have rolled out and pods are Running, re-run the audit on any machine with kubectl access:
- After changes have rolled out and pods are Running, re-run the audit on any machine with kubectl access:
Using kubectl
Using kubectl
On any machine with kubectl access:Replace Apply:For Deployments (or similar controllers):Apply with
- Identify non-compliant Pods and ServiceAccounts (for review)
- Patch a ServiceAccount so that tokens are not mounted by default
default and your-namespace with the specific ServiceAccount and namespace that do not need API access.Declarative example (ServiceAccount manifest):- Override at Pod/Workload level where the Pod must NOT mount the token
- Override at Pod/Workload level where the Pod MUST mount the token (explicitly true)
automountServiceAccountToken: false on a ServiceAccount but a particular Pod using it needs API access, set it to true in the Pod spec (Pod takes precedence):kubectl apply -f ....- Verification (on any machine with kubectl access)
is_compliant is true for Pods that should not mount the token:Automation
Automation

