Skip to main content

More Info:

Verifies automountServiceAccountToken is false for pods that do not call the Kubernetes API. A mounted token is a ready-made credential for an attacker who lands in the pod.

Risk Level

Medium

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Identify noncompliant pods and their owners (run on any machine with kubectl access):
    Save the list; for each line note: NAMESPACE, POD_NAME, OWNER_KIND, OWNER_NAME.
  2. For each workload, decide if it really needs a service account token (run on any machine with kubectl access):
    • Inspect pod spec and image/command:
    • Look for:
      • In-cluster client libraries (e.g., uses KUBERNETES_SERVICE_HOST, kubeconfig, client-go, @kubernetes/client-node).
      • Environment variables, volume mounts, or sidecars that clearly talk to the Kubernetes API.
    • If in doubt, consult the application owner; do not disable token automount until you’re confident it does not call the API.
  3. For standalone Pods that do not need the API, patch the Pod spec (run on any machine with kubectl access):
    Note: If the Pod is controlled by a higher-level object (Deployment, DaemonSet, etc.), this change will be lost when the controller recreates the Pod; in that case, change the controller instead (next step).
  4. For controller-managed workloads that do not need the API, patch the controller spec (run on any machine with kubectl access, pick the right kind per workload): Deployment example:
    DaemonSet example:
    StatefulSet example:
    Job example:
    CronJob example:
  5. (Optional) If multiple pods in a namespace share a ServiceAccount and none of their workloads call the API, you may set it once at the ServiceAccount level instead (run on any machine with kubectl access, and only after confirming no user of the ServiceAccount needs the API):
    Then ensure any workload that does need the token either uses a different ServiceAccount or explicitly sets automountServiceAccountToken: true in its pod template.
  6. Verify remediation (run on any machine with kubectl access):
On any machine with kubectl access:
  1. Identify the pod and owning controller
For each non‑system pod reported as noncompliant, determine its controller (Deployment, StatefulSet, etc.):
Do not edit bare Pods that are managed by a controller; changes will be overwritten. Always patch the controller.
  1. Patch the controller template to disable token automount
Examples (pick the kind that matches the ownerReferences.kind you saw):Deployment
StatefulSet
DaemonSet
If the workload legitimately calls the Kubernetes API, review and skip patching instead of forcing this setting.
  1. Optional: set it on the ServiceAccount instead of each pod
If multiple workloads share a ServiceAccount and none need API access:
  1. Verification
After controllers have rolled out updated pods, verify: