Zarf can't init when nonroot user is strictly enforced #1921
Labels
Comments
5 tasks
Racer159
added a commit
that referenced
this issue
Jul 28, 2023
## Description On clusters that strictly enforce no root containers via an Admission Controller, they can't determine that a named user isn't 0 in the container. This changes the container to identify the USER by UID and GID so the admission controller can allow this through. Chainguard documents the UID and GID of nonroot https://edu.chainguard.dev/chainguard/chainguard-images/reference/static/overview/#users ## Related Issue Fixes #1921 ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Other (security config, docs update, etc) ## Checklist before merging - [ ] Test, docs, adr added or updated as needed - [ ] [Contributor Guide Steps](https://github.com/defenseunicorns/zarf/blob/main/CONTRIBUTING.md#developer-workflow) followed --------- Co-authored-by: Wayne Starr <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Device and OS: Ubuntu/WSL
App version: 0.28.2
Kubernetes distro being used: RKE2
Other: Admission controller will not permit containers with named USER because it may be set to 0 in image.
Steps to reproduce
zarf initExpected result
Zarf inits
Actual Result
zarf agent deployment fails because the user ID can't be looked up before the container starts.
Visual Proof (screenshots, videos, text, etc)
Relevant code:
https://github.com/defenseunicorns/zarf/blob/main/Dockerfile#L4
I'll submit an PR for this shortly...
The text was updated successfully, but these errors were encountered: