9 ms·
While docker's port exposure should be more explicit, he should also mention that he used docker without reading the parts of the doc he neeeded to, blindly tru
by bionade24 4y ago
While docker's port exposure should be more explicit, he should also mention that he used docker without reading the parts of the doc he neeeded to, blindly trusting some dangerous half-knowledge from a forum or other persons.
If he'd bind the host port to localhost or put caddy in a container in the same vlan, it wouldn't have happened. From the blogpost I'm not even sure if he's aware of the binding option.
If you argue that a software shouldn't behave this way after being configured so explicitly, Archlinux not preconfiguring iptables to limit exposure like Debian or Ubuntu is worse, because it happens implicitly.
- chaps 4y agoConsidering how aggressively docker has been pushed down peoples' throats over the past 10 years, from bootcamps to tutorial after tutorial teaching how to use docker... it seems pretty unreasonable to think that everybody is going to read the all of the docker docs that describe this problem. Considering the risks involved, it's frankly silly for them not to include a warning. Hell, in the "container networking" docs, it even says it doesn't: "By default, when you create or run a container using docker create or docker run, the container doesn’t expose any of it’s ports to the outside world." And archlinux not preconfiguring iptables is a very, very archlinux-y thing to do -- not sure what your point on that is supposed to be there.
- Godel_unicode 4y agoIt doesn’t say that it doesn’t do that, it says that it doesn’t do that by default. If you explicitly tell it to expose a port, how can you possibly be surprised when it does so? If you don’t read the docs you don’t get to complain when you don’t understand the behavior. Edit: the second paragraph on the first search result for “docker networking” says that because it’s trying to present things in a platform independent way the overview won’t cover iptables specifics and then links to the detailed docs of how it uses iptables. If you can’t read two paragraphs maybe don’t try to be an engineer.
- ethbr0 4y agoIf something is designed and marketed as being usable without reading docs, it'd damn well better have defaults that "First, do no harm." It's insane to build something that optimizes ease of use, and then require users to understand it in depth to avoid footgunning.
- Godel_unicode 4y agoWho is marketing it that way? That’s insane.
- selfmodruntime 4y agoIt really is. I am astonished by the simple mindedness of some people in this thread. Half knowledge really is dangerous.
- chaps 4y agoNo need to call people simple minded, friend. It completely debases your point to the extent that it makes me question whether you understood their point. Consider the possibility that you simply misunderstood their point.
- selfmodruntime 4y agoExpecting a potentially dangerous tool to "just work" when the documentation is several thousands of words long is simple minded, especially when you watched a 10 minute video on it from some random tech blogger.
- Gordonjcp 4y agoBy default, Docker containers are not exposed to the host's public interface. You must explicitly expose them. If you expose everything else too, that's no-one's fault but yours.
- 4y ago
- selfmodruntime 4y ago> By default, when you create or run a container using docker create or docker run, the container doesn’t expose any of it’s ports to the outside world. It doesn't? You're explicitly telling it to do so and then go on crying about how docker is awful.
- chaps 4y agothat's word for word from: https://docs.docker.com/config/containers/container-networking/ https://docs.docker.com/config/containers/container-networki...
- Godel_unicode 4y agoBy default, as the docs very clearly state, ‘docker run’ doesn’t make network changes. The blog post was written by someone who has a compose file which changes this default behavior, which is extremely unsurprising as that is the entire purpose of compose files. If you change the default behavior, then the default behavior no longer applies and you should read the docs pertaining to how you changed the behavior.
- chaps 4y agoYou're being really generous to the documentation at Docker. It stinks and doesn't make it clear that it punches a hole in your firewall. Neither the compose quickstart [1], nor the compose specification [2] mention anything about iptables nor firewalls. The compose specification adds more details than the quickstart, but... it's obtuse, and overall a 12,000 word document! Surely that incredibly important information that has demonstrably and unexpectedly led to external access should be contained in either of these documents! Surely you can agree that their documentation should contain either the word "iptables" or "firewall"?! [1] https://docs.docker.com/compose/gettingstarted/ https://docs.docker.com/compose/gettingstarted/ [2] https://docs.docker.com/compose/compose-file/ https://docs.docker.com/compose/compose-file/
- selfmodruntime 4y ago
- NotYourLawyer 4y ago> he used docker without reading the parts of the doc he neeeded to, blindly trusting some dangerous half-knowledge from a forum or other persons Same thing 90% of people do.
- bionade24 4y agoIf you mean people that install Docker as an "app" on their NAS, they most likely use portainer and don't run into this issue. There are ways for people that don't want to learn the configuration of a project.
- Brian_K_White 4y agoFailed to read the entire docs is orthagonal to harmful default behavior. Maybe he also smells bad some days. So what? Docker is still wrong, and further, more wrong than the user.
- selfmodruntime 4y agoNo. Docker is correct in this case. There is no other way for traffic to get to your container. You must explicitly tell it to amend your firewall rules with the "-p" argument.