Repository navigation
Conversation
…penbao The vault-backup pods set runAsGroup 1000 at POD level, so the only container that does not override it -- the `minio/mc` mirror -- ran a low GID picked for a different image. `mc` bakes no group of its own, so nothing about 1000 was its identity; trivy reported it as KSV-0021 on both the Job and the CronJob. Raise the pod default to the same high 65532 the uid already uses, exactly as vault-config does. The snapshot container keeps restating the openbao image's baked `openbao:x:100:1000` explicitly, so the CKV_K8S_40 annotation now covers only the execution its rationale accounts for instead of one more it does not. fsGroup stays 1000, which is what makes this safe rather than a trade: reading the snapshot never depended on the mirror's PRIMARY gid. Kubernetes adds fsGroup to every container's supplementary groups and sets the setgid bit on the volume, so the 0640 snapshot #3279 established still lands group 1000 and a gid-65532 reader still opens it. vault-config already relies on that mechanism and pinned it there against a paired control (#3258). Measured on this tree with trivy 0.74.0, scan root the repository root and the repo's own flags: 6 misconfigurations -> 4. Both retired findings are the mirror's KSV-0021; the remaining 4 are all the snapshot container's baked 100:1000 pair. Part of #3202
Contributor
✅
|
Contributor
Author
Closing this — the change is not safe as written, and CI was right to stop it.
I justified this change from the So I asserted the two cases were equivalent on the point where they differ. I could not run the experiment that would settle it — reading a 0640 snapshot off that PVC as a gid-65532 process — and the failure mode if I am wrong is the nightly OpenBao backup silently ceasing to mirror. That is not something to ship on reasoning. Withdrawing rather than adjusting the guard. Editing the test to accept 65532 would make the check pass without establishing the property it exists to protect. The finding is real and worth keeping, so it is recorded on #3202 with a concrete next step: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The nightly OpenBao backup pods were running one container under a group ID that was never meant for it. The mirror step uses a different image from the snapshot step, but it inherited the group chosen for OpenBao — so a security scan flagged it, and the existing written justification for that low ID did not actually cover it.
Changes
Give the backup pods the same high, unprivileged group the rest of the pod already uses, so only the container that genuinely needs OpenBao's built-in identity still runs with it.
The two steps still hand the snapshot file between them exactly as before — that sharing never depended on the group being changed here, and the same arrangement is already proven in the sibling job.
Measured effect on this repository's own security scan: 6 findings → 4. The four that remain are the OpenBao image's own built-in identity, which is a separate and already-documented decision.
Part of #3202