security(k8s): give each workload an explicit service-account-token verdict (CKV_K8S_38)

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

CKV_K8S_38 ("service account tokens are only mounted where necessary") is the second-largest
group in #2787's checkov backlog — 8 of the 42 Kubernetes-framework findings measured on main
2026-07-28:

workload	file
Deployment.kube-system.coredns	k8s/providers/docker/infrastructure/controllers/coredns/deployment.yaml
CronJob.longhorn-system.longhorn-stale-node-cleanup	k8s/providers/hetzner/infrastructure/controllers/longhorn/cron-job-stale-node-cleanup.yaml
Job.openbao.vault-snapshot-init	k8s/bases/infrastructure/vault-backup/job.yaml
CronJob.openbao.vault-snapshot	k8s/bases/infrastructure/vault-backup/cron-job.yaml
Job.openbao.vault-config	k8s/bases/infrastructure/vault-config/job.yaml
Deployment.opencost.opencost-usage-scraper	k8s/bases/infrastructure/opencost/components/usage-scraper/deployment.yaml
Deployment.cdi.cdi-operator	k8s/bases/infrastructure/controllers/cdi/cdi-operator.yaml
Deployment.kubevirt.virt-operator	k8s/bases/infrastructure/controllers/kubevirt/kubevirt-operator.yaml

Why it matters

A mounted service-account token is a credential sitting in the container filesystem. Where the
workload never calls the API server it buys nothing and is simply reachable by anything that gets
code execution in that pod — which is the whole reason the check exists. Kubescape does not cover
this: its own exception CRs disable the pod-security controls cluster-wide, and the Kyverno
pod-security policies match kinds: [Pod] while k8s/ contains no Pod objects.

Why this is NOT a blanket sweep

At least three of the eight legitimately need their token — the KubeVirt and CDI operators are
controllers, and the Longhorn cleanup CronJob acts on nodes through the API. Setting
automountServiceAccountToken: false across all eight would break them. Each workload needs an
individual verdict, and the ones that keep the token need that recorded so the next pass does not
re-litigate it.

What

Per workload, either set automountServiceAccountToken: false on the pod spec, or record in the
manifest why the token is required. Prefer the pod-spec field over the ServiceAccount-level one so
the decision is visible where the workload is defined.

Acceptance criteria

• Every one of the eight workloads above has an explicit verdict: the field set to false, or
  a comment naming the API access that requires it.
• CKV_K8S_38 reports zero remaining findings it can act on, measured with the reproducible
  command from the measurement child.
• Each workload whose token was removed is confirmed still healthy after reconcile — a
  controller that silently loses API access fails quietly.
• No ClusterSecurityException or linter suppression is added; this is fixed at the manifest.

Size: M — eight small diffs plus a per-workload judgement, and the verification is the
expensive half.

Part of #2787. Depends on the measurement child for its before/after count.

[coderabbitai]

🔗 Related PRs

#2370 - fix(autoscaling): break the DaemonSet-VPA node ratchet; keep Longhorn storage off autoscale nodes [merged]
#2440 - fix(security): make C-0002 exec-into-container exception effective for infra controllers [merged]
#2455 - fix(security): harden containers with read-only root filesystems (Kubescape C-0017) [merged]
#2474 - refactor: name patch fragments by intent and codify patch naming rules [merged]
#2794 - fix(opencost): restore usage metrics [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Agentic Engineer

Measured: it is not "at least three of the eight" — all eight need the token

This issue's framing was that some of the eight are legitimate and the rest are
removable. Checked each against what the workload actually does, and none of the
eight can drop the token:

workload	why the token is required	evidence
coredns	serves cluster DNS by watching Services/Endpoints	Corefile enables the kubernetes cluster.local plugin
longhorn-stale-node-cleanup	reconciles Longhorn Node CRs	script is kubectl throughout
vault-snapshot-init	logs into OpenBao via Kubernetes auth	reads /var/run/secrets/kubernetes.io/serviceaccount/token as the jwt
vault-snapshot	same	same
vault-config	writes the openbao-unseal Secret	kubectl create secret … | kubectl apply -f -
opencost-usage-scraper	kubernetes_sd + authenticated kubelet scraping	already documented in-manifest
cdi-operator	operator reconciling its own CRs	upstream controller
virt-operator	same	upstream controller

So the deliverable is not "set the field to false where possible" — it is
recording the verdict so the next pass does not re-litigate it, which is what
the second half of the acceptance criteria asks for.

The skip mechanism, measured rather than assumed

Two forms look equivalent and are not:

• checkov.io/skip1: CKV_K8S_38=<reason> on the resource's metadata.annotations
  → SKIPPED, with the reason recorded in the report.
• a # checkov:skip=CKV_K8S_38: <reason> YAML comment → still FAILED. Silently
  a no-op; it looks applied and does nothing.

Verified on a three-case fixture (annotation / comment / automountServiceAccountToken: false), which also confirms false is the only value that passes the check —
true fails even with a rationale comment, which is why the six that need the token
require a scoped skip rather than just documentation.

Delivered in #2860 — six of eight

CKV_K8S_38 on k8s/: 8 failures → 2, the remaining two being the vendored
KubeVirt/CDI bundles. Whole-tree control: kubernetes-framework failures 43 → 37, and
the diff of failure identities is exactly those six with no new failure anywhere.
Ablation: dropping one annotation returns exactly that resource to FAILED and leaves
the other five skipped. Both overlays validate (ksail workload validate, 556 files,
exit 0).

One drift worth noting for #2787's tracking: the whole-tree kubernetes-framework
baseline is 43 today, not the 42 recorded on 2026-07-28.

The vendored-bundle half needs a mechanism that survives re-vendoring — an annotation
written into either file is silently dropped on the next bump — so it is filed as
#2861 rather than guessed at here. This issue stays open until that lands.

[devantler]

🤖 Generated by the Agentic Engineer

#2860 merged — six of eight delivered, verified on main

Merged 16:55:42Z (e8fd1da3). Re-measured against merged main, not inferred from the PR:

CKV_K8S_38 on k8s/ — 6 SKIPPED, each carrying its reason, 2 FAILED:

• coredns, longhorn-stale-node-cleanup, vault-snapshot-init, vault-snapshot,
  vault-config, opencost-usage-scraper → dispositioned
• cdi-operator, virt-operator → the vendored bundles, tracked in Record a re-vendor-durable service-account-token verdict for the KubeVirt and CDI operator bundles #2861

One correction worth carrying forward

The issue asks for the pod-spec field over a comment, "so the decision is visible where
the workload is defined". That is right in principle and does not survive contact with
the second scanner: an explicit automountServiceAccountToken: true trips Kubescape
C-0034, and it buys nothing behaviourally — true is the value these pods already
got by default. On the openbao workloads the verdict is therefore recorded in the
comment, with the field left implicit; coredns keeps the explicit field because
kube-system is inside the existing C-0034 exception.

Also measured and worth not re-deriving: C-0034's own remediation text — disable
auto-mount on the ServiceAccount, opt in per pod — cleared nothing, and is unsafe on
its own, since SA-level false without a pod-level true leaves these pods with no
token and breaks their OpenBao Kubernetes-auth login.

This issue stays open until #2861 lands.