Repository navigation
Record a re-vendor-durable service-account-token verdict for the KubeVirt and CDI operator bundles #2861
Description
🤖 Generated by the Agentic Engineer
Evidence
#2860 gave six of the eight CKV_K8S_38 workloads an explicit service-account-token
verdict, taking the check from 8 failures to 2. The two left are:
| workload | file |
|---|---|
Deployment.cdi.cdi-operator |
k8s/bases/infrastructure/controllers/cdi/cdi-operator.yaml |
Deployment.kubevirt.virt-operator |
k8s/bases/infrastructure/controllers/kubevirt/kubevirt-operator.yaml |
Both genuinely need the token — they are operator controllers that reconcile their
own CRs through the API server, so the verdict is "required", not "remove it".
Why the mechanism used in #2860 does not work here
Those two files are vendored upstream bundles, re-vendored wholesale from each
release's published asset. .github/renovate.json says so explicitly and requires a
maintainer to re-vendor the full manifest on every bump; AGENTS.md whitelists them
as the sole exception to one-resource-per-file, and scripts/validate-naming.py
lists them by path.
So an annotation written into either file is silently lost on the next re-vendor —
no conflict, no failing check, just a finding that quietly comes back. That is worse
than leaving it, because the next pass re-investigates a question that was already
answered.
The kustomize patches: route these bundles already use does not help either:
measured 2026-07-29, CI scans the raw YAML with checkov's kubernetes framework and
does not run the kustomize framework, so a patch changes the built output without
changing what the scanner reads.
What is needed
A mechanism that records the verdict once and survives re-vendoring. Options worth
weighing (none obviously right, which is why this is separate):
- a repository-level checkov config entry keyed to those two paths, kept next to the
re-vendor instructions; - a post-vendor step that re-applies the annotation as part of the documented
re-vendor procedure, with a check that fails if it is missing; - accepting the two findings and recording them as known residuals against Kubernetes misconfiguration findings are reported but not gated, and nothing else covers them #2787's
count, so the burn-down target is explicit rather than implied.
Acceptance criteria
- Both workloads have a recorded, discoverable verdict that a re-vendor cannot
silently drop. - The chosen mechanism is exercised against a simulated re-vendor (overwrite the
file from upstream, confirm the verdict survives or the build fails loudly). - Kubernetes misconfiguration findings are reported but not gated, and nothing else covers them #2787's residual
CKV_K8S_38count is stated explicitly, whichever way it goes.
Rough size: small. Part of #2845.
Activity
coderabbitai commentedon Jul 29, 2026
🔗 Related PRs
#2399 - feat: accept devantler-tech/actions cosign subjects during the publish-workflow repoint [merged]
#2625 - fix(deploy): synchronize production GHCR pull auth [merged]
#2633 - fix(deploy): verify incoming image on Talos nodes [merged]
#2635 - fix(deploy): reboot stale nodes so containerd adopts refreshed GHCR auth [merged]
#2794 - fix(opencost): restore usage metrics [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 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:💬 Have feedback or questions? Drop into our discord!
devantler commentedon Aug 11, 2026
This is already done — delivered by the vendored-operator annotator (#2899) that landed after this issue was filed. Closing with the evidence rather than leaving it at the head of the security queue, where it misdirects every run that picks the oldest actionable issue.
The issue's premise was that no re-vendor-durable mechanism existed, so an annotation would be silently lost on the next bump. That mechanism now exists and is enforced:
scripts/annotate-vendored-checkov/main.gocarries aDeploymentdisposition for both remaining workloads —cdi-operator(quay.io/kubevirt/cdi-operator) andvirt-operator(quay.io/kubevirt/virt-operator) — each withdeploymentChecks(), which includesCKV_K8S_38, plus a line-number-independentresourceFingerprint.scripts/update-vendored-operators.shreapplies those dispositions on every re-vendor, so a bump cannot drop them — the exact failure this issue was about.ci.yamlrunsscripts/update-vendored-operators.sh --validate-committed, so a hand-edited or drifted bundle fails before merge.CKV_K8S_38disposition in each ofcdi-operator.yamlandkubevirt-operator.yaml.The fingerprint is what makes it durable in the strong sense: a vendor refresh that moves the check to a different container or field fails closed and forces re-review, instead of silently reapplying a stale verdict.
One honest difference from what this issue anticipated. It expected the recorded verdict to read as "the operator genuinely needs the token". The shipped reason is instead "Pinned upstream operator deployment; changes must go through the vendor update path tracked by platform issue 2899." That is a vendor-provenance justification rather than a token-necessity one. Both are defensible and the disposition is reviewed and enforced either way, so I am not treating it as a gap — but if you want the reason to state the token necessity explicitly, reopen and it is a one-line change per bundle in the annotator's
deploymentReason.