security(k8s): three CKV_K8S_40 sites have no UID constraint — raise them or demonstrate one

🤖 Generated by the Agentic Engineer

Evidence

While dispositioning CKV_K8S_40 in #2898, three of the eleven sites turned out to have no
constraint on their UID at all. Each runs below UID 10000 by convention, and nothing in the
manifest requires it:

Site	UID	What it actually touches
`k8s/bases/apps/umami/cron-job.yaml` (CronJob `umami-provision-tenants`)	1001	No volumes and no volumeMounts. Talks to `http://umami-umami.umami.svc.cluster.local` over HTTP, with `readOnlyRootFilesystem: false`.
`k8s/providers/docker/.../minio/job.yaml` (Job `minio-create-bucket`)	1000	`mc` against `http://minio.minio.svc.cluster.local:9000`. Its only volume is a `/tmp/.mc` emptyDir with no `fsGroup`, so any UID can write it.
`k8s/providers/docker/.../minio/deployment.yaml` (Deployment `minio`)	1000	A `/data` emptyDir under `fsGroup: 1000`, which governs group ownership — so the UID itself is not what makes the volume writable.

The first draft of #2898 suppressed all three with reasons asserting shared file ownership. That was
wrong on inspection — none of them shares a volume with anything — so the suppressions were removed
rather than shipped with an invented justification.

Why this is worth doing rather than suppressing

Two of these three run on the local Docker provider, which CI brings up on every run, and the
third only calls an HTTP API. So unlike the rest of the CKV_K8S_40 backlog, this is the subset
where raising the UID is both plausible and verifiable in CI rather than requiring a production
change nobody can exercise.

Smallest useful change

Raise the mc Job first — it has no fsGroup, no shared volume, and the shortest feedback loop.
Then the umami CronJob (no volumes at all), then the MinIO server, which is the only one where the
image's own expectations about /data need checking.

Success signal

CKV_K8S_40 drops from 5 to 2 with the local Docker provider still coming up green in CI, and the
MinIO bucket-creation Job still completing. If a workload turns out to genuinely need its UID, that
is a real answer too — record it as a scoped skip under #2898's convention with the evidence.

Acceptance criteria

Each of the three either runs above UID 10000, or carries a scoped skip whose reason is
demonstrated rather than assumed.
The docker-provider CI run is green, and minio-create-bucket still completes.
.mega-linter.yml's recorded checkov count is refreshed.

Rough size: small. Part of #2787.

🔗 Related PRs

#2344 - fix(security-context): pair pod-level runAsUser with injected runAsGroup (#2292 regression) [merged]
#2437 - fix(cilium): run the cilium-operator as non-root [merged]
#2455 - fix(security): harden containers with read-only root filesystems (Kubescape C-0017) [merged]
#2857 - test(headlamp): measure the user-namespace mapping in prod [merged]
#2860 - security(k8s): record an explicit service-account-token verdict per workload [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!

security(k8s): drop three CKV_K8S_40 skips whose reason was not demon…

security(k8s): drop two more CKV_K8S_40 skips and correct a false Cor…

🤖 Generated by the Agentic Engineer

Two more sites join this bucket — both from review, both measured

#2900's review round found two further CKV_K8S_40 sites whose stated constraint did not hold.
Both are now here rather than suppressed, bringing this issue to five sites.

`k8s/bases/infrastructure/vault-config/job.yaml` (Job `vault-config`, UID 100)

It does not mount the vault-snapshots PVC. Its volume list is entirely emptyDir and
secret; the snapshots volume is an emptyDir that the fetch-snapshot init container fills
from the R2/MinIO mirror — and two comments already in that file say exactly this ("read it
WITHOUT mounting the RWO vault-snapshots PVC").

Nor is 100 an image requirement: the pinned quay.io/openbao/openbao:2.5.3 config reads
User: "<unset>". What is true, read live from the cluster, is that the OpenBao StatefulSet
runs runAsUser: 100, runAsGroup: 1000, fsGroup: 1000 — which is why the two vault-backup jobs,
which do mount the claim, keep their disposition and this one does not.

Open question for whoever picks it up: vault-init and store-keys write to emptyDirs under
fsGroup: 1000, so a higher UID is plausible — but OpenBao's docker-entrypoint.sh may expect
paths owned by 100. That needs exercising, not reasoning.

`k8s/providers/docker/.../coredns/deployment.yaml` (Deployment `coredns`)

CoreDNS does not run as root. The pinned image's own config,
registry.k8s.io/coredns/coredns:v1.14.3@sha256:884b72dd…, reads:

{"User": "nonroot:nonroot", "Entrypoint": ["/coredns"]}

That is the distroless nonroot identity — 65532, already above the 10000 threshold. The manifest
simply sets no runAsUser, so checkov cannot see it. An explicit runAsUser: 65532 would match
what the container already does and clear the check outright.

⚠️ The catch, and why this one is not "just do it". This is the local Docker provider's cluster
DNS, and this repo runs no full-cluster system test on PRs — only static validation and a
Kubescape scan. If the assumption is wrong, the symptom is a cluster with no DNS, not a red check.
The container already grants NET_BIND_SERVICE and the distroless binary carries the capability on
the file, so it should hold — but "should" is the word that makes this need a cluster.

#2900 also corrected the false comment in that file, which had asserted the opposite for as long
as it existed.

Revised scope

Five sites, in ascending order of how much evidence is still needed:

Site	UID	What is still unknown
`minio-create-bucket`	1000	nothing obvious — no `fsGroup`, no shared volume, HTTP only
`umami-provision-tenants`	1001	nothing obvious — no volumes at all, HTTP only
`minio` (server)	1000	whether the image expects `/data` at its own UID
`coredns`	unset (image: 65532)	whether `:53` still binds; needs a cluster
`vault-config`	100	whether OpenBao's entrypoint expects paths owned by 100

docs(k8s): correct a probe comment that restated the refuted UID claim

docs(ci): drop an over-strong RWO claim and fix the CoreDNS issue att…

🤖 Generated by the Agentic Engineer

One premise of this issue is false — acceptance criterion 2 cannot be met as written

This issue argues the MinIO pair is the verifiable subset:

Two of these three run on the local Docker provider, which CI brings up on every run […] this
is the subset where raising the UID is both plausible and verifiable in CI.

MinIO is not brought up by CI. It is an opt-in controller, commented out in the docker
provider's own kustomizations:

k8s/providers/docker/infrastructure/controllers/kustomization.yaml lists # - minio/ under
"Opt-in controllers (uncomment what you want to try locally)", alongside velero/.
k8s/providers/docker/infrastructure/kustomization.yaml likewise keeps vault-backup/ commented
out, noting it "needs controllers/velero + minio".

So acceptance criterion 2 — "the docker-provider CI run is green, and minio-create-bucket still
completes" — cannot be satisfied: that Job never runs in CI. The criterion is unmet rather than
skipped, and #2911 says so instead of implying a live exercise.

What replaced it

Static evidence read from the images themselves rather than reasoned about, which is what the
withdrawn suppressions got wrong:

Site	Image `User`	`/etc/passwd` entry for the UID it ran under	Disposition
`minio/job.yaml` (`mc`)	none (would run as root)	none	raised to 65532
`minio/deployment.yaml`	none (would run as root)	none	raised to 65532
`umami/cron-job.yaml`	`nextjs`	`nextjs:x:1001:65533` — exact match	scoped skip

Both MinIO images are therefore already running under a UID their own image does not know about,
which is the same class of change as raising it. MinIO's entrypoint only switches user when
MINIO_USERNAME and MINIO_GROUPNAME are set; neither is set here, so it takes the plain
exec branch and never looks the UID up.

The umami CronJob went the other way: 1001 turned out to be its image's baked user, so raising it
would break the match the image asks for. That is the one demonstrated constraint of the three, and
it is recorded as a scoped skip rather than a change.

Measured, with the repo's own scripts/megalinter-scan-counts.sh: checkov 37 → 34, CKV_K8S_40
11 → 8. trivy also moved 624 → 620, and that delta is attributable rather than drift — exactly two
targets changed (both MinIO files, 4 → 2 failures each), the other 457 kubernetes targets are
unchanged, and both runs ran the same 118 tests per target, so the rule set did not move.

Residual risk, stated plainly: because CI does not deploy MinIO, a UID mistake here would surface
the first time someone opts the stack in locally, not in this pull request. The blast radius is
bounded to that opt-in local/CI stand-in for R2 — it is not a production workload.

docs(lint): make the CKV_K8S_40 breakdown add up

security(k8s): disposition the vault-config CKV_K8S_40 as image-baked

docs(lint): cite the demonstrated image-baked precedent, not the refu…

Navigation Menu

Repository navigation

security(k8s): three CKV_K8S_40 sites have no UID constraint — raise them or demonstrate one #2901

Evidence

Why this is worth doing rather than suppressing

Smallest useful change

Success signal

Acceptance criteria

Two more sites join this bucket — both from review, both measured

`k8s/bases/infrastructure/vault-config/job.yaml` (Job `vault-config`, UID 100)

`k8s/providers/docker/.../coredns/deployment.yaml` (Deployment `coredns`)

Revised scope

One premise of this issue is false — acceptance criterion 2 cannot be met as written

What replaced it

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

security(k8s): three CKV_K8S_40 sites have no UID constraint — raise them or demonstrate one #2901

Description

Evidence

Why this is worth doing rather than suppressing

Smallest useful change

Success signal

Acceptance criteria

Activity

coderabbitai commented on Aug 2, 2026

devantler commented on Aug 2, 2026

Two more sites join this bucket — both from review, both measured

k8s/bases/infrastructure/vault-config/job.yaml (Job vault-config, UID 100)

k8s/providers/docker/.../coredns/deployment.yaml (Deployment coredns)

Revised scope

devantler commented on Aug 2, 2026

One premise of this issue is false — acceptance criterion 2 cannot be met as written

What replaced it

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

`k8s/bases/infrastructure/vault-config/job.yaml` (Job `vault-config`, UID 100)

`k8s/providers/docker/.../coredns/deployment.yaml` (Deployment `coredns`)