Fix: USER (runAsNonRoot)

[till]

Supply the numeric uid/gid of the user/group created early in the Dockerfile. This is to ensure that (on k8s) runAsNonRoot works as expected because the username could indeed map to root (uid 0).

---

For context, I am using dind(-rootless) on a k8s cluster.

[tianon]

See docker-library/memcached#79 (comment):

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:

• run the image explicitly as the user (...)

• maintain a short Dockerfile that's auto-built with just FROM memcached \n USER 11211:11211 (if it has to be baked into the image itself)

• implement something like a mutating admission webhook on the cluster which can pull the image and resolve the UID/GID appropriately to then dynamically update the applied configuration appropriately (which I think is the most "Kubernetes" solution to this problem)

[till]

See docker-library/memcached#79 (comment):

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:

• run the image explicitly as the user (...)
• maintain a short Dockerfile that's auto-built with just FROM memcached \n USER 11211:11211 (if it has to be baked into the image itself)
• implement something like a mutating admission webhook on the cluster which can pull the image and resolve the UID/GID appropriately to then dynamically update the applied configuration appropriately (which I think is the most "Kubernetes" solution to this problem)

Can you reconsider this? There is a functional difference when using this image on Kubernetes. A non-numeric user cannot be verified with runAsNonRoot. See this for implementation details.

Adjusting this, would indeed require less work downstream.

You also already create a user/group with a specific UID (a few lines up), so it seems there's nothing "extra" to maintain?

[till]

@tianon sorry to bug, but any thoughts?

[candrews]

I apparently just made a duplicate of this request at #547

This issue is a real concern. User do not want to "maintain a short Dockerfile" just to set the user to a numeric value. That's a lot of maintenance headache.

Other projects have made this change, ex nodejs/docker-node#2185

Can docker please make this change as well?

[tianon]

Why not set the user explicitly in your Kubernetes YAML instead? Then you control the numeric ID explicitly, which is also really important if you want to be able to control the persistent storage / permissions.

[tianon]

Specific to this repository, and the only tags of this repository that use a non-root USER value, #543 (review) is very relevant, particularly:

I honestly still struggle to understand the purpose/value of having a dind-rootless image, especially when it still requires --privileged (and the usage numbers make me think I'm not alone in scratching my head here as to why this exists / what purpose it serves / value it adds)

[candrews]

Why not set the user explicitly in your Kubernetes YAML instead?

Why should one have to do so?

Besides kubernetes, security tools flag USER with a username. Using USER with a username is just more difficult to use, especially for security conscience use cases.

Plenty of other projects are using numeric uids. Why resist following that widespread practice here?

[till]

@tianon I think I linked you to the code that produces an error with non numeric user/group from the image.

Not sure what other mapping you are suggesting that people do downstream.

[tianon]

I'm suggesting using runAsUser (and related fields) explicitly, which I believe is implemented just a few lines up from the lines you linked: https://github.com/kubernetes/kubernetes/blob/5648200571889140ad246feb82c8f80a5946f167/pkg/kubelet/kuberuntime/security_context.go#L81

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    supplementalGroups: [4000]

(Setting the user you want to run as explicitly will be much more secure in practice than relying on the image to do so.)

[till]

I set both of these usually.

[candrews]

Setting the user you want to run as explicitly will be much more secure in practice than relying on the image to do so.

How is that more secure?

The situation right now is that users need to do more work to achieve the same result. That's not good practice, security related or otherwise. Simplicity is key feature of security.