1

When configuring a container process to run as a non-root user on Kubernetes, does the user need to exist on the host? If yes, which user id is appropriate to use when the host node is managed by Google Kubernetes Engine?

Google Cloud's recommended best practices for operating containers state the following:

(...) it is a best practice to not run processes as root inside containers. You can enforce this behavior in Kubernetes by using a PodSecurityPolicy. When creating a pod in Kubernetes, use the runAsUser option to specify the Linux user that is running the process.

I would like to follow this practice.

Niels Søholm
  • 35
  • 1
  • 7

2 Answers2

1

As mentioned in the Best Practice document, you can run a container image locally (or on GKE cluster nodes) with a random user:

docker run --user $((RANDOM+1)) [YOUR_CONTAINER]

It means the user can be a random one; so, it is not of the kind to exist on the host. You just need to make sure it is not a root.

Moreover, you can check this document and run the command to Get a shell to a running Container. After running "ps aux", you will see some processes running under the available users. They can be any random user.

mehdi sharifi
  • 76
  • 5
0

The currently accepted answer sort of implies that you can just set any random non-root UID and be good. I want to clarify a bit for future readers.

Firstly, to make sure everyone is on the same page, Kubernetes currently doesn't support user namespacing as per this issue. This is despite it now being a feature in the Linux kernel and also Docker. So in Kubernetes, when you specify a pod or container securityContext with a runAsUser UID, that UID will be the one in use on both the host node and also within the container. So leads us to your question (and also mine before researching): what UID should you use?

So firstly, yes, everywhere and everyone agrees that it should not be root (UID 0). But it can't be an entirely random UID. If the UID collides with an existing user, with say passwordless sudo permissions, that's effectively root. That's not the only bad case however, you also for example wouldn't want the UID to collide with, say, your MySQL database user. So you want to assign a UID that either a) has no user already assigned to it, or b) to a user you've specifically created on the host for this purpose.

With Google Kubernetes Engine, if you're running with Container Optimized OS images, there seems to be a convention for UID values:

Choose an ID from the [2000, 4999] range to avoid collision with other user accounts.

[1] https://cloud.google.com/container-optimized-os/docs/how-to/create-configure-instance

Inspecting one of our GKE nodes, this seems to be correct, as I see SSH users being assigned UIDs starting at 5000. So on our GKE cluster, we've just assigned UID/GID 2000 for our containers.

Andrey
  • 101
  • 1