Repository navigation
First-party workloads run with unpinned or low UID/GID, and trivy cannot gate k8s/ until they are dispositioned #3232
Description
🤖 Generated by the Agentic Engineer
Evidence
Measured on main @2199c715 with scripts/megalinter-scan-counts.sh (repo root, per the scan-root rule): trivy reports 36 misconfigurations across 14 targets on k8s/, 0 CRITICAL, 0 HIGH.
KSV-0020 (UID <= 10000) and KSV-0021 (GID <= 10000) are 20 of those 36 — the largest family by a wide margin. #3231 dispositions the 4 that sit on the two vendored VM-operator bundles, where the omission is upstream's and the workload never reaches production. That leaves 16 on workloads this repository authors:
| File | KSV-0020 | KSV-0021 |
|---|---|---|
k8s/bases/apps/umami/cron-job.yaml |
1 | 1 |
k8s/bases/infrastructure/vault-backup/cron-job.yaml |
2 | 2 |
k8s/bases/infrastructure/vault-backup/job.yaml |
2 | 2 |
k8s/bases/infrastructure/vault-config/job.yaml |
2 | 4 |
Why this is not a blanket bump
The 16 are two different situations, and only inspection tells them apart:
umami/cron-job.yamlpins a low UID deliberately —runAsUser: 1001,runAsGroup: 1001,fsGroup: 1001. Raising it above 10000 only works if nothing in the image's filesystem is owned by 1001.- The vault jobs pin nothing — they set
runAsNonRoot: trueand omitrunAsUser/runAsGroupentirely, so what trivy reads as "low" is actually absent. The kubelet still keeps them off root. vault-config/job.yamlis already known to be image-baked. It carries a scopedcheckov.io/skip2recording exactly that, and setsrunAsUserper container instead. That precedent probably decides several of these, but it should be confirmed per image rather than assumed.
Setting a UID a container image cannot actually run as fails at start-up, and these are backup and provisioning jobs — a silent failure here is a backup that stops happening. So each image needs its ownership checked before its manifest moves.
Expected behaviour
Every first-party KSV-0020/0021 finding is either fixed at the manifest (UID/GID above 10000, verified to still run) or carries a scoped .trivyignore.yaml disposition naming the image constraint that makes it irreducible.
Acceptance criteria
- Each of the four files above is resolved as fix-or-disposition, with the per-image reason stated.
- trivy's KSV-0020 and KSV-0021 counts on
k8s/reach 0. - Any disposition added is asserted by a boundary test, so it fails the build if it widens — the pattern
scripts/tests/test-trivyignore-vendored-operator-boundary.shalready uses. - Each workload is verified to still run after a UID change, not merely to pass the scan.
Rough size: medium — four files, but each needs its image checked.
Part of #2787. Blocks removing REPOSITORY_TRIVY from DISABLE_ERRORS_LINTERS, together with the remaining 16 findings in other check families.
Activity
coderabbitai commentedon Aug 19, 2026
🔗 Related PRs
#3116 - fix(umami): run the tenant-provisioning container on a read-only root filesystem [merged]
#3203 - security(vault-backup): disposition the last two CKV_K8S_40 findings as one deferred exception [merged]
#3227 - security(k8s): disposition the first-party RBAC trivy findings [merged]
#3216 - security(trivy): declare the trusted registries so KSV-0125 gates instead of noises [merged]
#3210 - security(k8s): disposition vendored KubeVirt and CDI operator RBAC as a class [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 19, 2026
Closing as a duplicate of #3221, which was filed 2026-08-18 and covers the same 16 first-party KSV-0020/0021 findings across the same four files, with the same core reasoning about image-baked UIDs.
My fault for not checking this issue's existing sub-issues before filing. The two measurements agree exactly (vault-config 6, vault-backup cron-job 4, vault-backup job 4, umami 2), which is at least a useful independent confirmation.
The parts of this issue that were not already in #3221 — a correction to one of its premises, and two additional acceptance criteria — are posted to #3221 rather than lost here.