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 https://github.com/docker-library/memcached/pull/79#issuecomment-1180881289:

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). :grimacing:

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?