Skip to main content

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 server

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. 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: true or notset as appropriate.
  2. 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.yaml and ensure this field is present under metadata (top level of the ServiceAccount):
    • Apply the change:
  3. 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-level automountServiceAccountToken: true so they keep a token:
    • Edit /tmp/deployment-NAMESPACE-DEPLOYMENT_NAME.yaml and, under spec.template.spec, add or set:
    • Apply the change:
    • This will trigger a rollout; existing pods in that workload will be recreated.
  4. 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.
  5. 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:
  6. Verification
    • After changes have rolled out and pods are Running, re-run the audit on any machine with kubectl access:
On any machine with kubectl access:
  1. Identify non-compliant Pods and ServiceAccounts (for review)
  1. Patch a ServiceAccount so that tokens are not mounted by default
Replace default and your-namespace with the specific ServiceAccount and namespace that do not need API access.Declarative example (ServiceAccount manifest):
Apply:
  1. Override at Pod/Workload level where the Pod must NOT mount the token
For individual Pods:
For Deployments (or similar controllers):
  1. Override at Pod/Workload level where the Pod MUST mount the token (explicitly true)
If you have set 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):
Apply with kubectl apply -f ....
  1. Verification (on any machine with kubectl access)
Re-run the benchmark-style audit and review that is_compliant is true for Pods that should not mount the token:

Additional Reading: