Docker-Sicherheit für KMU: Container richtig absichern

Docker hat sich in den letzten Jahren vom Entwickler-Werkzeug zum festen Bestandteil produktiver IT-Infrastruktur entwickelt – auch bei kleinen und mittleren Unternehmen. Webanwendungen, interne Tools, Automatisierungs-Workflows: Vieles läuft heute containerisiert auf einem einzigen Linux-Server. Das Problem dabei: Docker ist standardmäßig nicht auf maximale Sicherheit ausgelegt, sondern auf einfache Bedienbarkeit. Wer die Standardeinstellungen unverändert übernimmt, öffnet häufig ungewollt Angriffsflächen, die bei einer klassischen Server-Installation gar nicht erst entstehen würden.

Warum Container-Sicherheit anders funktioniert als bei klassischen Servern

Ein Container ist keine vollständig isolierte virtuelle Maschine, sondern teilt sich den Kernel des Host-Systems mit allen anderen Containern. Diese Architektur macht Container leichtgewichtig und schnell – bedeutet aber auch: Gelingt einem Angreifer der Ausbruch aus einem Container, landet er potenziell direkt auf dem darunterliegenden Linux-Server und damit im Zugriff auf alle anderen dort laufenden Dienste. Anders als bei einem Hypervisor mit vollständiger Hardware-Virtualisierung ist die Trennung zwischen Container und Host also grundsätzlich schwächer – ein Umstand, den viele KMU bei der Einführung von Docker unterschätzen.

Hinzu kommt: Container werden oft aus öffentlichen Images gebaut, die Entwickler oder Administratoren von Docker Hub oder anderen Registries beziehen. Nicht jedes dieser Images wird aktiv gepflegt oder auf Schwachstellen geprüft – ein unbedacht eingesetztes Image kann bereits bei der Installation bekannte Sicherheitslücken oder sogar Schadcode mitbringen.

Die häufigsten Docker-Fehlkonfigurationen in der Praxis

• Container laufen als root: Ohne explizite Konfiguration starten viele Container-Prozesse mit root-Rechten. Gelingt ein Ausbruch, hat der Angreifer damit sofort erweiterte Rechte auf dem Host.
• Docker-Socket ungeschützt gemountet: Wird /var/run/docker.sock in einen Container eingebunden, erhält dieser faktisch vollständige Kontrolle über den Docker-Daemon – und damit über alle anderen Container und den Host selbst.
• Veraltete Base-Images: Container-Images werden einmal gebaut und dann monatelang nicht neu gebaut, obwohl in der zugrunde liegenden Basis-Distribution längst Sicherheitsupdates erschienen sind.
• Offene Ports ohne Firewall-Regeln: Docker manipuliert beim Start eigenständig die iptables-Regeln des Hosts – ein häufig übersehener Effekt, durch den Container-Ports auch dann von außen erreichbar sein können, wenn eine Firewall eigentlich etwas anderes vorsieht.
• Keine Ressourcen-Limits: Ohne definierte Grenzen für CPU und Arbeitsspeicher kann ein kompromittierter oder fehlerhafter Container die Ressourcen des gesamten Hosts aufbrauchen und andere Dienste lahmlegen.
• Secrets im Klartext: Datenbank-Passwörter und API-Schlüssel landen nicht selten direkt als Umgebungsvariable im docker-compose.yml oder sogar fest im Image – sichtbar für jeden mit Lesezugriff auf die Konfigurationsdateien.

Was KMU konkret tun sollten

1. Container grundsätzlich ohne root-Rechte betreiben

Für die meisten Anwendungen lässt sich im Dockerfile ein dedizierter, unprivilegierter Nutzer definieren (USER-Anweisung). Zusätzlich sollte der Docker-Daemon selbst, wo möglich, im sogenannten Rootless-Modus laufen, sodass Docker-Prozesse gar nicht erst mit root-Rechten auf dem Host ausgeführt werden.

2. Docker-Socket niemals ungeschützt in Container mounten

Der Zugriff auf den Docker-Socket ist gleichbedeutend mit vollständiger Admin-Kontrolle über den Host. Braucht ein Container tatsächlich Zugriff auf die Docker-API – etwa bei CI/CD-Werkzeugen –, gehört das über einen abgesicherten Proxy mit eingeschränkten Rechten gelöst, nicht über einen direkten Mount.

3. Images regelmäßig aktualisieren und scannen

Base-Images sollten in einem festen Rhythmus neu gebaut werden, damit Sicherheitsupdates der zugrunde liegenden Distribution einfließen. Werkzeuge wie Trivy oder Docker Scout prüfen Images automatisiert auf bekannte Schwachstellen, bevor sie produktiv eingesetzt werden.

4. Firewall-Regeln nach der Docker-Installation prüfen

Da Docker eigene iptables-Regeln setzt, reicht eine einmalige Firewall-Konfiguration auf dem Host oft nicht aus. Nach jeder Docker-Installation oder größeren Änderung an der Container-Landschaft sollte kontrolliert werden, welche Ports tatsächlich von außen erreichbar sind – etwa mit einem Portscan von außerhalb des eigenen Netzes.

5. Secrets über dedizierte Mechanismen verwalten

Statt Zugangsdaten als Klartext-Umgebungsvariable zu hinterlegen, bieten Docker Secrets, .env-Dateien mit restriktiven Dateirechten außerhalb des Repositories oder externe Secret-Manager eine deutlich sicherere Alternative.

6. Ressourcen-Limits konsequent setzen

CPU- und Speicherlimits pro Container – in docker-compose.yml über deploy.resources oder die --memory- und --cpus-Flags konfigurierbar – verhindern, dass ein einzelner kompromittierter oder fehlerhafter Container die gesamte Server-Infrastruktur beeinträchtigt.

Praxisbeispiel: Container-Wildwuchs bei einem Dresdner Handwerksbetrieb

Bei einem mittelständischen Handwerksbetrieb aus Dresden war über zwei Jahre ein einzelner Linux-Server organisch mit mehreren Docker-Containern gewachsen – eine Webanwendung, ein internes Tool, ein Automatisierungs-Workflow. Eine Überprüfung zeigte: Sämtliche Container liefen als root, mehrere Base-Images waren seit über einem Jahr nicht aktualisiert worden, und Datenbank-Zugangsdaten standen im Klartext in einer docker-compose.yml, die versehentlich auch im internen Git-Repository landete. Die Korrektur erfolgte schrittweise: Umstellung auf unprivilegierte Container-Nutzer, Einführung eines monatlichen Image-Update-Zyklus, Auslagerung der Secrets in eine restriktiv geschützte .env-Datei außerhalb der Versionskontrolle sowie eine Kontrolle der tatsächlich offenen Ports gegen die bestehende OPNsense-Firewall. Der gesamte Umbau ließ sich ohne Produktionsausfall innerhalb weniger Tage umsetzen.

Sie suchen Unterstützung in Dresden?

Rexoma unterstützt KMU in Dresden, Sachsen und ganz Ostdeutschland beim sicheren Betrieb von Docker- und Container-Umgebungen – von der Überprüfung bestehender Konfigurationen über die Absicherung von Secrets bis zur Einbindung von Container-Infrastruktur in ein sauberes Patch-Management. Als IT-Dienstleister mit Fokus auf mittelständische Betriebe sorgen wir dafür, dass moderne Container-Technologie nicht zum unterschätzten Sicherheitsrisiko wird.

FAQ

Ist Docker grundsätzlich unsicherer als klassische Server-Installationen? Nicht grundsätzlich, aber Docker verschiebt die Verantwortung für Sicherheit stärker auf die Konfiguration. Die Standardeinstellungen priorisieren Bedienbarkeit, nicht maximale Absicherung – wer sie unverändert übernimmt, riskiert unnötige Angriffsflächen.

Warum ist der Docker-Socket so kritisch? Wer Zugriff auf den Docker-Socket hat, kann darüber beliebige neue Container mit vollen Rechten starten und damit faktisch den gesamten Host kontrollieren. Ein Mount dieses Sockets in einen Container sollte deshalb nur in genau begründeten, abgesicherten Ausnahmefällen erfolgen.

Reicht eine Firewall auf dem Host, um Container-Ports abzusichern? Nicht automatisch. Docker verändert beim Start eigenständig die iptables-Regeln des Hosts, wodurch Container-Ports auch dann erreichbar sein können, wenn die ursprüngliche Firewall-Konfiguration etwas anderes vorsah. Nach jeder Änderung an der Container-Landschaft lohnt sich eine Kontrolle von außen.

Wie oft sollten Docker-Images aktualisiert werden? Ein fester, wiederkehrender Rhythmus – etwa monatlich oder bei bekanntwerdenden kritischen Schwachstellen sofort – verhindert, dass veraltete Base-Images unbemerkt Sicherheitslücken in den produktiven Betrieb tragen.

Wo sollten Zugangsdaten für Container-Anwendungen gespeichert werden? Nicht als Klartext-Umgebungsvariable im docker-compose.yml und nicht im Versionskontroll-Repository. Besser geeignet sind Docker Secrets, restriktiv geschützte .env-Dateien außerhalb des Repositories oder ein dedizierter Secret-Manager.