-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: define user id and group instead of name in the Dockerfile #79
feat: define user id and group instead of name in the Dockerfile #79
Conversation
@tianon @yosifkit @blar @ncopa @michael-k |
Thanks for the contribution! I'd honestly rather not maintain this UID explicitly like this, especially since there's no functional difference between the two when actually running the image (and one is distinctly more user-friendly to read than the other). 😬 There are a few options here that don't require us to make/maintain any changes to the images:
|
Hi @tianon, Thank you for the reply. Following some comments inline. I hope that the following info can show you why this silly, nit change is important and it can persuade you to support this change and help us out :-)
We do this in the image already, see:
That is not true. From Docker Docs
From: https://docs.docker.com/engine/reference/builder/#user NOTE: Therefore because the container user is always a member of the root group, the container user can read and write these files. From Dockefile best practices https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ On Kubernetes (>= 1.24) you can check If we create a Pod/Container to be admitted as restricted and does not violate the PodSecurity with the following security context config:
The Pod/Container will not run and the error On Openshift To allow a workload to run as restricted(restricted-v2 SCC) we MUST leave the runAsUser field empty. Otherwise, we will only be able to run the Pod if it has access to the SCC nonroot-v2 or anyuid. Note that we cannot here define a specific userID because it will depend on the namespace. So, if we want to distribute an Operator using this image we do not know what is the ns where it will be installed and it begins to add complexities on top either if we are OK by running it with security context more permissve. Therefore if we try a number like 1001 we will face issues like:
Then, you can also check its docs:
(and one is distinctly more user-friendly to read than the other). 😬 What do you mean with TL'DR: Regards the suggested solutions:
That is exactly what is not possible to do to achieve the goal.
That is the alternative solution that I am trying to avoid with this PR. Note that I am checking it beforehand and others will also probably ask for the same in the future.
That does not address the problem. I hope that this content and argumentations can help us to get this one merged :-) @tianon @yosifkit @blar @ncopa @michael-k ( Could you please give a look at the reasons and re-consider accepting this small PR? ) |
This comment was marked as resolved.
This comment was marked as resolved.
This is a duplicate of #36. We already define the user ID and its primary group ID; repeating the UID information later in the Dockerfile is not something we want to do as the username is much clearer to users than just a "random" ID (especially when doing This seems like a failing of Kubernetes to not support looking up the defined username and of OpenShift in both not resolving the username to an ID and not having something like an alternate method of defining a non-root uid for the namespace mapping in "restricted-v2 SCC". |
HI @yosifkit,
The current approach does not follow the good practices defined in the Docker docs, please check all info shared here #80 to understand the motivations.
That is not a failure. |
Line 4 in 1f2afc7
We do set an explicit user ID when the user is created as the docs suggest (so it isn't non-deterministic) and we even set the primary group so that the following does not apply.
So, no, I'd rather not repeat the value of that user ID in the |
Closing since it was not accepted. |
Description
Define user id and group instead of name in the Dockerfile
Note that the entry point will set the username.
Motivation
Be able to use this image in Pods qualified with security context restricted in Kubernetes and Opensift clusters.
TL'DR:
RunAsUser
we will face the error:"container has runAsNonRoot and image will run as root …
Error: container has runAsNonRoot and image has non-numeric user (memcache), cannot verify user is non-root
Therefore, for a Pod/Container to be qualified to the restricted-v2 SCC (the most restricted context) we cannot use RunAsUser.NOTE: It was checked locally with the command
memcached -m 1024 -o modern -v
and all worked fine.