3 ms·

So many gotchas in today's world. Recently it turned out that docker-compose.yaml was helpfully exposing our DB to our local LAN (which is an entire company th

So many gotchas in today's world. Recently it turned out that docker-compose.yaml was helpfully exposing our DB to our local LAN (which is an entire company that has nothing to do with our dev work), despite restricting all in and out traffic to our tailnet with UFW. I know it's a known issue, it comes up here every now and then, we kept it in mind and even talked about it. But as soon as someone uses an "expose" in a docker-compose.yaml, you're f-ed. Sure, you should keep the containers talking within the docker network, but we are kind of distributed in our org (across a series of NUCs). I find it annoying that is has come to this. Now considering Podman, or VMs (to use a host firewall around the virtual stuff).

jhardy54 2y ago
Are you binding to 127.0.0.1 or 0.0.0.0? > Sure, you should keep the containers talking within the docker network, but we are kind of distributed in our org (across a series of NUCs). I don’t think I understand this, are you saying that you want the ports exposed to some devices on your network but not others?
- teekert 2y ago
  In docker-compose it's just "- ports", I guess it's always 0.0.0.0, unless bound to something else (like 127.0.0.1). You can restrict it to the Tailnet IP, but then you have to hardcode the Tailscale 100.x.x.x IP address (not flexible).
nonameiguess 2y ago
The real issue here is Linux overloading netfilter to implement both overlay networking so you can address virtual interfaces in network namespaces, and traffic blocking rules, so host-based firewalls like ufw and containerized networking implementations like Docker and Kubernetes more or less have to assume they have full control of your filter chains and it's up to you as a server admin to deconflict. The best answer is usually not to use any kind of host-based firewall if you're doing container networking and use a network firewall instead.

jhardy54 2y ago

Are you binding to 127.0.0.1 or 0.0.0.0? > Sure, you should keep the containers talking within the docker network, but we are kind of distributed in our org (across a series of NUCs). I don’t think I understand this, are you saying that you want the ports exposed to some devices on your network but not others?

teekert 2y ago
In docker-compose it's just "- ports", I guess it's always 0.0.0.0, unless bound to something else (like 127.0.0.1). You can restrict it to the Tailnet IP, but then you have to hardcode the Tailscale 100.x.x.x IP address (not flexible).

nonameiguess 2y ago

The real issue here is Linux overloading netfilter to implement both overlay networking so you can address virtual interfaces in network namespaces, and traffic blocking rules, so host-based firewalls like ufw and containerized networking implementations like Docker and Kubernetes more or less have to assume they have full control of your filter chains and it's up to you as a server admin to deconflict. The best answer is usually not to use any kind of host-based firewall if you're doing container networking and use a network firewall instead.