Skip to main content

More Info:

Pods and service accounts that do not call the API server should not mount service account tokens, reducing the credentials exposed in the workload.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify non-compliant Pods and their ServiceAccounts
    • Run on: any machine with kubectl access
    • Review the output and decide which workloads truly need API server access. Only those should continue to mount tokens.
  2. For Pods that do NOT need API access but MUST keep using their current ServiceAccount
    • Run on: any machine with kubectl access
    • For each such Pod, edit the controller that creates it (Deployment/StatefulSet/DaemonSet/CronJob/Job) and set spec.template.spec.automountServiceAccountToken: false. Example for a Deployment:
    • Add or update under spec.template.spec:
    • Save and exit; the Pods will be recreated automatically without mounting tokens.
  3. For ServiceAccounts used ONLY by Pods that do NOT need API access
    • Run on: any machine with kubectl access
    • Edit the ServiceAccount to disable token automounting by default:
    • Add or update at top-level of the ServiceAccount spec:
    • This makes all Pods using this ServiceAccount compliant as long as their Pod spec does not override with true.
  4. For ServiceAccounts shared by Pods that DO and DO NOT need API access
    • Run on: any machine with kubectl access
    • Keep the ServiceAccount as-is (or even automountServiceAccountToken: true if needed), and control per-Pod behavior:
      • For Pods that need API access: no change required (they may inherit the default).
      • For Pods that must NOT mount tokens: set spec.template.spec.automountServiceAccountToken: false as in Step 2 so the Pod-level value overrides the ServiceAccount.
  5. For static workload manifests managed via files (Git/IaC) rather than kubectl edit
    • Run on: any machine with kubectl access and repo access
    • Locate the YAML manifest for each non-compliant workload and modify it directly:
      • In every ServiceAccount that should not mount tokens by default:
      • In every Pod template that must explicitly disable mounting:
    • Apply the updated manifests:
  6. Verify remediation
    • Run on: any machine with kubectl access
On any machine with kubectl access:
  1. Identify pods and service accounts to change (those that do not need API access but are non‑compliant):
Review the listed workloads and confirm they do not require Kubernetes API access before changing anything.
  1. Patch ServiceAccounts that should never auto‑mount tokens (declarative via kubectl patch):
  1. For pods created by controllers (Deployments, DaemonSets, StatefulSets, Jobs, CronJobs), set automountServiceAccountToken: false in the pod template. Example for a Deployment:
Example for a DaemonSet:
Example for a StatefulSet:
Example for a Job:
Example for a CronJob:
These patches will roll out new pods with tokens not mounted.
  1. For standalone Pods defined directly (no controller), edit the pod manifest and re‑create it, or patch if acceptable (note: patching an existing running Pod will not change already mounted volumes). Recommended approach:
  • Export, edit, and re‑create:
Edit /tmp/my-pod.yaml so the pod spec contains:
Then delete and recreate:
  1. Verification (same logic as audit):