Sie können Docker monatelang ohne sichtbare Probleme in der Produktion ausführen. Container starten, Apps reagieren, nichts geht kaputt. Dann verschafft ein offengelegter Port oder eine falsch konfigurierte Berechtigung Fuß, den ein Angreifer nicht erarbeiten musste. Die meisten Docker-Sicherheitsfehler sehen erst dann wie Fehler aus, wenn etwas schief geht.
Dieser Artikel behandelt die spezifischen Konfigurationen, die Containerumgebungen gefährden, und was jede einzelne für einen Angreifer ermöglicht. Der Artikel schließt mit einer Checkliste, die Sie noch heute mit Ihrem eigenen Setup abgleichen können.
Warum Docker-Sicherheit schwieriger ist, als es aussieht
Container fühlen sich isoliert an. Sie starten einen, er führt seinen eigenen Prozessraum aus und der nächste Container existiert darin nicht. Sie werden zwar isoliert, aber nur teilweise. Container teilen sich den Kernel des Hosts, was bedeutet, dass ein Prozess innerhalb eines Containers unter bestimmten Bedingungen das Hostsystem vollständig erreichen kann.
Docker-Schiffe sind für den Entwicklerkomfort und nicht für die Produktionshärtung konfiguriert. Root-Zugriff aktiviert. Alle Ports können an alle Schnittstellen gebunden werden. Keine Laufzeitüberwachung. Die meisten Entwickler akzeptieren diese Einstellungen, versenden den Container und fahren fort. Das ist ein vernünftiger Ansatz für den Einstieg; Es handelt sich nicht um eine fertige Sicherheitslage.
Entsprechend Red Hats Bericht „State of Kubernetes Security“ 202467 % der Unternehmen verzögerten oder verlangsamten die Anwendungsbereitstellung aufgrund von Bedenken hinsichtlich der Container- oder Kubernetes-Sicherheit. Diese Reibung ist normalerweise nicht auf Angriffe zurückzuführen. Es kommt von Teams, die feststellen, dass ihre Container-Setups eine Härtung benötigen, die sie nicht eingebaut haben.
Wir sehen oft, dass Container in der Produktion mit derselben Konfiguration ausgeführt werden, die sie auf dem lokalen Computer eines Entwicklers hatten. Hier verstärken sich Docker-Sicherheitsfehler in der Regel im Stillen, ohne sichtbare Symptome, bis etwas geprüft wird oder fehlschlägt.
Die Fehler, die zu diesen Lücken führen, sind spezifisch, vorhersehbar und größtenteils vermeidbar, beginnend auf der Konfigurationsebene.
Häufige Fehler bei der Docker-Konfiguration
Die meisten Containerverstöße beginnen nicht mit einem Zero-Day-Exploit. Sie beginnen mit einer Konfiguration, die am ersten Tag festgelegt wurde, ohne viel über die Netzwerkexposition oder den Umfang der Berechtigungen nachzudenken.
Die standardmäßigen Docker-Einstellungen sind so konzipiert, dass sie funktionieren. In der Lücke zwischen Funktionalität und Sicherheit häufen sich die Sicherheitsrisiken für Docker-Container, insbesondere bei selbst gehosteten Setups, die bereitgestellt und nie wieder überprüft werden.
Wir sehen dieses Muster häufig: Container auf öffentlichen IP-Servern mit Portbindungen, Benutzereinstellungen und Netzwerkkonfigurationen genau so, wie sie bei der ersten Bereitstellung waren.
Container als Root ausführen
Wenn Sie einen Docker-Container starten, ohne einen Benutzer anzugeben, wird er als Root ausgeführt. Das bedeutet, dass jeder Prozess innerhalb des Containers, einschließlich Ihrer Anwendung, über Root-Rechte im Namensraum des Containers verfügt.
Root innerhalb eines Containers ist nicht dasselbe wie Root auf dem Host, aber die Trennung ist nicht absolut. Exploits zur Rechteausweitung, die auf die Laufzeit abzielen, wie der gut dokumentierte runc CVE-2019-5736 und ähnliche Laufzeitfehler, erfordern häufig einen Root-Container-Prozess, um erfolgreich zu sein.
Nicht-Root-Container beseitigen die Root-Prozessanforderung, von der diese Exploits abhängen, wodurch die Angriffsfläche für diese Schwachstellenklasse erheblich verringert wird, das Container-Escape-Risiko jedoch nicht vollständig beseitigt wird.
Durch Hinzufügen einer USER-Direktive zu Ihrer Docker-Datei wird dieses Problem behoben. Einige offizielle Images werden mit einem nicht privilegierten Benutzer ausgeliefert, den Sie mit einer USER-Anweisung aktivieren können, aber viele verwenden immer noch standardmäßig Root ohne vorgefertigten App-Benutzer. In diesen Fällen erstellen Sie den Benutzer in der Docker-Datei, bevor Sie dorthin wechseln. Bei den meisten selbstgehosteten Setups beseitigt diese einzige Änderung eine ganze Kategorie von Eskalationsrisiken.
Zu viele Ports dem öffentlichen Internet zugänglich machen
Wenn Sie einen Port mit Docker veröffentlichen, schreibt Docker direkt seine eigenen iptables-Regeln. Diese Regeln werden vor Firewallregeln auf Hostebene ausgeführt. Das ist ein bekanntes Verhalten, das von der Community gemeldet wurde Und dokumentiert im Paketfilter-Leitfaden von Docker, keine Fehlkonfiguration, und es bedeutet, dass UFW und ähnliche Tools nicht blockieren, was Docker bereits geöffnet hat.
Docker schreibt direkt in iptables und umgeht dabei die UFW- und Firewalld-Standardeinstellungen auf vielen Linux-Hosts. Das bedeutet, dass ein an 0.0.0.0 gebundener Port öffentlich erreichbar sein kann, selbst wenn Ihre Firewall konfiguriert zu sein scheint. Cloud-Sicherheitsgruppen und DOCKER-USER-Kettenregeln können diesen Datenverkehr weiterhin blockieren, sodass die tatsächliche Gefährdung von Ihrem spezifischen Netzwerk-Setup abhängt.
Binden Sie Dienste nach Möglichkeit an 127.0.0.1, leiten Sie öffentlich zugänglichen Datenverkehr über einen Reverse-Proxy und veröffentlichen Sie nur das, was wirklich externen Zugriff erfordert. Ein Reverse-Proxy ist die zuverlässigste Möglichkeit, zu kontrollieren, was von außerhalb des Hosts offengelegt wird.
Ignorieren der Netzwerkisolation zwischen Containern
Jeder Container in diesem Netzwerk kann jeden anderen Container darin ohne Einschränkung erreichen. Die Standardbrücke wendet keine Datenverkehrsfilterung zwischen Containern an, die sie gemeinsam nutzen, und die meisten Setups ändern diese Konfiguration nie.
Wenn ein Container kompromittiert wird, wird diese offene Kommunikation zu einem lateralen Bewegungspfad. Ein Frontend-Container kann eine Datenbank, eine interne API oder alles andere im selben Standard-Bridge-Netzwerk erreichen, auch wenn dieser Zugriff nie beabsichtigt war.
Benutzerdefinierte Netzwerke geben Ihnen explizite Kontrolle darüber, welche Container kommunizieren können, aber ein einziges benutzerdefiniertes Netzwerk, das von allen Ihren Diensten gemeinsam genutzt wird, ermöglicht weiterhin freien Datenverkehr zwischen Containern. Für eine echte Isolation müssen Dienste, die nicht miteinander kommunizieren sollten, in getrennten Netzwerken untergebracht werden. Das Ausschalten der Standardbrücke ist der Ausgangspunkt, nicht die Ziellinie.
Mit Blick auf den Docker-Socket
Der Docker-Socket unter /var/run/docker.sock ist die Steuerschnittstelle für die gesamte Docker-Engine. Durch die Einbindung in einen Container erhält dieser Container direkten API-Zugriff auf den Daemon, der auf dem Host ausgeführt wird.
Mit diesem Zugriff kann ein Container neue Container starten, Host-Verzeichnisse bereitstellen, laufende Container überprüfen und ändern und den Host-Computer effektiv steuern. Die Angriffsfläche entspricht Root auf dem Host, weshalb jedes Tool, das Socket-Zugriff erfordert, sorgfältig geprüft werden muss.
Für die meisten Anwendungsfälle gibt es sicherere Alternativen: bereichsbezogene APIs oder Docker-Verwaltungstools die keinen Socket-Zugriff erfordern. Docker-in-Docker bringt seine eigenen Sicherheits- und Betriebskompromisse mit sich und ist kein einfacher Ersatz.
Konfigurationsfehler verursachen die anfängliche Belichtung. Bild- und Abhängigkeitsentscheidungen bestimmen, wie sich diese Belichtung im Laufe der Zeit verstärkt.
Image- und Secrets-Fehler, die den Container überdauern
Wenn Sie einen Container stoppen, werden auch die darin enthaltenen Konfigurationsfehler gestoppt. Wenn Sie ein Image neu erstellen, das eine Schwachstelle oder fest codierte Anmeldeinformationen enthält, beginnt das Problem erneut mit dem Container. Fehler auf Bildebene werden zwischen Bereitstellungen nicht zurückgesetzt.
Sie reisen mit dem Image zu jeder Umgebung, die es abruft, zu jeder Registrierung, die es speichert, und zu jedem Teammitglied, das es ausführt. Diese Beständigkeit macht die Image- und Secrets-Verwaltung zu einer eigenständigen Risikokategorie, die getrennt von der Konfiguration geprüft werden sollte.
Wir sehen dieses Muster oft: ein Image, das zu Beginn des Projekts sorgfältig ausgewählt und seitdem nie wieder erstellt wurde und langsam von der Sicherheitsgrundlinie abweicht, die es ursprünglich darstellte.
Verwendung nicht vertrauenswürdiger oder veralteter Bilder
Öffentliche Register stehen jedem offen. Über Docker Hub wurden schädliche Bilder verbreitet, die Krypto-Miner und Hintertüren enthalten, die in den Layer-Verlauf eingebettet sind und über Container-Neustarts hinweg bestehen bleiben. Überprüfung vor dem Abrufen, insbesondere bei Bildern von inoffiziellen oder unbekannten Herausgebern.
Das separate Problem ist die Abgestandenheit. Ein offizielles Image, das Sie vor sechs Monaten erstellt und seitdem nie wieder erstellt haben, häuft mit jedem CVE, das für seine Pakete offengelegt wird, ungepatchte Docker-Schwachstellen an. Das Bild ist nicht kaputt. Es ist einfach nicht mehr aktuell.
Sonatypes Bericht zum Stand der Software-Lieferkette 2024 fanden heraus, dass in 95 % der Fälle eine anfällige Komponente verbraucht wird, eine reparierte Version bereits verfügbar ist und 80 % der Anwendungsabhängigkeiten über ein Jahr lang nicht aktualisiert werden. Dieses Muster ist auch für Docker-Basisimages relevant, da diese auf denselben Open-Source-Paketen basieren.
Verwenden Sie offizielle Bilder von verifizierten Herausgebern und pinnen Sie bestimmte Versions-Tags, anstatt sich auf „Neueste“ zu verlassen. Erstellen Sie einen regelmäßigen Aktualisierungsrhythmus, um Ihre Bilder auf dem neuesten Stand zu halten.
Geheimnisse der Hardcodierung in Dockerfiles und Compose-Dateien
Anmeldeinformationen, die in eine Dockerfile-ENV- oder ARG-Anweisung geschrieben, in einen Compose-Umgebungsblock fest codiert, als Build-Argumente übergeben oder in einer der Versionskontrolle übergebenen .env-Datei gespeichert werden, verschwinden nicht, wenn Sie den Container stoppen. Sie bleiben im Verlauf der Bildebene oder in der Quellcodeverwaltung und sind für jeden zugänglich, der darauf zugreifen kann.
Dies ist einer der am häufigsten übersehenen Docker-Sicherheitsfehler, da er während der Entwicklung keine sichtbaren Probleme verursacht. Ein API-Schlüssel in einer ENV-Anweisung funktioniert ordnungsgemäß. Es befindet sich auch in Ihrem Repository, ist in Ihr Bild integriert und wird überall dort verteilt, wo das Bild übertragen wird.
Modern Docker Compose unterstützt einen nativen Secrets-Mechanismus, der Anmeldeinformationen zur Laufzeit bereitstellt, ohne sie in das Image einzubinden. Die Secrets-API von Docker und externe Secrets-Manager folgen demselben Prinzip. Dies sind die Optionen, die Anmeldeinformationen vollständig von Build-Artefakten und festgeschriebenen Dateien fernhalten.
Laufzeitumgebungsvariablen stellen eine Verbesserung gegenüber fest codierten Anmeldeinformationen dar, werden jedoch weiterhin durch Docker-Inspect-Ausgaben, Protokolle und Absturzdumps offengelegt. Sie sind ein Fortschritt gegenüber eingebrannten Geheimnissen und keine fertige Lösung.
Containerbilder werden nicht regelmäßig aktualisiert
Es ist eine weitverbreitete Angewohnheit, monatelang dasselbe Bild zu verwenden. Jeder Tag, der vergeht, nachdem eine neue Schwachstelle aufgedeckt wurde, aber bevor Sie sie neu erstellen, weisen Ihre Container ein Gefährdungsfenster auf, das ohne sichtbare Veränderung wächst.
Erstellen Sie einen konsistenten Wiederaufbauplan. Automatisieren Sie diesen Prozess nach Möglichkeit und führen Sie regelmäßig einen Schwachstellenscanner für Ihre aktuellen Bilder durch. Das Ziel ist nicht Perfektion. Es verkürzt die Zeit zwischen der Veröffentlichung eines Patches und seiner Bereitstellung.
Bei schnellen Bereitstellungen können Zugriffskontrolle und -überwachung an Priorität verlieren. Dies sind auch die Kategorien, in denen Vorfälle am längsten unentdeckt bleiben.
Zugangskontroll- und Sichtbarkeitslücken
Nachdem ein Container mit einer soliden Konfiguration und aktuellen Images ausgeführt wird, bleiben zwei Kategorien von Fehlern bestehen. Beides ist von Natur aus unsichtbar: Sie werden ein schwaches Zugriffskontrollproblem erst bemerken, wenn jemand es verwendet, und Sie werden keine Überwachungslücke bemerken, bis Sie Aktivitäten untersuchen müssen, die nie protokolliert wurden.
Das gleiche Red Hat 2024-Forschung fanden heraus, dass 42 % der Teams nicht über ausreichende Fähigkeiten verfügten, um die Containersicherheit und damit verbundene Bedrohungen anzugehen.
Wir stellen fest, dass Überwachungslücken typischerweise bei der Untersuchung von Vorfällen auftauchen, nicht vorher. Wenn Sichtbarkeit zur Priorität wird, geht es oft eher darum, auf etwas zu reagieren, als es zu verhindern.
Schwache Authentifizierung und ungeschützte Management-Dashboards
Für ein Container-Management-Dashboard auf einer öffentlichen IP ohne Authentifizierung ist kein raffinierter Angreifer erforderlich. Dazu ist es erforderlich, dass sie die Adresse kennen. Das ist eine niedrigere Messlatte, als den meisten Teams bewusst ist.
Selbstgehostete Überwachungs- und Verwaltungstools werden normalerweise mit einer Weboberfläche ausgeliefert, auf die über alle Netzwerkschnittstellen zugegriffen werden kann. Diese ohne Authentifizierung auf einer öffentlichen IP zu belassen, ist das Container-Äquivalent dazu, ein Admin-Panel entsperrt zu lassen.
Authentifizierung, ein Reverse-Proxy und die Platzierung in einem privaten Netzwerk bilden die Grundlage. Bei der Zugriffskontrolle handelt es sich um einen Konfigurationsschritt, den Sie zu jeder Verwaltungsschnittstelle hinzufügen, und nicht um etwas, das standardmäßig aktiviert ist.
Das gleiche Prinzip gilt für Docker-CLI- und GUI-Verwaltung; Der Zugriff auf den Daemon auf Administratorebene birgt unabhängig von der Schnittstelle das gleiche Risiko.
Sie überwachen nicht, was Ihre Container tun
Wenn ein Container kompromittiert wird, hinterlässt die Aktivität des Angreifers eine Spur: Änderungen im Prozessverhalten, ungewöhnliche Netzwerkverbindungen und unerwartete Dateiänderungen. Ohne eine Protokollerfassung existiert dieser Trail nicht in einer Form, auf die Sie reagieren können.
Zentralisierte Protokollsammlung, Container-Audit-Protokollierung und Laufzeitüberwachungstools liefern Ihnen die Daten, um abnormale Aktivitäten zu erkennen, bevor sie sich verstärken. Das Ziel besteht nicht darin, jede Zeile zu analysieren. Es geht darum, die Daten zur Verfügung zu haben, wenn Sie Nachforschungen anstellen müssen.
Container-Setups, die stillschweigend in der Produktion ohne Protokollpipeline und ohne Warnungen ausgeführt werden, sind nicht wartungsarm. Sie sind ungeprüft. Das sind zwei unterschiedliche Betriebszustände.
Warum auch die Infrastrukturumgebung wichtig ist
Containersicherheit beginnt mit der Konfiguration, aber die Konfiguration läuft auf der Infrastruktur ab. Ein Host mit falsch konfiguriertem Netzwerk, gemeinsam genutzten Ressourcen oder keiner Filterung auf Netzwerkebene schafft Bedingungen, die sich auf alle darüber liegenden Container auswirken. Das richtige Container-Setup und die richtige Serverkonfiguration sind zwei separate Aufgaben.
Viele Docker-Sicherheitslücken werden durch Bedingungen verstärkt, die die Container selbst erben:
- Ein Shared-Tenancy-Server ohne Hardware-Isolierung zwischen Mandanten
- Ein Host-Kernel, der ungepatcht läuft
- Ein Host ohne integrierte Filterung auf Netzwerkebene
Dies macht die oben genannten Konfigurationsschritte nicht überflüssig, da eine ordnungsgemäße Containerhärtung unabhängig von der Infrastrukturebene wichtig ist. Wenn Sie mit einer isolierten Infrastruktur beginnen, wird eine besorgniserregende Ebene aus der Gleichung entfernt.
Bei Cloudzy bieten wir zwei Pfade an, je nachdem, was Ihr Setup erfordert:
- Linux-VPS: eine saubere Umgebung, um Docker selbst bereitzustellen und die Härtungsschritte in diesem Artikel anzuwenden
- Portainer VPS: eine Ein-Klick-Option mit vorinstalliertem Portainer; Der Server bootet und Sie befinden sich bereits im Dashboard
Beide Optionen laufen auf derselben Infrastruktur: KVM-Virtualisierung, AMD Ryzen 9-CPUs mit bis zu 5,7 GHz Boost-Takt, DDR5-Speicher, NVMe-SSD-Speicher, bis zu 40 Gbit/s Netzwerk und kostenloser DDoS-Schutz über BuyVM-Filterung, an 12 globalen Standorten mit einem SLA für 99,95 % Verfügbarkeit.
Um einen tieferen Einblick in die Ausführung von Portainer auf einem VPS zu erhalten, behandeln wir es in einem speziellen Artikel.
Eine praktische Sicherheitscheckliste für Docker-Bereitstellungen
Die oben genannten Docker-Sicherheitsfehler sind meist auf einzelne Konfigurationsentscheidungen zurückzuführen, die einmal getroffen und nie wieder überprüft wurden. Wenn Sie diese Checkliste mit einem vorhandenen Setup vergleichen, werden diese Lücken aufgedeckt. Es fungiert als Audit und nicht als Bereitstellungsleitfaden.
Diese Best Practices für die Docker-Sicherheit behandeln, wie Docker-Container vor den oben beschriebenen häufigsten Konfigurationsfehlern geschützt werden.
Kurzanleitung: Alle 9 Fehler
| Fehler | Kategorie | Einzeiliger Fix |
| Läuft als Root | Konfiguration | Hinzufügen BENUTZER -Direktive in Ihre Docker-Datei einfügen |
| Ports, die an 0.0.0.0 gebunden sind | Konfiguration | An 127.0.0.1 binden und über einen Reverse-Proxy weiterleiten |
| Keine Netzwerkisolation | Konfiguration | Teilen Sie Dienste je nach Zugriffsanforderungen auf separate benutzerdefinierte Netzwerke auf. |
| Docker-Socket montiert | Konfiguration | Entfernen Sie die Halterung. Verwenden Sie bereichsbezogene APIs oder Alternativen |
| Nicht vertrauenswürdige oder veraltete Bilder | Bild | Verwenden Sie offizielle Bilder mit angehefteten Versions-Tags |
| Hartcodierte Geheimnisse | Bild | Verschieben Sie Anmeldeinformationen in Laufzeitumgebungsvariablen oder einen Secrets-Manager |
| Kein Zeitplan für die Image-Neuerstellung | Bild | Legen Sie einen monatlichen Wiederaufbaurhythmus fest; automatisieren, wo möglich |
| Nicht authentifizierte Dashboards | Zugang | Fügen Sie Authentifizierung hinzu und verschieben Sie Verwaltungsoberflächen in private Netzwerke |
| Keine Sammlung von Containerprotokollen | Zugang | Richten Sie eine zentrale Protokollierung und Laufzeitüberwachung ein |
Wir empfehlen, es zunächst mit vorhandenen Setups auszuführen, da dort die Lücken höchstwahrscheinlich bereits vorhanden sind.
Container, die als Nicht-Root ausgeführt werden: Überprüfen Sie Ihre Docker-Dateien auf eine USER-Anweisung. Wenn keiner vorhanden ist, wird der Container als Root ausgeführt.
Portbindungen beschränkt auf localhost oder Proxy: Führen Sie Docker PS aus und überprüfen Sie die Portbindungen. Ein 0.0.0.0:PORT-Eintrag kann auf Hosts öffentlich erreichbar sein, auf denen ihn keine Upstream-Sicherheitsgruppe, externe Firewall oder DOCKER-USER-Kettenregel blockiert.
Benutzerdefinierte Bridge-Netzwerke im Einsatz: Container auf der Standardbrücke von Docker können einander frei erreichen. Container auf derselben benutzerdefinierten Brücke können weiterhin miteinander kommunizieren. Teilen Sie daher Dienste zur tatsächlichen Isolierung über separate Netzwerke anhand der Vertrauensgrenze auf.
Docker-Socket nicht in Containern montiert: Aktivieren Sie „Dateien erstellen und Argumente ausführen“. Wenn /var/run/docker.sock als Volume angezeigt wird, bestätigen Sie, dass dies erforderlich und beabsichtigt ist.
Basisbilder von verifizierten Herausgebern mit angehefteten Versionen: Ein FROM ubuntu:latest ruft eine nicht spezifizierte, möglicherweise veraltete Version ab. An eine bestimmte Veröffentlichung anpinnen.
Keine Geheimnisse in Dockerfiles, Compose-Dateien oder Build-Argumenten: Der Bildebenenverlauf behält die Anmeldeinformationen nach dem Löschen des Containers bei. Verwenden Sie Compose Secrets, Swarm Secrets, Build Secret Mounts oder einen externen Secrets Manager. Laufzeitumgebungsvariablen sind besser als hartcodierte Werte, erscheinen aber dennoch in der Inspektionsausgabe und in den Protokollen.
Zeitplan für die Image-Neuerstellung definiert: Alte Bilder häufen Schwachstellen an. Durch einen monatlichen Aktualisierungsrhythmus bleibt das Belichtungsfenster für die meisten Setups überschaubar.
Verwaltungsschnittstellen hinter der Authentifizierung: Jedes Dashboard auf einer öffentlichen IP ohne Authentifizierung ist ein offener Einstiegspunkt. Wenn möglich, ist die Platzierung in einem privaten Netzwerk vorzuziehen.
Gesammelte Containerprotokolle: Ohne eine Protokollpipeline hängt die Erkennung von Vorfällen von sichtbaren Auswirkungen auf das System ab. Das ist ein spätes Signal zum Handeln.
Abschluss
Die Standardkonfiguration von Docker dient der Bequemlichkeit und nicht der Sicherheit. Die meisten der in diesem Artikel behandelten Fehler sind auf Einstellungen zurückzuführen, die nach der ersten Bereitstellung nie geändert wurden, und nicht auf raffinierte Angriffe.
Bei den Korrekturen handelt es sich größtenteils um einmalige Konfigurationsentscheidungen: eine USER-Anweisung, eine Änderung der Portbindung, ein benutzerdefiniertes Netzwerk, ein Zeitplan für die Neuerstellung. Für die meisten Setups sind keine neuen Werkzeuge erforderlich.
Die richtige Containerkonfiguration ist die erste Aufgabe. Die Infrastruktur, auf der es läuft, ist die zweite. Beides ist wichtig und keines ersetzt das andere.
