3 ms·
You need to teach the Docker devs that. By default docker localhost is 0.0.0.0 so when you do docker run container_name -p 80:80 you are mapping to 0.0.0.0. I a
by sansnomme 7y ago
You need to teach the Docker devs that. By default docker localhost is 0.0.0.0 so when you do docker run container_name -p 80:80 you are mapping to 0.0.0.0. I always explicitly write out the full port map i.e. -p 127.0.0.1:80:80. This is especially problematic if you are running e.g. postgres in Docker. The last thing you want is to have it exposed to the internet. One mitigation is to change the default localhost, you can do this by setting the IP variable in daemon.json to 127.0.0.1.
/etc/docker/daemon.json (check your OS, for Mac use the GUI)
{
"ip" : "127.0.0.1"
}
Sane, secure-by-default configs are important. Don't let your users go shocked_pikachu.jpeg because of perceived notions of end-user freedom. (See for example how badly a certain famous lisp-based text editor effed up TLS)
- deleted 7y ago[deleted]
- segfaultbuserr 7y ago> Don't let your users go shocked_pikachu.jpeg because of perceived notions of end-user freedom. (See for example how badly a certain famous lisp-based text editor effed up TLS) On the other hand, don't lock your users up because of perceived notions of end-user privacy and security. (See for example how badly a certain famous browser named after a metal blocked adblockers) Not disagreeing with you at all, I'm all for strict TLS defaults, just ranting about the fact that so many restrictions meant for control and domination are marketed as "security", it hurts the public support of actual security. Many people I've read online cannot distinguish Google's push of secure TLS and Google's push of artificial control, one decided to run the website on plaintext HTTP diehardly. And many others still see ALL hardware security modules as evil DRM / mandatory code-signing scheme. How unfortunate it is, even more unfortunate is that their estimation has a better chance to be correct.