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
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS EKS
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List pods and service accounts that may not need API access (run on any machine with kubectl access):
-
For each pod, determine if it really needs API server access (manual review):
- Inspect the container images and commands:
- Look for:
- Use of
kubectl, client SDKs, or API calls to Kubernetes - RBAC permissions or config mounting kubeconfig/service-account token
- Controllers/operators, admission webhooks, or in-cluster automation
- Use of
- If you are unsure, consult the application owner before disabling token mounting.
- Inspect the container images and commands:
-
For workloads that do NOT need API access, set
automountServiceAccountToken: falseat the pod/workload level (preferred; run on any machine with kubectl access):- For a Deployment (similar for StatefulSet/DaemonSet/Job/CronJob):
Edit
/tmp/deploy.yamland underspec.template.specadd:Then apply: - For a standalone Pod manifest, add the same field under
specand re-create the pod if needed.
- For a Deployment (similar for StatefulSet/DaemonSet/Job/CronJob):
-
Optionally harden ServiceAccounts that should never mount tokens by default (run on any machine with kubectl access):
- For each such ServiceAccount:
Edit
/tmp/sa.yamlto include:undermetadata(same level asname/namespace), then: - Ensure any pods that DO require API access and use this ServiceAccount explicitly set:
in their pod template.
- For each such ServiceAccount:
-
Coordinate and monitor rollout impact:
- Changing pod templates causes pods to be re-created/rolled; schedule changes during a maintenance window if needed.
- After changes, confirm affected pods are running and application functionality is intact:
-
Verification (run on any machine with kubectl access):
Using kubectl
Using kubectl
On any machine with kubectl access:
-
Identify pods and service accounts that do not need API server access
Review workloads and decide which ones truly need to talk to the Kubernetes API. Only those should keep token mounting enabled.
-
Patch individual Pods that do not need the token (ephemeral; also fix their controllers)
-
Configure ServiceAccounts to not mount tokens by default
For service accounts whose workloads do not need API access:Or declaratively, create/update a manifest such as:Apply it: -
Configure controllers (Deployments, DaemonSets, StatefulSets, Jobs, CronJobs) so new pods do not mount tokens
Edit or patch the pod template for each controller whose workloads don’t need API access. Example patch for a Deployment:Example declarative Deployment snippet:Apply it: -
Recreate pods if needed
For controllers, new pods will inherit the new setting automatically after rollout. To force recreation: -
Verification (same logic as the audit)
Automation
Automation

