Docker ist für viele Entwickler und Unternehmen das Synonym für einfache und effiziente Containerisierung. Mit der Veröffentlichung von Docker Engine Version 28 setzt das Team einen wichtigen Meilenstein im Bereich der Sicherheit, speziell im Netzwerkmanagement von Containern. Durch die standardmäßige Härtung der Container-Netzwerke wird verhindert, dass Container unbeabsichtigt aus lokalen Netzwerken erreichbar sind, was zuvor eine potenzielle Schwachstelle darstellte. Diese Sicherheitsänderung ist besonders relevant für Linux-Anwender, da Docker Desktop von dieser Neuerung nicht betroffen ist. Die Ausgangslage vor Docker Engine v28 war so, dass Docker beim Erstellen eines Containers auf dem Standard-Bridge-Netzwerk NAT-Regeln über iptables konfiguriert hat. Das bedeutet, dass veröffentlichte Ports, die explizit durch den Nutzer freigegeben werden, über das Hostsystem erreichbar sind.
Wenn jedoch die Firewall-Regel für die FORWARD-Kette permissiv auf ACCEPT gesetzt war und die IP-Weiterleitung aktiviert war, konnten Container über ihren internen IP-Bereich auf lokalem Netzwerkzugriff zugänglich sein – selbst wenn der jeweilige Port nicht veröffentlicht wurde. Dieses Problem betrifft vor allem Nutzer, die in Mehrmandanten-LAN-Umgebungen oder allgemein in gemeinsam genutzten lokalen Netzwerken unterwegs sind. Ein Angreifer mit Zugriff auf dasselbe RFC1918-Subnetz, etwa aus den Bereichen 192. 168. x. x oder 10. x, konnte unter Umständen nicht veröffentlichte Ports von Containern durch direktes Routing erreichen, sofern er die IP-Adressen der Container erraten oder ermitteln konnte. Diese Sicherheitslücke war bisher schwer auszuschließen, da sie von vorteilhaften Standard-Firewall-Regeln auf dem Hostsystem abhing.
Insbesondere Nutzer, die das Hostsystem bewusst mit einer offenen FORWARD-Kette konfiguriert hatten und über lokale Netzwerke direkte IP-Zugriffe auf Container nutzten – etwa für spezifische Entwicklungs- oder Routingzwecke – waren hiervon betroffen. Die Folge war, dass Container, die nicht explizit über -p oder --publish-Flags gebunden waren, von anderen Geräten im lokalen Netzwerk potenziell erreichbar waren. Die engere Umgebung blieb damit anfällig für unautorisierte Verbindungen von unbekannten Hosts im gleichen Netzwerksegment. Docker Engine 28 antwortet darauf mit einem sicherheitsorientierten Standardverhalten: Unveröffentlichter Containerverkehr auf deren interne IP-Adressen wird nun standardmäßig blockiert. Das heißt, nur explizit veröffentlichte Ports sind aus dem Netzwerk heraus abrufbar, während alle anderen Verbindungen verworfen werden.
Dieses “Secure by Default”-Prinzip minimiert die Angriffsfläche auf den Containerbetrieb berechtigten Endpunkten drastisch, ohne die gängige Docker-Nutzung zu behindern. Auch Verbindungen vom Host-System selbst auf Container-IP-Adressen sind weiterhin möglich, womit eingespielte Abläufe erhalten bleiben. Für Administratoren und Entwickler, die den alten Zustand benötigen und auf direkte IP-Zugriffe über das LAN angewiesen sind, bietet Docker v28 flexible Opt-out-Mechanismen: Über die Konfigurationsdatei /etc/docker/daemon. json lässt sich mit dem Parameter „ip-forward-no-drop“ das standardmäßige Droppen deaktivieren. Alternativ ist die Erstellung eines speziellen Bridge-Netzwerks mit dem Modus „nat-unprotected“ möglich, welches die neuen Sperren für nicht veröffentlichte Ports aufhebt. Damit ermöglicht Docker sowohl ein hohes Maß an Sicherheit als auch weiterhin die nötige Flexibilität für besondere Netzwerk- und Entwicklungsanforderungen.
Nutzer komplexerer Umgebungen oder individueller Firewalleinstellungen werden dazu ermutigt, eigene iptables-Regeln vorzunehmen, um präzise Steuerungen zu realisieren. Allerdings setzt dies fundiertes Wissen im Bereich Netzwerksicherheit voraus, um keine unbeabsichtigten Sicherheitslücken zu schaffen. Die Motivation hinter dieser Veränderung resultiert aus jahrelangen Diskussionen und dem zunehmenden Sicherheitsbedarf in professionellen Container-Umgebungen. Früher waren viele Docker-Setups einfache Einzelmaschinen, bei denen offene FORWARD-Ketten wenig Risiko erzeugten. Mittlerweile dominieren komplexe Multi-Host-Netzwerke, Container-Orchestrierungen und cloudbasierte Infrastrukturen die Landschaft, in denen explizite Sicherheitskontrollen essenziell sind. Docker hat mit Version 28 nun Sicherheitsverhalten implementiert, das der modernen Realität gerecht wird: Container-Ressourcen werden grundsätzlich nicht exponiert, es sei denn, der Nutzer entscheidet sich bewusst dafür.
Diese stärkere Trennung macht die Umgebung insgesamt vertrauenswürdiger und reduziert das Risiko versehentlicher Angriffe aus lokalen Netzwerken. Für Anwender, die ein Upgrade planen, empfiehlt Docker, ihre bestehenden Firewall-Regeln vorab genau zu überprüfen. Insbesondere sollten Nutzer der offenen FORWARD-Kette bedenken, inwieweit sie auf bisher frei erreichbare Container zugreifen, um Unterbrechungen des Workflows zu vermeiden. In einer Testumgebung lässt sich vorab simulieren, welche Verbindungen durch die neuen Regeln blockiert werden, und ob die notwendige Konfiguration gegeben ist. Die Community und die Docker-Entwickler empfehlen dringend, die neuen Defaults zu akzeptieren, um die Sicherheit auf einem hohen Niveau zu halten, anstatt das frühere Verhalten zu erzwingen. In Summe vergrößert Docker mit Engine v28 die Sicherheitseinbußen für Unternehmen und Privatanwender gleichermaßen, ohne Rückschritte im Bedienkomfort zu machen.
Container sind so besser gegen unautorisierte Zugriffe innerhalb desselben physischen Netzwerks geschützt. Darüber hinaus sorgen klare Abgrenzungen zwischen veröffentlichten und unveröffentlichten Ports für eine konsistente und transparente Netzwerkzugriffssteuerung, die jetzt standardmäßig über iptables umgesetzt wird. Anwender profitieren im Alltag von weniger Sorgen um heimliche Angriffe auf Containerdienste und können Bereiche wie Entwicklung, Testing und Produktion noch sicherer betreiben. Die Docker-Community wurde bereits intensiv in diesen Wandlungsprozess eingebunden, was zu einer reibungslosen Umstellung beiträgt. Auch die Dokumentation und der Support wurden angepasst, um einen möglichst unkomplizierten Übergang zu gewährleisten. Trotz der erhöhten Standards erhalten Nutzer die Möglichkeit, bei Bedarf per Konfiguration oder neu erstellten Netzwerken individuelle Sicherheitsprofile zu realisieren.
Docker unterstreicht damit einen aktuellen Trend in der Container- und Cloud-Technology: Die Vereinfachung von Sicherheit durch sichere Voreinstellungen, anstatt Sicherheit zum optionalen Nachdenken zu machen. Die Veröffentlichung von Docker Engine v28 ist demnach mehr als ein Update, es ist ein klares Signal in Richtung moderner, sicherer Container-Infrastrukturen, die den Schutz von Anwendungen und Daten aktiv in den Mittelpunkt stellen und gleichzeitig die agile Nutzung erleichtern. Wer bereits mit Docker arbeitet, sollte daher zeitnah auf Version 28 oder höher umsteigen, um von den verbesserten Schutzmechanismen zu profitieren und weiterhin ein sichereres Netzwerk für seine Container zu gewährleisten. Die neuen Funktionen sind ein wertvoller Baustein in der stetigen Evolution von Docker zu einer profi-orientierten Plattform mit höchsten Sicherheitsansprüchen und zugleich einer angenehmen Nutzbarkeit für Entwickler rund um den Globus.
