Zavelix IT-Praxistipp: Docker-Server sicher betreiben – die Grundlagen

Hinweis: Praxistipp, keine Nachricht

Dies ist ein allgemeiner Zavelix IT-Praxistipp und keine Meldung zu einem aktuellen Ereignis. Grundlage ist die Dokumentation zur Docker Engine.

Die vier Sicherheitsbereiche

Die Docker-Dokumentation nennt vier Bereiche, die bei der Sicherheit zu betrachten sind: die Sicherheit des Kernels mit Namespaces und Control Groups, die Angriffsfläche des Docker-Daemons, Lücken in der Container-Konfiguration sowie zusätzliche Härtungsfunktionen des Kernels.

Isolation durch Namespaces und Control Groups

Namespaces trennen Container voneinander und vom Host: Prozesse in einem Container sehen die Prozesse anderer Container oder des Hosts nicht. Jeder Container hat zudem einen eigenen Netzwerkstack. Control Groups begrenzen Ressourcen wie Speicher, CPU und Festplatten-I/O und verhindern, dass ein einzelner Container das System durch Ressourcenverbrauch lahmlegt. Sie schützen also vor manchen Denial-of-Service-Szenarien, nicht aber vor dem Zugriff auf Daten anderer Container.

Der Docker-Daemon als sensibler Punkt

Der Daemon benötigt Root-Rechte, sofern nicht der Rootless-Modus genutzt wird. Deshalb sollten nur vertrauenswürdige Benutzer ihn steuern dürfen. Ein Container kann nämlich Verzeichnisse des Hosts einbinden, bis hin zum gesamten Dateisystem, und es dort verändern. Wer Docker über eine API aus einer Anwendung heraus ansteuert, sollte Parameter besonders sorgfältig prüfen.

Standardmäßig läuft die Steuerung über einen Unix-Socket, dessen Zugriff sich über normale Dateiberechtigungen einschränken lässt. Wird die API über das Netzwerk bereitgestellt, ist laut Dokumentation eine Absicherung mit HTTPS und Zertifikaten zwingend. Eine Freigabe über HTTP ohne TLS ist nicht erlaubt. Eine Firewall allein genügt nicht, da der Endpunkt von Containern aus erreichbar sein kann und dies zu Rechteausweitung führen kann. Empfohlen wird außerdem, den Zugang nur aus einem vertrauenswürdigen Netz oder VPN zu erlauben. Alternativ ist der Zugriff per SSH möglich.

Capabilities: Root im Container ist eingeschränkt

Docker startet Container standardmäßig mit einem eingeschränkten Satz an Linux-Capabilities und entzieht alle außer den benötigten. Dadurch hat Root im Container deutlich weniger Rechte als Root auf dem Host. Mount-Vorgänge, Raw Sockets oder das Laden von Kernelmodulen lassen sich verweigern. Das erschwert Angreifern, nach einer Rechteausweitung im Container Schaden anzurichten oder auf den Host zu gelangen.

Dedizierter Server

Wenn Docker auf einem Server läuft, empfiehlt die Dokumentation, dort ausschließlich Docker zu betreiben und andere Dienste in Container zu verlagern. Übliche Administrationswerkzeuge wie ein SSH-Server und Monitoring bleiben unproblematisch.

Was sollten Unternehmen jetzt tun?

Diese Schritte lassen sich aus den genannten Grundlagen ableiten:

• Zugriff auf den Docker-Daemon nur vertrauenswürdigen Personen geben.
• Den Rootless-Modus prüfen, wenn der Daemon nicht mit Root-Rechten laufen soll.
• Die Docker-API nicht ungeschützt im Netzwerk freigeben; bei Bedarf HTTPS mit Zertifikaten, VPN oder SSH nutzen.
• Bei Host-Verzeichnissen in Containern sehr restriktiv sein.
• Standard-Capabilities beibehalten und nicht ohne Grund erweitern.
• Den Docker-Server möglichst nur für Docker nutzen.