I just learned: Docker edits firewall rules for you(geoff.tuxpup.com)
geoff.tuxpup.com
I just learned: Docker edits firewall rules for you
https://geoff.tuxpup.com/posts/psa_docker_edits_firewall_rules/
125 comments
s/nearly//
From https://zwischenzugs.com/2015/06/24/the-most-pointless-docke... anyone with Docker access gets root with that command.
TBH out of the box Kubernetes is as bad, or worse than docker, in that anyone with create pod permissions can get root on every worker node in the cluster (and the control plane nodes if it's unmanaged Kubernetes) https://raesene.github.io/blog/2019/04/01/The-most-pointless...
From https://zwischenzugs.com/2015/06/24/the-most-pointless-docke... anyone with Docker access gets root with that command.
TBH out of the box Kubernetes is as bad, or worse than docker, in that anyone with create pod permissions can get root on every worker node in the cluster (and the control plane nodes if it's unmanaged Kubernetes) https://raesene.github.io/blog/2019/04/01/The-most-pointless...
I love how all use cases for this is to simply run some command as a user without write permission to anything.
We evolved sysadmin oposing thumbs called virtual machines just to deal with our environment making it cheaper to emulate an entire other computer instead of dealing with having a user without write access, guaranteed, on the FS.
We evolved sysadmin oposing thumbs called virtual machines just to deal with our environment making it cheaper to emulate an entire other computer instead of dealing with having a user without write access, guaranteed, on the FS.
The 1st thing only happens when users explicitly misconfigure docker, the other one is a real security problem when docker runs in root mode.
There's nothing "explicit" about this sort of misconfiguration, that's exactly why it catches so many people out. It's a bad/insecure default that serves no practical purpose. If Docker bound to 127.0.0.1 by default and required you to explicitly bind to "0.0.0.0" to expose the container to the outside world, the frequency of dangerous misconfigurations would likely be reduced by 95%+.
It would still catch people who bind to 0.0.0.0 and expect the traffic to be blocked by UFW, but that's a different issue. `iptables: false` is a very crude solution, they should offer something like `iptables: "manual"` where Docker only touches its own iptables chains and lets you wire them up to your own UFW/iptables chains in a sane way.
It would still catch people who bind to 0.0.0.0 and expect the traffic to be blocked by UFW, but that's a different issue. `iptables: false` is a very crude solution, they should offer something like `iptables: "manual"` where Docker only touches its own iptables chains and lets you wire them up to your own UFW/iptables chains in a sane way.
You can also add `iptables: false` to docker's daemon json and docker will stop messing with your iptables conf.
The docs strongly advise against this: https://docs.docker.com/network/iptables/
This is on my todo list after wrestling docker almost in to compliance with nftables. Even so, I still have some issue with ports forwarded to docker services not NATting correctly and instead show up with a source IP of the docker bridge. Switching to nftables exclusively (docker is using iptables-nft) and preventing docker from doing this should resolve my issues.
I can't think of another application on any of my systems that muck with firewall rules behind the scenes like this.
I can't think of another application on any of my systems that muck with firewall rules behind the scenes like this.
[deleted]
I only learned about this a few years ago by coincidence, because I happened to open HN when there was a story[1] about NewsBlur having been hacked "thanks" to this Docker "feature".
[1]: https://news.ycombinator.com/item?id=27670058
[1]: https://news.ycombinator.com/item?id=27670058
If such an obvious thing happens to a company because they're too smart to read documentation, they would have run into big problems with LXD or sd-machined, too.
I disagree that this is obvious or reflects an inappropriate attitude.
This is a case where a tool you trust (ufw) lies to you because Docker not only unexpectedly adds iptables rules for simple scenarios, but adds them at a higher priority than your firewall. Software doesn't normally modify your firewall when it binds to a port, and firewalls exist to restrict port exposure.
Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes).
If Docker was a simple tool with brief docs, I could agree, but Docker's docs are so extensive that knowing everything it does isn't practical. One just has to hope they stumble into docs on footguns. It's hard for me to call this behavior "obvious" without basically invalidating footguns as an idea.
This is a case where a tool you trust (ufw) lies to you because Docker not only unexpectedly adds iptables rules for simple scenarios, but adds them at a higher priority than your firewall. Software doesn't normally modify your firewall when it binds to a port, and firewalls exist to restrict port exposure.
Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes).
If Docker was a simple tool with brief docs, I could agree, but Docker's docs are so extensive that knowing everything it does isn't practical. One just has to hope they stumble into docs on footguns. It's hard for me to call this behavior "obvious" without basically invalidating footguns as an idea.
> Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes).
Adding to this. I really don't blame people (not even my past self) for:
* Expecting `-p 8001:8002` to behave the same way as the unprivileged `ssh -L 0.0.0.0:8001:${CONTAINER_IP_IN_ONE_DOCKER_SUBNET}:8002`.
* Expecting `ufw` to pickup changes in firewall rules.
* Trusting the offline `man 1 docker-run`.
Even knowing what I know now (I'm still pretty ignorant, but a little bit less than in the past), I still consider this a bad default from the Docker CLI.
Yes, `docker run` needs privileges for other stuff, but since the forwarding part can be done without punching a hole, I don't think it's unreasonable to expect it to be done that way.
Even just mentioning the word "iptables" in `docker-run(1)` would go a long way.
Adding to this. I really don't blame people (not even my past self) for:
* Expecting `-p 8001:8002` to behave the same way as the unprivileged `ssh -L 0.0.0.0:8001:${CONTAINER_IP_IN_ONE_DOCKER_SUBNET}:8002`.
* Expecting `ufw` to pickup changes in firewall rules.
* Trusting the offline `man 1 docker-run`.
Even knowing what I know now (I'm still pretty ignorant, but a little bit less than in the past), I still consider this a bad default from the Docker CLI.
Yes, `docker run` needs privileges for other stuff, but since the forwarding part can be done without punching a hole, I don't think it's unreasonable to expect it to be done that way.
Even just mentioning the word "iptables" in `docker-run(1)` would go a long way.
I learned this a few months ago too.
It's such a weird, stupid system. But everyone seems to think this is pretty normal.
I think the firewall is my business, and nothing else should automatically open ports in it. Especially not docker.
I think the firewall is my business, and nothing else should automatically open ports in it. Especially not docker.
Yep, learned that the hard way when it trashed my server UFW config as well. It felt kinda wierd to have a tool change machine configuration in such a way (even VMs generally don't do that?), but what do I know, I still prefer to deploy single binary services.
This is not about being unnormal, this is a design decision. Just because people use docker in the "tradional admin way", too doesn't mean it's a wrong decision to do this. Wishful thinking about what a command of a software does without looking it up is generally dangerous. There are abstractions to help people that don't want to bother, e.g. portainer.
Violates least surprise.
Accomplishes least resistance.
Least resistance is of no legitimate value by itself. It's a goal only within the bounds of other constraints. The examples are literally countless.
It is a long standing issue and is a gotcha for everyone.
https://github.com/moby/moby/issues/22054
It's completely asinine.
https://github.com/moby/moby/issues/22054
It's completely asinine.
What's asinine is "I configured it wrong and it broke, it's a bug in docker".
Docker's networking behaviour famously changes between point releases, sometimes without even being mentioned in the release notes.
Very much a case of "make sure you use some sort of overarching firewall solution" wrapping your Docker hosts, otherwise you can be in for a world of hurt. :/
Their support for IPv6 used to be extremely shitty too, with the documented switch to enable it... not working at all. Heh. ;)
The IPv6 thing may or may not be better now, but I haven't tried Docker with IPv6 in years so no idea.
Very much a case of "make sure you use some sort of overarching firewall solution" wrapping your Docker hosts, otherwise you can be in for a world of hurt. :/
Their support for IPv6 used to be extremely shitty too, with the documented switch to enable it... not working at all. Heh. ;)
The IPv6 thing may or may not be better now, but I haven't tried Docker with IPv6 in years so no idea.
No, you don't need a firewall.
Docker doesn't expose anything to the public interface unless you specifically request that it does.
If you don't understand the implications of this, you should not be running servers.
It is absolute shite at doing IPv6, which is annoying.
Docker doesn't expose anything to the public interface unless you specifically request that it does.
If you don't understand the implications of this, you should not be running servers.
It is absolute shite at doing IPv6, which is annoying.
> Docker doesn't expose anything to the public interface unless you specifically request that it does.
Heh Heh Heh.
Having directly been involved in the clean up of it doing exactly that a few years ago, I'll just say that your confidence is dangerously misplaced. :(
Heh Heh Heh.
Having directly been involved in the clean up of it doing exactly that a few years ago, I'll just say that your confidence is dangerously misplaced. :(
Okay, give me the steps to reproduce it.
What did you do, what did you get wrong, and why did it need "cleaned up"?
What did you do, what did you get wrong, and why did it need "cleaned up"?
The law of least-surprise disagrees with you I am afraid: firewall rule override is clearly stepping off the limits of what containerization should provoke.
Maybe inform yourself of the situation and consider again carefully.
Should all programs running as root bypass a firewall explicitly configured by the user?
Should all programs running as root bypass a firewall explicitly configured by the user?
The real answer is that OP is using docker wrong. If you „publish“ a port, your firewall gets amended. This is clearly stated in the documentation. If you do not wish for that to happen, and instead want to use a reverse proxy, you „expose“ a port instead and reroute the requests into the docker bridge network.
No, it isn't. Looking at the documentation (https://docs.docker.com/compose/compose-file/compose-file-v3...), it doesn't mention the firewall anywhere.
It clearly states “this will publish the mentioned port to the outside world”. How do you expect this to work? Magic?
No, it doesn't. That's not written anywhere on the page. And even if it were, the obvious interpretation of "outside world" would just be that it's available outside the container. And maybe that it's bound to the external network interfaces, but not that it bypasses the firewall.
The documentation clearly states that ports are published. You just didn't follow up on it. Publishing is a docker term different from exposing. There is information on the page about exposing a port without publishing it. Under `long syntax` there is the following information: "published: the publicly exposed port" [0]. How much more clear than "publicly exposed" can you get?
What is a published port? Again, look in the documentation, it's clearly states there [1].
You need to learn to read the documentation of potentially dangerous tools fully. If you don't, you're in for a world of hurt. The outside world is clearly just that.
[0]: https://docs.docker.com/compose/compose-file/compose-file-v3... [1]: https://docs.docker.com/config/containers/container-networki...
What is a published port? Again, look in the documentation, it's clearly states there [1].
You need to learn to read the documentation of potentially dangerous tools fully. If you don't, you're in for a world of hurt. The outside world is clearly just that.
[0]: https://docs.docker.com/compose/compose-file/compose-file-v3... [1]: https://docs.docker.com/config/containers/container-networki...
Except it is not clear at all and should mention the firewall changes. I expect that publishing means listening on 0.0.0.0, not messing with the firewall.
See my comment above. Firewall changes are clearly mentioned under the section "published ports".
What you expect does not matter. What you're thinking of is exposing. It's even in the word "publish".
The documentation has two sections entirely devoted to the terms. It's in the section "container networking", which is marked as required reading by the docs.
It's not dockers fault that you're copy pasting configuration examples from medium blogs.
[0]: https://docs.docker.com/config/containers/container-networki...
What you expect does not matter. What you're thinking of is exposing. It's even in the word "publish".
The documentation has two sections entirely devoted to the terms. It's in the section "container networking", which is marked as required reading by the docs.
It's not dockers fault that you're copy pasting configuration examples from medium blogs.
[0]: https://docs.docker.com/config/containers/container-networki...
You know, it would be nice for you to actually read the docs before posting insulting comments.
> This creates a firewall rule in the container
We’re done here.
> This creates a firewall rule in the container
We’re done here.
Not by default, but if you explicitly pass them a command-line flag that means "open this port to the network" then they should.
No they shouldn't, just how nginx shouldn't manipulate iptables just because you've said it should listen to 443 on "the network".
Many times you don't even want docker containers to go "to the network" directly and it shouldn't assume unsecure behaviour by default.
Moreover, CRITICALLY, you can't prevent Docker from doing that and you can ONLY secure the machine by adding another rule on top that supresses Dockers rule... and those dockers rule change over time making it easy for the blocking hack to stop working after an update and again make the machine unsecure.
Many times you don't even want docker containers to go "to the network" directly and it shouldn't assume unsecure behaviour by default.
Moreover, CRITICALLY, you can't prevent Docker from doing that and you can ONLY secure the machine by adding another rule on top that supresses Dockers rule... and those dockers rule change over time making it easy for the blocking hack to stop working after an update and again make the machine unsecure.
> No they shouldn't, just how nginx shouldn't manipulate iptables just because you've said it should listen to 443 on "the network".
But you've typed in a command that explicitly will alter the iptables rules, as documented, and as you have requested
> Many times you don't even want docker containers to go "to the network" directly and it shouldn't assume unsecure behaviour by default.
Docker containers do not have a network connection outside their own subnet by default, and only expose the ports that they have explicitly been configured in the Dockerfile to expose.
By determining the container's IP address you can talk to it directly but this is not really recommended, because it can and will change. This internal IP address is by default in an RFC1918 range, and will not be in any way accessible from the outside world.
> Moreover, CRITICALLY, you can't prevent Docker from doing that and you can ONLY secure the machine by adding another rule on top that supresses Dockers rule... and those dockers rule change over time making it easy for the blocking hack to stop working after an update and again make the machine unsecure.
You can prevent Docker from doing that, by not adding into the command line the additional option that tells it to hook containers up directly to the "outside world" interface bypassing any firewall you might set.
But you've typed in a command that explicitly will alter the iptables rules, as documented, and as you have requested
> Many times you don't even want docker containers to go "to the network" directly and it shouldn't assume unsecure behaviour by default.
Docker containers do not have a network connection outside their own subnet by default, and only expose the ports that they have explicitly been configured in the Dockerfile to expose.
By determining the container's IP address you can talk to it directly but this is not really recommended, because it can and will change. This internal IP address is by default in an RFC1918 range, and will not be in any way accessible from the outside world.
> Moreover, CRITICALLY, you can't prevent Docker from doing that and you can ONLY secure the machine by adding another rule on top that supresses Dockers rule... and those dockers rule change over time making it easy for the blocking hack to stop working after an update and again make the machine unsecure.
You can prevent Docker from doing that, by not adding into the command line the additional option that tells it to hook containers up directly to the "outside world" interface bypassing any firewall you might set.
You‘re wrong. If you use a command line argument that explicitely states „this will publish this port in your firewall for convenience“, a command line argument which you shouldn‘t use anyway, then you‘re on your own.
You choose to do this. Docker assumes that you know what you‘re doing.
You‘re also wrong in your last paragraph. There is the - easy - option to expose the port on your loopback, and re route to the docker bridge network by using a reverse proxy.
You choose to do this. Docker assumes that you know what you‘re doing.
You‘re also wrong in your last paragraph. There is the - easy - option to expose the port on your loopback, and re route to the docker bridge network by using a reverse proxy.
This is exactly right. The alternative is ridiculous.
Also, comparing expectations of Docker vs. something like nginx is crazy.
Also, comparing expectations of Docker vs. something like nginx is crazy.
> the alternative is ridiculous.
Like what is, having full control over your own system? I don’t think there’s anything wrong with not messing with my firewall and leaving this part to me.
> is crazy
And this is why, exactly?
Like what is, having full control over your own system? I don’t think there’s anything wrong with not messing with my firewall and leaving this part to me.
> is crazy
And this is why, exactly?
How exactly do you *not* have full control of your system? Because typing in a command expressly designed to modify firewall rules... actually modifies firewall rules?
It’s not clearly stated in the docs, this is exactly how and why that happens.
It actually is, though, you just need to read them.
I read them. It's doesn't say that.
You do have full control over your system.
You could choose not to install docker, for once.
You could choose not to install docker, for once.
You can prevent docker from doing that by editing its config, but you have to read the documentation to know that. As you have to, to actually know what a certain command does, too.
What horror. Now we actually have to read the documentation of potentially dangerous tools instead of guessing or following twitter tutorials.
Yes, if the command you ask them to perform connects to the public interface.
I can also note that I didn't find any supported way to prevent that from happening. So it's one thing to find out that docker edit firewall rules. It's another thing to build a proper set of firewall rules which will prevent incoming connections.
I came up with some rules including DOCKER-USER chain but I'd qualify them as hack relying on undocumented configuration. And I just have no idea how to configure firewalld because it puts another layer of complexity on top of iptables.
I came up with some rules including DOCKER-USER chain but I'd qualify them as hack relying on undocumented configuration. And I just have no idea how to configure firewalld because it puts another layer of complexity on top of iptables.
FYI, afaik firewalld as a high level interface is on the way out in RHEL* land (if that's what you're using), to be replaced by nftables.
firewalld is a high level interface to both nftables and iptables.
Afaik, firewalld doesn't speak nftables (the tooling, not the backend).
At least, in the sense that if you use nftables (the high level tooling/config) and firewalld (the high level tooling/config), there will be some incompatibilities.
So it's either/or.
At least, in the sense that if you use nftables (the high level tooling/config) and firewalld (the high level tooling/config), there will be some incompatibilities.
So it's either/or.
This is a trend that needs to be sharply curtailed. The last time I _re-started_ my Big Blue Button server it automatically installed UFW along with it's own ruleset completely locking me out as I run SSHD on a non-standard port. All without asking or even telling me it was going to do this. Aargh!
I've been burned and infuriated by this, but let me ask honestly, is there other (common-ish) software that does this? The novelty to me was half the issue.
[deleted]
The fact that ufw doesn't play well with iptables sounds like a good reason not to use it.
(Yes yes I know iptables is antiquated but they should still be compatible with each other at the kernel level)
(Yes yes I know iptables is antiquated but they should still be compatible with each other at the kernel level)
UFW works fine with iptables. The issue occurs because docker adds an iptables chain that takes precedence over the UFW rules.
If ufw worked fine, they shouldn't have had to run "iptables -L" to find out that docker put in a rule that "ufw status" couldn't see. The commands should just be interchangeable.
UFW works by creating iptables rules. It intentionally does not expose the full functionality of iptables. The u is for "uncomplicated". The fact that you can add iptables chains that take precedence over the UFW managed chain is a feature of iptables, not a bug of UFW. You'll find the same is true of any Linux firewall that sits on top of iptables or nftables.
I use firehol. All it does is convert "interface eth0 server https allow" into the respective iptables rule(s). While in theory you could write additional iptables rules outside of firehol, there really isn't an equivalent to "ufw status", only "iptables -L"... no room for ambiguity.
I hadn't heard of this before. Reading about it a bit it feels like the worst of both worlds. Doesn't this mean you need to know firehole to create your firehol config AND know iptables to inspect what's actually applied?
Maybe, I really hadn't thought about it that way... but it's a lot easier to write rules though unless you're doing something weird (like ripping a packet apart to look at a particular byte offset). I used to write my own iptables scripts but that got quite tedious.
Could UFW detect/warn that there are iptables rules interfering with its own rules?
That's a good question actually. Given the complexity and power of iptables and nftables (which is the reason UFW, firewalld and the like exist) I'd guess probably not. Trying to determine if a rule on another chain (or really a combination of rules across a combination of chains) changes the behavior of one of yours would be... challenging. I suspect the best it could do reliably is detect that rules in other chains exist and warn about that, but that's also a pretty common case. Pretty much every VPS in a cloud would have this warning for example.
Personally I think the real problem here is docker. Injecting rules into iptables is a bit like blindly injecting lines of code into someone else's program sight unseen. I'm not aware of any other tools that are nearly so willing to do so.
Personally I think the real problem here is docker. Injecting rules into iptables is a bit like blindly injecting lines of code into someone else's program sight unseen. I'm not aware of any other tools that are nearly so willing to do so.
This is the kind of case that is a good argument for regulated liability even on open source or gratis software components in the egregrious cases - the actor is a big tech company and clearly exposing users to compromise breakins in a calculated, fully aware way, for ~7 years.
[1] https://github.com/moby/moby/issues/22054
[1] https://github.com/moby/moby/issues/22054
Why does Docker have the privilege of editing the iptables? Is it running as root?
Yes, the docker daemon runs as root
It doesn't have to.[1]
[1] https://docs.docker.com/engine/security/rootless
[1] https://docs.docker.com/engine/security/rootless
It's fascinating that the bulk of the responses here amount to "you're holding it wrong". Somehow I think the conversation would look a lot different with the same argument applied to a memory CVE in a c++ application.
it also fiddles with your container's resolv.conf, which can cock stuff up really badly if you are using search domain.
There is a option to hardcode DNS and also an option to don't abstract networking and use host mode. Fiddling with your container's resolv.conf is necessary for docker networks between containers.
Indeed its configurable, but its not obvious! it was only when I was doing TCP dump on the host did I realise that docker was routing our containers to 8.8.8.8, rather than the proper DNS that we had specified.
How else did OP expect traffic to get to his containers? Magic?
edit to add: after reading the article completely, a few things stand out.
1. It is clear the author does not understand the details of the compose file and is new to Docker.
2. Proposed solution is also incomplete
3. Not understanding why you would want to wrap caddy (even though it's a static binary) in the same system is missing the point.
4. Blaming Docker for clear user error is crazy.
edit to add: after reading the article completely, a few things stand out.
1. It is clear the author does not understand the details of the compose file and is new to Docker.
2. Proposed solution is also incomplete
3. Not understanding why you would want to wrap caddy (even though it's a static binary) in the same system is missing the point.
4. Blaming Docker for clear user error is crazy.
Oh no I only expose ports on my tailnet. Or, I guess not then? How to check the status of the real firewall them, if ufw can mislead?
If you're legally allowed to run nmap against your host (eg some network places will have a real problem with it!) then it can be a useful way to check the "real world" reachability of ports.
After some testing, the port really only seems to be open on the tailnet, luckily.
If you’re exposing ports on your tailnet then you’re presumably binding to those specific interfaces, right?
Nope I use ufw to only allow incoming on the tailnet [0]. Guess that I’ll ben nmapping some hosts soon…
[0]: https://blog.hmrt.nl/posts/first_steps_arch_box/#set-up-tail...
[0]: https://blog.hmrt.nl/posts/first_steps_arch_box/#set-up-tail...
The docs, always the first place to look: https://docs.docker.com/network/iptables/
Other solution is to simply not expose ports directly with rocket compose and instead use something like Traefik to proxy them.
I’ve stopped using ports after having a redis instance taken over by some crypto miner.
I’ve stopped using ports after having a redis instance taken over by some crypto miner.
Traefik is a good idea for other reasons, but there's no problem with using Docker to directly expose ports.
You just need to ensure that you're only exposing the *right* ports, and aren't just blindly opening everything up to the world.
By default nothing is exposed to the world. You do not need to expose your Redis server's port to anything.
You just need to ensure that you're only exposing the *right* ports, and aren't just blindly opening everything up to the world.
By default nothing is exposed to the world. You do not need to expose your Redis server's port to anything.
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.
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.
Considering 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.
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.
It 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.
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.
If 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.
It's insane to build something that optimizes ease of use, and then require users to understand it in depth to avoid footgunning.
Docker is certainly not marketed that way & even the majority of tutorials / if not all on Digital ocean or similar sites don't misguide you into doing this. It is clearly not marketed as "usable without reading docs" and even though people using it as a tool to deploy prebuilt software without learning its configuration, this doesn't apply to the docker commands itself.
If https://www.portainer.io/ would do this implicitly, your argument would be more valid. But for the docker command-line it's a bit too far-fetched.
If https://www.portainer.io/ would do this implicitly, your argument would be more valid. But for the docker command-line it's a bit too far-fetched.
Honestly, I am not sure if you're right with the marketing but the docker way of “doing everything needed in a tightly coupled way” does reek of a tool that is designed primarily for ease of use.
Heck, this “issue” (which, I don’t agree is an issue) only exists so that people don't have to do an additional step. Its “ease of use” which violates the principle of least surprise most commonly.
Heck, this “issue” (which, I don’t agree is an issue) only exists so that people don't have to do an additional step. Its “ease of use” which violates the principle of least surprise most commonly.
The docker way is a way of using coontainers as a form of contained application building & distribution, which builds itself (optionally on top of layers from docker hub) from a Dockerfile and is configured by a docker-compose file, minimizing the need for external configuration tools that may have problems to keep up with new features. The other feature are the layered builds, which you can mix from multiple bases.
Docker does not compete with LXD which just runs containers like VMs, but with distrobuilder + LXD + including the init.yml in the deploy process.
Docker does not compete with LXD which just runs containers like VMs, but with distrobuilder + LXD + including the init.yml in the deploy process.
By 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.
You must explicitly expose them.
If you expose everything else too, that's no-one's fault but yours.
Just about everyone who describes Docker, including the Docker documentation itself, describes "exposing" a port as creating a "mapping" between ports in the container and ports on the host.
Furthermore, the "container networking" page (https://docs.docker.com/config/containers/container-networki...) says that Docker creates iptables rules for the purpose of creating this mapping.
The clear implication is that, say, "exposing" port 8080 should have similar behavior to simply running a program on the host that listens on port 8080. It does do that, but it also silently punches holes in your firewall, unless you make Docker-specific changes to your firewall config to work around it.
Even if a knowledgeable person reads the docs, and then sees something like "click here for the platform-specific details of how iptables rules are managed", I think it's entirely reasonable for them not to realize that those platform-specific details are in fact security-critical.
Furthermore, the "container networking" page (https://docs.docker.com/config/containers/container-networki...) says that Docker creates iptables rules for the purpose of creating this mapping.
The clear implication is that, say, "exposing" port 8080 should have similar behavior to simply running a program on the host that listens on port 8080. It does do that, but it also silently punches holes in your firewall, unless you make Docker-specific changes to your firewall config to work around it.
Even if a knowledgeable person reads the docs, and then sees something like "click here for the platform-specific details of how iptables rules are managed", I think it's entirely reasonable for them not to realize that those platform-specific details are in fact security-critical.
No. This is not the case. There is a different term that does what you mean: "publishing" a port. It's different from the "EXPOSE XYZ" syntax, and is used in the docker cli with the "-p" command.
Maybe a lesson learned from this conversation is that the documentation isn't clear about what's going on and should be updated.
The documentation is incredibly clear about this and does not need to be updated. It's mentioned multiple times. The beginning of the documentation offers information about the difference of publishing and exposing. The docker networking tab explicitly mentions that publishing a port means it's visible to the outside world.
Who is marketing it that way? That’s insane.
It really is. I am astonished by the simple mindedness of some people in this thread. Half knowledge really is dangerous.
No 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.
Expecting 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.
> 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.
It doesn't? You're explicitly telling it to do so and then go on crying about how docker is awful.
that's word for word from: https://docs.docker.com/config/containers/container-networki...
By 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.
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.
You'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/ [2] https://docs.docker.com/compose/compose-file/
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/ [2] https://docs.docker.com/compose/compose-file/
They have an absurd amount of detail, you just have to bother to actually read. Linked directly from the overview, after explaining why it’s not on the platform-independent explain, is exactly what you asked for.
Tl;dr - If you need to add rules which load before Docker’s rules, add them to the DOCKER-USER chain.
https://docs.docker.com/network/iptables/
Tl;dr - If you need to add rules which load before Docker’s rules, add them to the DOCKER-USER chain.
https://docs.docker.com/network/iptables/
All I'm saying is they can do a better job presenting the information so these things are more readily findable. People are calling this a footgun for a reason. And no, that link isn't mentioned in the docker overview page[1]. Unless you're talking about another overview, which... come on, lol.
Seriously, there's so much room for consolidation and accessibility of their documentation. In terms of relaying information on side effects and how to identify those side effects, this is so much less approachable than pandas and sqlalchemy documentation, and that's saying something.
[1] https://docs.docker.com/get-started/overview/
Seriously, there's so much room for consolidation and accessibility of their documentation. In terms of relaying information on side effects and how to identify those side effects, this is so much less approachable than pandas and sqlalchemy documentation, and that's saying something.
[1] https://docs.docker.com/get-started/overview/
People who read the docs aren’t calling these things footguns though. If you look through the comments section here it’s full of people saying the same thing I’m saying.
Just take the L and do the reading.
Just take the L and do the reading.
The fact that you can't admit that the documentation has wiggle room for improvement here is telling. But by all means keep thinking this was a competition deserving of Ls and continue to miss the simple point. Peace and good luck, friend.
I just wish you’d read the docs before deciding they’re bad. But feel free to creatively misinterpret responses as you see fit.
Doc updates aren’t free, let’s not waste effort fixing a problem that doesn’t exist when there are much better uses for that effort. Moving the words around isn’t going to effect their ability to be understood by those who refuse to actually put eyes on them.
Doc updates aren’t free, let’s not waste effort fixing a problem that doesn’t exist when there are much better uses for that effort. Moving the words around isn’t going to effect their ability to be understood by those who refuse to actually put eyes on them.
Read the documentation. That's really all you had to do. The docs are clear.
They mention that the port will be published to the internet. Usage of iptables is implementation detailed. They say to make sure to secure it. What else do you want? There is documentation on the behavior in the “docker for Linux” page
I want a damn mention of exactly what is changing on my system!! Why is that hard to understand and why are you trivializing such a big change? This isn't like a config file change that's OS implementation dependent. It's a freaking firewall change that has no obvious mention anywhere in its documentation! That's huge!
Well, here you go I guess? https://docs.docker.com/network/iptables/
I found this right in the docker for linux documentation.
Can I ask, how else would you expect traffic to arrive at your container when you publish a port on the internet?
I found this right in the docker for linux documentation.
Can I ask, how else would you expect traffic to arrive at your container when you publish a port on the internet?
Failed 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.
Maybe he also smells bad some days. So what? Docker is still wrong, and further, more wrong than the user.
No. 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.
> 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.
Same thing 90% of people do.
If 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.
Use podman and ditch docker, you can even alias it.
How else would you expect it to NAT traffic into and out of the containers' network namespaces?
Remember UPnP? Good times.
The difference between this and UPnP is that this is a program opening firewall rules on the computer it's running on, whereas UPnP let programs open firewall rules on other devices.
A... program? You know that Docker containers are self-contained operating systems?
The whole point of containers like Docker is to separate the allocation and control of resources via a middle way that is not quite virtualization. So a monolithic OS running on one computer is at one end of the spectrum, and a "separate hardware device" accessible by LAN is further along the spectrum, but it's a continuum.
So I feel like Docker's control of the host OS presents a similar surprise to us today as we felt when UPnP was in control of networked devices a few decades ago.
To a Docker or UPnP expert, it's just another fact of provisioning the application's resources. UPnP has often been deployed at the hands of inexperienced users, and so it is with Docker.
The whole point of containers like Docker is to separate the allocation and control of resources via a middle way that is not quite virtualization. So a monolithic OS running on one computer is at one end of the spectrum, and a "separate hardware device" accessible by LAN is further along the spectrum, but it's a continuum.
So I feel like Docker's control of the host OS presents a similar surprise to us today as we felt when UPnP was in control of networked devices a few decades ago.
To a Docker or UPnP expert, it's just another fact of provisioning the application's resources. UPnP has often been deployed at the hands of inexperienced users, and so it is with Docker.
> You know that Docker containers are self-contained operating systems?
That doesn't qualify as a program?
That doesn't qualify as a program?
Well, if it's 1983, and the Master Control Program is after you, be careful not to get de-rezzed.
"Hey, I got a new program to install on my computer!" "What's your new program called?" "This program is... Ubuntu Linux."
"Hey, I got a new program to install on my computer!" "What's your new program called?" "This program is... Ubuntu Linux."
K8s at least offers more fine-grained control over networking, between port range restrictions and having to enable a NodePort.