Hacker News Reader

Comment by Gordonjcp | Hacker News Reader

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.

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.

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"?

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?

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.

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.

This is exactly right. The alternative is ridiculous.

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?

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 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.

> 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.

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?

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...

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.

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...

Yes, if the command you ask them to perform connects to the public interface.

Reply on news.ycombinator.com