Etcd: Dockerfile: run as a non-root user within the container.

[joelegasse]

There has been some renewed interest in #3503, from almost 3 years ago. The idea being that the user ID within the container should not be root (uid 0). There have been some changes to container runtimes since then, including wider support for user namespaces that allow mapping user IDs within a container to non-privileged user IDs on the host.

The primary concern of just issuing USER XYZ in the Dockerfile, or even trying to be clever with adjusting permissions before dropping privileges would be the upgrade path for users already managing the user ID or permissions with currently available features of the runtime. Some examples being:

• User ID specified at the time the container is created/started.
  
  
  
  • Might cause issues if root is assumed in an attempt to drop privileges.
  
  
• Various config options (ENV, config file, command args) used to change data storage locations
  
  
  
  • Adjusting underlying permissions would require full resolution of final etcd config before locations could be known and permissions updated
  
  
• Shared volumes with other containers
  
  
  
  • Adjusting permissions via the etcd container could break setups where volumes are shared with other containers.
  
  

If we go down the "adjust permissions before startup" road, we'd have to either change the entry point to a custom script or integrate the permissions check into the etcd code directly. The latter isn't very helpful for non-container usage and a custom script would need to figure out where the final data locations would be before adjusting any permissions. Simply adding USER xyz to the Dockerfile would almost certainly break existing containers without a manual intervention to update the permissions within the volume.

This issue should be a discussion about the trade-offs and implications of each option. I'm personally leaning toward just adding a recommendation that a non-root user be used when creating the container. I think there are too many unknowns about how the image is being used to try to change this behavior at this point. Any change is likely to break some user's setup, and we should acknowledge where those breakages might occur, or what overhead we're adding to the upgrade process before we proceed with a PR to change the default user ID in the container image.

[philips]

My two cents, we should:

• change to non-root on the next minor or major release of the container
• ensure etcd provides a helpful error message and links to docs if perms are wrong on data dir
• provide docs on how to fix everything if you were using root before
• provide docs on how to run as root if you want to go back to the old behavior

The old default wasn't good and I don't see any reason for it to continue.

[miguelbernadi]

If documentation for newcomers recommends to run with non-root containers and provides an example of how you would like to do it by default in the future:

• The approach will be tested by users
• New systems will follow the default before the new default is enacted
• A least-breaking change path may appear

Default can be changed a few releases later with less impact and clearer picture of user impact.

[hmtai]

Hi, what the progress of etcd run as non-root?I see the milestone is etcd-v3.4.I deploy the etcd as static pod and I want to run etcd as not-root.

[pantaoran]

I'm in a corporate environment where I can run containers on the Kubernetes cluster but I don't have admin privileges on Kubernetes.
It's configured to only accept docker images that explicitly run as non-root. So I cannot use your images, which is a pity.

Environments like mine are normal among the people I know. If you're not going to change your policy on this for the main images, could you at least provide a non-root alternative in addition?

[philips]

@pantaoran what environment are you using that doesn't allow for a security context to set a different UID?

• example: https://github.com/etcd-io/discovery.etcd.io/blob/master/etcd-cluster.yaml#L25
• docs: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

[pantaoran]

I don't understand your example, what is that repo for? It's a different repo from this one here.
I would like to deploy a Galera cluster on Kubernetes, and it needs a service discovery to go along, for which I would like to use etcd. So as an unpriviledged Kubernetes user I want to deploy both etcd and Galera.

Now our k8s cluster enforces a security context as described in https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/ under the section "Apply Security Context to Your Pods and Containers". Therefore, my pods are required to have runAsNonRoot: true in their security context, which in turn requires the Dockerfile of the docker image to contain a line like USER 1001.

Does that make my problem clearer?

[philips]

@pantaoran what I am saying is that you can set the user that a container runs as on Kubernetes even if the container image runs as root be default. The way you do that is by setting a security context as I have done in the example URL provided above.

Putting it another say the Dockerfile having a USER setting is just a default which can be easily changed via configuration on Kubernetes.

[pantaoran]

Ha, I had no idea. Looks like I'm the fool here!
Thank you very much!

I haven't tried this method with your image because I already found an alternative image from bitnami that uses a non-root user in the Dockerfile. There are of course still questions about if everything would really work as a non-root user at runtime, but I will not have time to try that in this case. Good luck everyone :-)