Open andrew-wharton opened 7 years ago
@andrew-wharton
You're absolutely correct. There are a number of things open to the public in the demo docker-compose.yaml
in this repo to make demos and learning easier. It's not safe for production.
Having Consul exposed to the world as it is is the first of those problems, regardless of whether or not the SSL details are in there.
Recommended changes for production:
On Triton, removing the port declarations will not only close those ports, but the container won't even get an interface on the public internet.
This could be better noted, perhaps in the Compose file. Do you have any suggestions?
Thanks for the quick response.
I think the main problem is that the README gives the impression that this is a turnkey solution for setting up a production ready WP site, especially when discussing details such as setting auth keys and salts, as well as scaling up to multiple instances.
People will likely also be using this as a template/reference for setting up their own production systems for other applications, so a word on adequately securing it in the README would be great. And as you mentioned, some comments in the Compose file about changing the "ports" would be useful as well.
I was going to ask about how you can still use CNS once you remove the port declarations from Consul, but then I discovered the dns_search option, so I guess that's it.
Thanks!
Please correct me if I'm wrong here, but...
When setting up SSL/TLS in the nginx container using Let's Encrypt, it stores its certificate, private key etc. in Consul's key/value store under nginx/acme/*, presumably so they can be replicated to multiple nginx instances once the certificate is obtained.
However, access to Consul isn't secured in any way, or at least I can't find mention of it, and it's accessible on the internet on :8500. Wouldn't this make it trivial to get the site's SSL/TLS certificate and private key if one knows the hostname or the IP address of the consul instance?
Or am I missing something here?