91–100 of 126 posts
Earlier quoted context omitted.
What's asinine is "I configured it wrong and it broke, it's a bug in docker".
Maybe inform yourself of the situation and consider again carefully. Should all programs running as root bypass a firewall explicitly configured by the user?
Earlier quoted context omitted.
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 r…
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.
Earlier quoted context omitted.
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…
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
Earlier quoted context omitted.
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. ;) Th…
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.
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. :(
Earlier quoted context omitted.
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…
Tl;dr - If you need to add rules which load before Docker’s rules, add them to the DOCKER-USER chain.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
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/
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.
Earlier quoted context omitted.
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/
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…
Just take the L and do the reading.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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.
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.
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.