Default configs in Docker images dont work very well out of the box

[phlax]

description

The default Envoy docker image comes with an example configuration that:

• listens on 127.0.0.1:9901 with an admin interface
• proxies http 0.0.0.0:10000 to https www.google.com

Running this with

docker run -it --rm -p 10000:10000 -p 9901:9901 envoyproxy/envoy:v1.16.0

...and browsing to http://localhost:PORT neither works very well.

The admin doesnt work at all out-of-the-box because its listening to 127.0.0.1

The google proxy creates an overlay with a spinning wheel and borks (im guessing that playing with eg /etc/resolv.conf it might work differently)

I would propose that we change and/or document the admin UI

For the proxy, how about we proxy to the www.envoyproxy.io website

refs

• Improve install docs #13461
• docs: Update start/install section #13490

[phlax]

also noticing that they are using v2 configs (related to #13529 (comment))

[phlax]

@mattklein123 there are kinda 2 questions/propositions here

use envoyproxy.io as default/demo proxy

proxying http://localhost to https://anything.else is always going to be imperfect, but proxying to the envoy website works better than proxying to google and is more "neutral" i think.

make admin listen on 0.0.0.0 in default/demo configuration

this one im a bit more ambivalent about because there is an obvious security implication.

in the docker image it doesnt matter much because without it it doesnt work at all - with it, it will still only expose admin according to your Docker configuration

running envoy outside of docker with admin on 0.0.0.0 is a bit more complex, but at least to do this you would have to download the config and run with it - so we can document that you would probs not want to do this in normal operation - or at least to take measures to protect this endpoint

[phlax]

i would quite like to move on this quicly - once #13562 is landed.

If i can fix this before #13490 it will make "getting-started" easier to document

[phlax]

@lizan do you have any thoughts on above suggestions ?

[mattklein123]

I think both of these changes are fine with me, as long as we very carefully document the security implications of the admin config in the example.

IIRC the google proxy used to work, so it would be nice to understand why it no longer works, but I guess that is a separate issue. I think proxying to the website as a neutral location makes sense to me.

[phlax]

it would be nice to understand why it no longer works

almost certainly Content Security Policy

[phlax]

as long as we very carefully document the security implications

here is the (wip) bit in the updated quick start instructions

https://storage.googleapis.com/envoy-pr/13490/docs/start/quick-start.html#configuration-admin

[phlax]

running envoy outside of docker with admin on 0.0.0.0

thinking about this further - this is how it is already documented. So the only change i think is to the config in the Docker image

[lizan]

in the docker image it doesnt matter much because without it it doesnt work at all - with it, it will still only expose admin according to your Docker configuration

It does matter if you run with --network=host, which I've been seeing people doing this in many cases.

[phlax]

which I've been seeing people doing this in many cases.

im sure the image is used in many different ways - but the default config - ie the one that proxies to google etc is less likely to be used in this way.

currently we have the worst of all worlds. The Docker image config doesnt work, and the documentation encourages you to listen on 0.0.0.0 without any word to secure it

[phlax]

the other option - which i think is not a bad idea - remove the config altogether (as getenvoy does i think)