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 exposing ports on your tailnet then you’re presumably binding to those specific interfaces, right?
I just learned: Docker edits firewall rules for you
71–80 of 126 posts
Re: I just learned: Docker edits firewall rules for you
#72Earlier quoted context omitted.
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 r…
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 doc…
This is exactly right. The alternative is ridiculous.
Also, comparing expectations of Docker vs. something like nginx is crazy.
Re: I just learned: Docker edits firewall rules for you
#73How 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.
Re: I just learned: Docker edits firewall rules for you
#74it 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.
Re: I just learned: Docker edits firewall rules for you
#75Remember 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.
Re: I just learned: Docker edits firewall rules for you
#76Earlier quoted context omitted.
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.
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 imp…
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.
Re: I just learned: Docker edits firewall rules for you
#77Earlier quoted context omitted.
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…
> You know that Docker containers are self-contained operating systems?
That doesn't qualify as a program?
Re: I just learned: Docker edits firewall rules for you
#78Earlier quoted context omitted.
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.
Re: I just learned: Docker edits firewall rules for you
#79I 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
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.
Re: I just learned: Docker edits firewall rules for you
#80Docker 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.
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.