Change:
REGISTRY ?= staging-k8s.gcr.io IMAGE = $(REGISTRY)/pause <del> TAG = 3.4.1 </del> <ins> TAG = 3.5 </ins> REV = $(shell git describe --contains --always --match='v*') # Architectures supported: amd64, arm, arm64, ppc64le and s390x

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Run the linux pause container as non-root user Why is this needed: The image is being flagged by scanning tools as not setting a nonroot user in the image definition. While the image is based on scratch which provides some coverage from exploiting vulnerabilities in the image that may escalate privileges it is still a good practice to explicitly set the user in the Dockerfile. There are two options - 1 - Use a base image that can add a user and then copy /etc/passwd and set the user 2 - Switch the image to a base image like distroless/static:nonroot
/assign /sig release /area release-eng dependency security /milestone v1.20 ref: , ,
/sig security
What do you think about this? Please also see the discussion in slack which seems to imply that we are just doing this to "making scanners happy"
cc
Just FYI: There is no need to create a user just to use it with , use a uid is good enough. Example run: Still, works too.
That's good to know. Not sure why I've never tried it or if I had it might not have worked then. Have some places I can clean this up
Agreed that this doesn’t seem like a meaningful security improvement, but it does seem like an opportunity to set a good example of not using root when it isn’t needed. Adding ‘USER :’ to the existing dockerfile (or some similar fix; I picked due to long UNIX tradition) “should” be harmless... but in the past pause image changes have been fraught. do you feel like y’all have good arrangements in place to test a modified pause container rigorously enough to feel good about it?
/cc
Heyho I wanted to check how it is going? The code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each relevant issue has a chance to be considered. As the issue is tagged for 1.20, is it still planned for this release?
I thought I had done everything that needed to be completed for this. Is there anything left? Just let me know.
Do we still need this issue or we can close it?
This change should be made from a security best practices stand point.

I'll leave it up to you guys if you think you want to do it in the future or not.
Can you check this? Shall we move this to 1.21?
Let's keep this open and kick the can to the next milestone. It's still important, but we're out of time for v1.20. /milestone v1.21
I'm not sure if that is too trivial, but I gave the proposal a test-shot in
/unassign /assign
I am not a container security expert. It still seems unclear to me that this is actually a container best practice in this case, this image is not supported to run as a user image, it's an implementation detail of pods, with ~zero user control over how it runs, AIUI. I'm also not sure if this change is a problem for PID reaping? I'd like / someone from SIG security to review these changes, I can weigh in more usefully WRT the build / update process however
I can't come up with a threat model under which making this change prevents an attack, mostly because the behavior of the pause container is so trivial. It seems to be a nice-to-have: it should be harmless, and it helps us set a better example of running containers as non-root when root is not really needed. As far as I understand PID reaping, running pause as non-root shouldn't be a problem even with shareProcessNamespace, because if it were I would expect similar problems in normal Linux with reaping suid children.
Hello! This Issue has not been updated for a long time, so I'd like to check what's the status. The code freeze is starting March 9th, 2021 (about 1 week from now). As the Issue is tagged for 1.21, is it still planned for this release?
any update on this issue or for which milestone it will be targeted?
is not within the v1.21 milestone. I have to continue some tests to ensure that the change is the right move forward.
/milestone clear
I found this thread because I have a Kubernetes controller running some containers as UID . This turns up in an audit for processes running with sketchy UIDs. Please don't ship software that runs processes on UIDs that are not defined users.