101–110 of 126 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.
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?
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.
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...
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.
Earlier quoted context omitted.
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. :(
What did you do, what did you get wrong, and why did it need "cleaned up"?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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 understa…
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.
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.