Handle container started as non-root better

[phlax]

description

It seems like a common issue that people try to start the container as non-root, which doesnt work with the ENTRYPOINT currently.

Users then seem to set ENVOY_UID and that only confuses the issue further.

I think we can do a couple of things.

• print a very big warning in the entrypoint if it detects that it has been started by a user other than root - perhaps with link to docs
• allow the container to be started (with an explicit flag) as non-root in which case it wont try to drop perms or chown stuff etc

starting as non-root will probably work in most situations, esp if you ensure the env yourself - not sure off hand about stdout/err

[phlax]

this may be an issue for some specific frameworks or at least common setups - eg openshift

[phlax]

one idea i was thinking of for starting as non-root is that if the ENVOY_UID is set and the container is started with the same uid, perhaps it could skip the permissions dropping etc

[phlax]

@lizan any thoughts on this ?

[phlax]

/assign phlax

[lizan]

I forgot why we had chown in the first place, in most environment it isn't needed anyway... /dev/stdout is a symlink to /proc/self/fd/1

[phlax]

im trying to rem too - my vague recollection was that it was needed

i guess there are two options that might improve this - remove it (if unneeded), or add some logic to conditionally do whatever perms/user checking/dropping

i think the main issue is that users are trying to start the container (from outside) as non-root, which can work i think, but wont with the current permission dropping

[lizan]

agreed, I'm ok with either way.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[phlax]

bump

[mtttcgcg]

This is more important for us now that Envoy 1.14's xDS v2 API is deprecated. 1.14 was the last version we were able to run without encountering this issue.

[phlax]

@mtttcgcg there is a fix i think in #15115

ill follow up with an update to docs once that has landed

[phlax]

@ToniCipriani @mtttcgcg if you can confirm that this issue was resolved in #15115 ill add a note in docs and we can close this ticket i think

[ToniCipriani]

@ToniCipriani @mtttcgcg if you can confirm that this issue was resolved in #15115 ill add a note in docs and we can close this ticket i think

Looks good. Deployed envoyproxy/envoy-alpine-dev, container did not complain and I can see logs. Did a few basic tests and seems to work fine.

Thanks.

[ToniCipriani]

Also, will this be part of the next 1.17 release?

[phlax]

@Shikugawa would we be able to backport #15115 and/or include in current release ?

[Shikugawa]

@phlax It makes sense. Affected versions are 1.15, 1.16 and 1.17, right?

[phlax]

great, thanks

Affected versions are 1.15, 1.16 and 1.17, right?

yep - just checked the v1.15-latest image and that has the problem entrypoint

[ToniCipriani]

@phlax We noticed the same problem again on one of our clusters. However it doesn't mention the additional message, and it tried to drop the permissions, resulting in the chown error again. I will have to check the service account configuration on what it's trying to run as.

[phlax]

im a little confused - im trying to figure out how either, it could be running as non-root but get a uid of 0, or, its running as root but cant chown