search

match4everyone / match4healthcare

Helping hospitals find qualified medicine students (Hackathon #wirvsvirus). A more flexibel version is currently in development under match4everyone/match4everything,
https://match4healthcare.de
Other
17 stars 10 forks source link

Docker localhost #540

Closed maltezacharias closed 4 years ago

maltezacharias commented 4 years ago

Based on match4healthcare/error-page-template branch, should be merged afterwards.

Small change. Our current default configuration exposes the docker server on port 80 and 8000 on all interfaces of the host. This is not easy too understand, because port 8000 is carried over from the docker-compose.dev.yml file and 80 is defined additionally on the docker-compose.prod.yml

Additionally we should recommend using a reverse proxy which means that it would be better to only expose on localhost. Unfortunately docker in it's default configuration will otherwise punch holes into the firewall. This PR modifies our default behaviour to only expose the docker image on localhost and references a sample nginx config from #209 in the documentation.

maltezacharias commented 4 years ago

Sounds like a good idea and seems to work. Mapping the container to port 80 was never used in the production server right?

Correct. At least not in the last backup we have.

Regarding docker and the firewall, did you try something like this? https://www.techrepublic.com/article/how-to-fix-the-docker-and-ufw-security-flaw/

I did. --iptables==false breaks all sorts of things. Docker relies on its rules for a lot of things to work and the article leaves out some minor details like all containers losing internet connectivity and such. Also by default container IPs vary so it's not a viable approach to disable the iptable rule creation. The proposed solution by Docker is to add rules to DOCKER-USER but that is limiting and doesn't work well with a lot of other products. Their design is broken. They should add an option to only create the port forwarding NAT rules. These by themselves would not open the ports up automatically anyway. I still think this PR is the best possible solution. If you want to use one of several methods to prevent docker from poking holes you can implement this on your host. How you do that is out of scope for us.

We should only ship the safe default which is to only expose the port on localhost and do it only in one of our .yml files.

Baschdl commented 4 years ago

@maltezacharias Shouldn't we also do the same for the database?

maltezacharias commented 4 years ago

That's not exposed publicly, only between the containers as per https://docs.docker.com/compose/compose-file/#expose I also portscanned our new prod server to be sure, and yes it work's as intended :)