security(k8s): run the userns-longhorn-smoke probe at a high UID - #3047
Merged
Conversation
Raise the probe's runAsUser/runAsGroup/fsGroup from 1000 to 65532 so it clears checkov CKV_K8S_40, which passes from 10000 up. The UID is not what the Job measures: /proc/self/uid_map describes the pod's user namespace and reads identically for every process in it whatever UID that process has, so the uid_host_start > 0 acceptance condition is unchanged. The UID reaches the sentinel only as text and the round-trip assertions grep for the init-user=/main-user= keys, never their values. fsGroup moves with runAsGroup because that, not the UID, is what makes the Longhorn volume writable. Measured with the repository's own reproduction: checkov 11 -> 10 failed, and passed 1852 -> 1853, so the finding is resolved rather than suppressed. CKV_K8S_40 drops from 4 sites to the 3 vault-snapshots writers, which #2904 holds back for a watched window. Correct the two figures in .mega-linter.yml that had drifted, as that file instructs any slice to do. Part of #2787 Part of #2904
Contributor
✅
|
Contributor
Author
@coderabbitai review |
Contributor
|
✅ Action performedReview finished.
|
Contributor
Author
Verification recordProgrammatic. Reproduced with the repository's own
The passed count rising by one is the control that matters: the finding moved to passed, so it is Both overlays still build ( User evaluation — stated plainly, because it is not a runtime exercise. This Job is commented
One correction found in self-review and fixed before this comment: an earlier draft of the config |
Contributor
📝 WalkthroughWalkthroughThe Longhorn smoke Job now runs its pod, init container, and main container with UID and GID Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
devantler
marked this pull request as ready for review
August 10, 2026 00:47
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Aug 10, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Aug 10, 2026
Contributor
Author
Evicted from the merge queue twice by the same root cause — and it is not this PR. Both
The The lease is orphaned, on three independent lines of evidence:
The holder identity is composed as Recovery is deliberately manual by design, and clearing it is a cluster mutation outside this No action needed on this PR itself: its own required checks are green and it is |
5 tasks
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
1 participant
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.
Why
The Kubernetes misconfiguration backlog (#2787) is what keeps checkov and trivy reporting-only
instead of gating, so every finding cleared is a step toward turning that gate back on. This clears
one of the ten checkov findings left.
It is the safe one to take unattended. #2904 splits the remaining
CKV_K8S_40sites into theproduction
vault-snapshotswriters — which share a volume, touch the disaster-recovery restorepath, and need a watched window — and this smoke probe, which is commented out of its kustomization
and does not deploy at all.
What
The probe now runs under a high user ID, which is what the check asks for. Its actual subject is the
user-namespace mapping, not the identity it runs as, so the proof it performs is unchanged.
Measured with the repository's own reproduction script: checkov goes from 11 findings to 10, and the
passing count rises by one — so the finding is genuinely resolved, not hidden behind a suppression.
Two figures in the linter config had drifted from reality and are corrected, which that file asks
any change here to do.
No production workload changes.
Part of #2787
Part of #2904