Locking Down Your Docker Containers: A Simple Yet Powerful Solution

I’ve been playing around with various AI tools and self-hosted apps lately, and I have to admit, it’s been a wild ride. From local AI assistants to code completion servers, these tools have been super useful, but they also come with a significant amount of risk. I mean, think about it – when you’re using something like OpenCode with MCP servers, you’re basically giving it an open door to your entire system and network.

That’s why I was thrilled to stumble upon a solution that could help me restrict my Docker containers to specific domains only. It’s called network-filter, and it’s a Docker container that acts like a strict firewall for your other containers. You tell it exactly which domains are allowed, and it blocks everything else at the network level.

How it Works

The cool part about network-filter is that it uses iptables and dnsmasq under the hood to drop all traffic except what you explicitly whitelist. No proxy shenanigans, just straight network-level blocking. You can even specify ports per domain, which is really useful for fine-grained control.

I’ve been using network-filter for a few different use cases, including:

• LLM tools with MCP servers that could potentially access anything
• AI coding assistants that have filesystem access but shouldn’t reach random endpoints
• Self-hosted apps I want to try but don’t fully trust

Setup is a Breeze

Setting up network-filter is dead simple. You just need to create a YAML file with the following configuration:

services:
  network-filter:
    image: monadical/network-filter
    environment:
      ALLOWED_DOMAINS: "api.openai.com:443,api.anthropic.com:443"
    cap_add:
      - NET_ADMIN
  my-app:
    image: my-app:latest
    network_mode: "service:network-filter"

The magic happens with the network_mode: "service:network-filter" line, which tells my-app to use the same network interface as network-filter. This means that my-app will only be able to access the domains that I’ve explicitly whitelisted.

Limitations and Future Plans

Right now, network-filter only supports IPv4, and all containers sharing the network get the same restrictions. However, for isolating these tools, that’s been fine for me. The creator of network-filter has mentioned that they plan to add support for IPv6 in the future, which will be a great addition.

I’d love to hear from others who have been thinking about this problem, especially with MCP servers becoming more common. How are you handling the security implications of giving AI tools such broad access? Have you found any other solutions that work well for you?

You can check out the network-filter project on GitHub and try it out for yourself.

Zabezpieczanie Kontenerów Docker: Prosta, Lecz Potężna Rozwiązanie

Bawiam się różnymi narzędziami AI i aplikacjami self-hosted od jakiegoś czasu, i muszę przyznać, że to było dzikie przeżycie. Od lokalnych asystentów AI po serwery uzupełniania kodu, te narzędzia były bardzo przydatne, ale także niosą ze sobą znaczne ryzyko. Myślę, że można to porównać do otwarcia drzwi do całego systemu i sieci, gdy używa się czegoś takiego jak OpenCode z serwerami MCP.

Dlatego byłam szczęśliwa, gdy natrafiłam na rozwiązanie, które mogło mi pomóc w ograniczeniu moich kontenerów Docker do określonych domen. Nazywa się network-filter, i jest to kontener Docker, który działa jak ścisły firewall dla innych kontenerów. Wskazujesz mu dokładnie, które domeny są dozwolone, i blokuje wszystko inne na poziomie sieciowym.

Jak To Działa

Fajna rzecz w network-filterze jest to, że wykorzystuje iptables i dnsmasq pod spodem, aby upuścić cały ruch, z wyjątkiem tego, który jest jawnie dozwolony. Żadnych sztuczek z proxy, tylko proste blokowanie na poziomie sieciowym. Można nawet określać porty dla każdej domeny, co jest bardzo przydatne do dokładnej kontroli.

Używam network-filtera w kilku różnych przypadkach, w tym:

• Narzędzia LLM z serwerami MCP, które mogą potencjalnie uzyskać dostęp do wszystkiego
• Asystenci kodowania AI, którzy mają dostęp do systemu plików, ale nie powinni mieć dostępu do losowych punktów końcowych
• Aplikacje self-hosted, które chcę wypróbować, ale którym nie całkowicie ufam

Konfiguracja To Łatwa Sprawa

Ustawienie network-filtera jest bardzo proste. Wystarczy utworzyć plik YAML z następującą konfiguracją:

services:
  network-filter:
    image: monadical/network-filter
    environment:
      ALLOWED_DOMAINS: "api.openai.com:443,api.anthropic.com:443"
    cap_add:
      - NET_ADMIN
  my-app:
    image: my-app:latest
    network_mode: "service:network-filter"

Cudem jest linia network_mode: "service:network-filter", która mówi my-app, aby używał tej samej sieci, co network-filter. To oznacza, że my-app będzie mógł uzyskać dostęp tylko do tych domen, które zostały jawnie dozwolone.

Ograniczenia i Planowane Rozwinięcia

Na razie network-filter obsługuje tylko IPv4, i wszystkie kontenery dzielące sieć mają te same ograniczenia. Jednak dla izolowania tych narzędzi, to było dla mnie wystarczające. Twórca network-filtera wspomniał, że planuje dodać obsługę IPv6 w przyszłości, co będzie wielkim ulepszeniem.

Chciałabym usłyszeć od innych, którzy myśleli o tym problemie, zwłaszcza z serwerami MCP, które stają się coraz bardziej powszechne. Jak radzicie sobie z implikacjami bezpieczeństwa, gdy dajecie narzędziom AI tak szeroki dostęp? Czy znaleźliście jakieś inne rozwiązania, które działają dla was?

Można sprawdzić projekt network-filter na GitHubie i wypróbować go samemu.