fix(common): honor uid per entry in the containers list - #261
Open
henrik242 wants to merge 1 commit into
Open
Conversation
henrik242
force-pushed
the
fix/containers-uid
branch
from
August 10, 2026 09:50
7f9d88f to
7ab818a
Compare
uid on containers[] entries was ignored; those pods always ran as 1000. Each entry now renders runAsUser/runAsGroup, and the pod-level securityContext follows the first entry's uid. Schema rejects uid 0, which runAsNonRoot has always made unschedulable.
henrik242
force-pushed
the
fix/containers-uid
branch
from
August 14, 2026 11:28
7ab818a to
edb8b29
Compare
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.
uidset oncontainers[]entries was silently ignored. The pod securityContext read onlycontainer.uid(singular) and fell back to the default1000, and the per-containersecurityContext set no
runAsUserat all, so pods using thecontainerslist always ran asuid
1000. Sinceuidis schema-valid on every entry, this failed silently rather than erroring.Each entry's
uidnow renders asrunAsUser/runAsGroupon that container, and the pod-levelsecurityContext (including
fsGroup) follows the first entry'suid, falling back tocontainer.uid. Same fix incron.yaml. The schema now rejectsuid: 0, whichrunAsNonRoot: truehas always made unschedulable.Single-container charts are unaffected. Rendered against all five
fixture/helmvalues files,the only change is that each container's securityContext now spells out
runAsUser/runAsGroup: 1000, matching the pod-level value that already applied.entur/gha-helm#121 currently works around this by duplicating
container.uid: 101next tocontainers[0].uid: 101, with a comment to drop it "once this fixture's common dependency isbumped to a release that includes that fix". Worth landing before the v2.0.0 GA tag so the uid
change ships inside the major rather than as a later patch bump.
Note: helm-docs also corrected the
charts/common/README.mdversion badge from2.0.0to2.0.0-rc-1. That is pre-existing drift againstChart.yaml, not a change from this PR.