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.
K8s at least offers more fine-grained control over networking, between port range restrictions and having to enable a NodePort.