Skip to main content

More Info:

Automatically mounting service account tokens into pods that do not call the API server expands the attack surface. Disable token mounting on service accounts and pods that do not need it.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify service accounts and pods that auto-mount tokens
    • Run on any machine with kubectl access:
  2. Select candidates that do not need API access
    • Focus on namespaces and workloads that are not control‑plane or infrastructure (e.g., non‑kube-system, non‑monitoring/ingress).
    • For each candidate deployment/statefulset/cronjob, inspect its containers for API use:
    • Review /tmp/all-deployments.yaml (or per‑namespace exports) for images and arguments that clearly do not interact with the Kubernetes API (simple stateless apps, frontends, batch jobs with no cluster logic).
  3. Confirm with application owners whether API access is required
    • For each candidate workload, provide: namespace, resource name, serviceAccountName, and current automountServiceAccountToken behavior (from step 1).
    • Ask owners if the pod ever: uses in‑cluster config, lists/watches Kubernetes objects, or needs token‑based authentication. If not, mark it safe to disable token mounting.
  4. Disable token auto-mount on service accounts where safe
    • For a specific service account confirmed as not needing API access (example: namespace prod, service account web-sa), run:
    • For new service accounts, ensure manifests include:
  5. Override token auto-mount at pod spec level where needed
    • For workloads using shared service accounts where some pods need tokens and others do not, set automountServiceAccountToken: false on the pod template of the specific workload. Examples:
    • Persist this in the source manifests/Helm charts so it is not reverted by future deployments.
  6. Verify changes cluster-wide
    • Re-run the cluster-wide inspection:
    • Confirm that pods and service accounts identified as not needing API access now have automountServiceAccountToken set to false either on the service account or on the pod spec.

Using kubectl

1. List all ServiceAccounts and check their token mounting behavior

Run on: any machine with kubectl access.
Review /tmp/all-serviceaccounts.yaml and look for automountServiceAccountToken:
  • If missing on a ServiceAccount, it inherits the namespace/pod default (usually true unless overridden).
  • If explicitly set to true, that ServiceAccount’s pods will mount tokens by default.
  • For ServiceAccounts used by workloads that do not need to call the API server, automountServiceAccountToken: true or unset is a potential problem; those are candidates to set automountServiceAccountToken: false after review.
To focus on ServiceAccounts that explicitly enable token mounting:
Output columns:
  1. Namespace
  2. ServiceAccount name
  3. true
Each line represents a ServiceAccount that forces token mounting; verify whether its pods truly need API access.

2. Find pods that explicitly control token mounting

Run on: any machine with kubectl access.
Inspect /tmp/all-pods.yaml and look for automountServiceAccountToken:
  • If automountServiceAccountToken: true at pod spec level, the pod will mount a token even if the ServiceAccount is more restrictive.
  • If automountServiceAccountToken: false, the pod is explicitly protected and will not mount a token.
  • Pods with automountServiceAccountToken: true that do not need to call the API server are potential problems.
To list pods that explicitly enable token mounting:
Output columns:
  1. Namespace
  2. Pod name
  3. ServiceAccount name
  4. true
Each line is a pod that forces token mounting; review the workload purpose to decide if that is justified.

3. Identify pods that implicitly mount tokens (likely default behavior)

These pods do not set automountServiceAccountToken but are still likely getting a token via default behavior.Run on: any machine with kubectl access.
Output columns:
  1. Namespace
  2. Pod name
  3. ServiceAccount name
Interpretation:
  • These pods do not override token mounting; whether they receive a token depends on:
    • The ServiceAccount’s automountServiceAccountToken field, or
    • The namespace/global defaults.
  • For workloads that do not need API calls, confirm whether their ServiceAccounts are unnecessarily allowing token mounting.

4. Check if pods actually have token files mounted

This helps confirm effective behavior, independent of spec fields.Run on: any machine with kubectl access.
Interpretation:
  • If you see files such as token, ca.crt, and namespace under /var/run/secrets/kubernetes.io/serviceaccount, that pod has a service account token mounted.
  • For pods that do not need to interact with the Kubernetes API, the presence of this directory and token file indicates unnecessary exposure.

5. Verification after making manual changes

After you manually update manifests/ServiceAccounts (outside of this section), re-run:
Confirm that:
  • ServiceAccounts and pods that do not need API access either:
    • have automountServiceAccountToken: false, and/or
    • no longer show a token directory when checked with the command in step 4.
The above jq block is complex to inline correctly across all clusters; instead, use the following more explicit two-step approach:
To verify the script:
  • Run it from any machine with kubectl and jq installed.
  • Confirm it completes without errors and prints:
    • A table of ServiceAccounts and their automountServiceAccountToken.
    • A table of pods showing pod-level and ServiceAccount-level automount values for review.