I learnt that to run a container as rootless, you need to specify either the SecurityContext:runAsUser 1000 or specify the USER directive in the DOCKERFILE.
Question on this is that there is no UID 1000 on the Kubernetes/Docker host system itself.
I learnt before that Linux User Namespacing allows a user to have a different UID outside it’s original NS.
Hence, how does UID 1000 exist under the hood? Did the original root (UID 0) create a new user namespace which is represented by UID 1000 in the container?
What happens if we specify UID 2000 instead?
2
Answers
Hope this answer helps you
You are correct except in
runAsUser: 1000
. you can specify any UID, not only1000
. Remember any UID you want to use (runAsUser: UID
), thatUID
should already be there!Often, base images will already have a user created and available but leave it up to the development or deployment teams to leverage it. For example, the official Node.js image comes with a user named node at UID
1000
that you can run as, but they do not explicitly set the current user to it in their Dockerfile. We will either need to configure it at runtime with arunAsUser
setting or change the current user in the image using aderivative Dockerfile
.Remmeber that
runAsUser
andrunAsGroup
ensures container processes do not run as theroot
user but don’t rely on therunAsUser
orrunAsGroup
settings to guarantee this. Be sure to also setrunAsNonRoot: true
.Here is full example of
securityContext
:sources:
Something at the container layer calls the setuid(2) system call with that numeric user ID. There’s no particular requirement to "create" a user; if you are able to call
setuid()
at all, you can call it with any numeric uid you want.You can demonstrate this with plain Docker pretty easily. The
docker run -u
option takes any numeric uid, and you candocker run -u 2000
and your container will (probably) still run. It’s common enough todocker run -u $(id -u)
to run a container with the same numeric user ID as the host user even though that uid doesn’t exist in the container’s/etc/passwd
file.At a Kubernetes layer this is a little less common. A container can’t usefully access host files in a clustered environment (…on which host?) so there’s no need to have a user ID matching the host’s. If the image already sets up a non-root user ID, you should be able to just use it as-is without setting it at the Kubernetes layer.