Docker was not designed with security in mind, and on any host exposed to the internet a massive security risk because of this. Putting someone in the `docker` group is nearly equivalent to giving them root permissions.
K8s at least offers more fine-grained control over networking, between port range restrictions and having to enable a NodePort.
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.
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.
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 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".
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.
> 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.
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.
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.
> 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. :(
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.
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 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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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"?!
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.
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.
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.
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.
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!
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.
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.
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.
K8s at least offers more fine-grained control over networking, between port range restrictions and having to enable a NodePort.