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

  • 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

Manual Steps

  1. List pods and service accounts that may not need API access (run on any machine with kubectl access):
  2. 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
    • If you are unsure, consult the application owner before disabling token mounting.
  3. For workloads that do NOT need API access, set automountServiceAccountToken: false at the pod/workload level (preferred; run on any machine with kubectl access):
    • For a Deployment (similar for StatefulSet/DaemonSet/Job/CronJob):
      Edit /tmp/deploy.yaml and under spec.template.spec add:
      Then apply:
    • For a standalone Pod manifest, add the same field under spec and re-create the pod if needed.
  4. Optionally harden ServiceAccounts that should never mount tokens by default (run on any machine with kubectl access):
    • For each such ServiceAccount:
      Edit /tmp/sa.yaml to include:
      under metadata (same level as name/namespace), then:
    • Ensure any pods that DO require API access and use this ServiceAccount explicitly set:
      in their pod template.
  5. 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:
  6. Verification (run on any machine with kubectl access):
On any machine with kubectl access:
  1. 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.
  2. Patch individual Pods that do not need the token (ephemeral; also fix their controllers)
  3. 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:
  4. 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:
  5. Recreate pods if needed
    For controllers, new pods will inherit the new setting automatically after rollout. To force recreation:
  6. Verification (same logic as the audit)

Additional Reading: