Envoy shouldn't run as root.

[bpinske]

Description: Some organizations have podsecuritypolicies that prevent containers from running as root.

https://github.com/envoyproxy/envoy/blob/main/ci/docker-entrypoint.sh#L27 https://github.com/envoyproxy/envoy/blob/main/ci/Dockerfile-envoy#L26

After reading the dockerfile and entrypoint script it seems that the container starts off as root but later su-execs to be the envoy user. This isn't good enough for Kubernetes which still sees a container being started as root.

Is there ever a reason to allow Envoy to run as root rather than just doing the logic of the entrypoint script right in the dockerfile with a USER envoy directive?

[optional Relevant Links:] In the knative kourier project envoy is leveraged but envoy is ran as root https://github.com/knative-sandbox/net-kourier/pull/593 https://github.com/knative/operator/issues/710

[phlax]

so the history of this is that Envoy originally ran as root both as the main container process and as the Envoy process

i changed this so that in the distributed containers permissions were dropped so that even tho the main container process was still root, Envoy was execed with more limited permissions

this was the agreed compromise at the time, because there were many things (eg Envoy's docs) that expected the container to run as root

an opt-out was also added to revert to the original (root throughout) running

i have no aversion to moving to use USER for setting container permissions but others may think otherwise - cc @lizan

tbh, i think the future in terms of deployment containers is to use the distroless container where the permissions are kinda taken care of

[bpinske]

I've looked at this myself and its kind of a tricky situation.

It's obviously not good to start off as the Envoy user and then optionally escalate back to root.

There would be no way to truely start off as the Envoy user in a way that would satisfy a PSP requirement of no root and support the possibility of root without causing breaking changes in the same container.

If you imagine a case where the container was always Envoy user only and overrides were passed in the form of a kubernetes runAsUser directive or a docker -u argument, then it would still be possible to run as root anyway. But it would be backwards incompatible with the existing environment variable scheme which would need to be removed.

https://docs.docker.com/engine/reference/run/#user.

Distroless containers are a good idea, however in my case that's not immediately possible as the latest distroless container image published is for 1.19. There are plenty of options available to me specifically how I can deal with this, but its a tricky one to fix properly upstream without introducing breaking changes.