K8s 1.24+ SA Token Projection Verifier

Threat/Impact Level: HIGH | Exploitability/Downtime Risk: HIGH | Time to Fix: 10 mins

TL;DR

• What broke: Kubernetes 1.24 removed auto-generation of long-lived ServiceAccount secret tokens. Pods with automountServiceAccountToken: false or workloads migrated from pre-1.24 clusters have no token volume, causing any in-cluster API call to fail immediately with service account token is not mounted.
• How to fix it: Explicitly define a projected volume with a serviceAccountToken source (and matching volumeMount) on every container that needs API server access. For workloads that need zero API access, confirm automountServiceAccountToken: false is intentional and remove the SDK calls.
• Fast path: Use our Client-Side Sandbox above to auto-refactor your broken Pod/Deployment YAML without sending your configs to a third-party server.

failed to create client: service account token is not mounted

Unable to authenticate the request due to an error:
[invalid bearer token, service account token has been invalidated]

How to Fix It

Basic Fix — Add the Projected Volume

apiVersion: v1
kind: Pod
metadata:
  name: my-controller
spec:
  serviceAccountName: my-sa
- # automountServiceAccountToken: false  <-- was set, or cluster default changed
+ automountServiceAccountToken: false   # keep false; we manage the mount explicitly
  containers:
  - name: app
    image: my-controller:latest
+   volumeMounts:
+   - name: kube-api-access
+     mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+     readOnly: true
+ volumes:
+ - name: kube-api-access
+   projected:
+     defaultMode: 0444
+     sources:
+     - serviceAccountToken:
+         path: token
+         expirationSeconds: 3607
+         audience: https://kubernetes.default.svc.cluster.local
+     - configMap:
+         name: kube-root-ca.crt
+         items:
+         - key: ca.crt
+           path: ca.crt
+     - downwardAPI:
+         items:
+         - path: namespace
+           fieldRef:
+             apiVersion: v1
+             fieldPath: metadata.namespace

Critical: The mountPath must be exactly /var/run/secrets/kubernetes.io/serviceaccount. client-go's rest.InClusterConfig() hardcodes this path. Deviation requires custom token path configuration in the SDK.

Enterprise Best Practice — Least-Privilege SA + Bound Token

# 1. Dedicated, least-privilege ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-controller-sa
  namespace: production
- automountServiceAccountToken: true   # old default, dangerous
+ automountServiceAccountToken: false  # explicit opt-in per pod only
---
# 2. RBAC: grant only what the workload needs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-controller-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
- # DO NOT add: ["secrets"] unless absolutely required
---
# 3. Pod spec with explicit projected volume
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: my-controller-sa
+     automountServiceAccountToken: false
      containers:
      - name: app
+       volumeMounts:
+       - name: kube-api-access-custom
+         mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+         readOnly: true
+     volumes:
+     - name: kube-api-access-custom
+       projected:
+         defaultMode: 0444
+         sources:
+         - serviceAccountToken:
+             path: token
+             expirationSeconds: 3607
+             audience: https://kubernetes.default.svc.cluster.local
+         - configMap:
+             name: kube-root-ca.crt
+             items:
+             - key: ca.crt
+               path: ca.crt
+         - downwardAPI:
+             items:
+             - path: namespace
+               fieldRef:
+                 apiVersion: v1
+                 fieldPath: metadata.namespace

For Vault Agent / IRSA-style workloads: set audience to your Vault JWT auth backend audience string, not the default API server URL.

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

package k8s.projected_sa_token

violation[{"msg": msg}] {
  pod := input.review.object
  pod.kind == "Pod"
  not pod.spec.automountServiceAccountToken == false
  msg := "Pod must set automountServiceAccountToken: false and declare an explicit projected SA token volume."
}

violation[{"msg": msg}] {
  pod := input.review.object
  pod.kind == "Pod"
  pod.spec.automountServiceAccountToken == false
  volumes := {v.name | v := pod.spec.volumes[_]; v.projected}
  mounts := {m.name | m := pod.spec.containers[_].volumeMounts[_]}
  count(volumes & mounts) == 0
  msg := "automountServiceAccountToken is false but no projected SA token volume is mounted."
}

# Run against your Helm-rendered manifests
helm template my-release ./chart | checkov -d - --check CKV_K8S_41
# CKV_K8S_41: Ensure SA tokens are not auto-mounted where not required
# Add custom check for projected volume presence in your .checkov.yaml

# .github/workflows/k8s-validate.yaml
- name: Server-side dry-run against staging cluster
  run: |
    helm template . | kubectl apply --dry-run=server \
      --validate=true \
      -f - \
      --server https://$STAGING_API_SERVER

# Find all non-expiring legacy SA tokens still in cluster
kubectl get secrets -A \
  -o jsonpath='{range .items[?(@.type=="kubernetes.io/service-account-token")]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

# For each found: verify if still referenced, then delete or annotate with expiry