Läuft Ihr Docker-Container – oder ist er auch sicher?

Ein Docker-Container, der sauber startet, ist noch kein sicherer Container.

Das klingt unbequem, ist aber genau der Punkt: Viele Webprojekte laufen heute in Docker, weil Deployments damit reproduzierbarer, portabler und einfacher werden. Für kleine SaaS-Teams, Agenturen, Freelancer und Website-Betreiber ist das ein echter Vorteil. Aber Docker löst Sicherheitsprobleme nicht automatisch. Es verschiebt sie nur in eine andere Schicht.

Die Frage ist deshalb nicht: Läuft die Website? Die bessere Frage lautet: Wenn jemand Zugriff auf diesen Container bekommt, wie viel Schaden kann er anrichten?

Der typische Denkfehler

Viele Teams behandeln Docker wie eine Verpackung: App rein, Image bauen, Container starten, fertig. Für ein internes Testsystem reicht das vielleicht. Für eine produktive Website mit Kontaktformularen, Logins, Kundendaten, Zahlungsflüssen oder Tracking ist das zu dünn.

OWASP beschreibt Docker als Technologie, die bei richtiger Nutzung Sicherheit erhöhen kann, aber durch Fehlkonfigurationen auch neue Risiken einführt. Besonders kritisch sind exponierte Docker-Sockets, Root-Prozesse im Container, zu viele Berechtigungen, fehlende Updates, unsaubere Secrets und nicht geprüfte Images (OWASP Docker Security Cheat Sheet).

Das Problem ist selten Docker selbst. Das Problem ist das Setup, das im Projektstress entstanden ist und danach niemand mehr angefasst hat.

Schneller Selbstcheck: rote Flaggen im Docker-Setup

Wenn mehrere dieser Punkte zutreffen, sollte das Deployment geprüft werden:

• Der Container läuft als root, obwohl die App das nicht braucht.
• In docker-compose.yml ist /var/run/docker.sock in einen Container gemountet.
• Secrets liegen in .env-Dateien, Build-Args, Images oder CI/CD-Logs.
• Das Base Image ist nicht gepinnt oder wird seit Monaten nicht aktualisiert.
• Es gibt keinen regelmäßigen Image-Scan auf bekannte Schwachstellen.
• Der Container läuft mit privileged: true.
• Es werden mehr Ports veröffentlicht als wirklich nötig.
• Es gibt keine Resource Limits für CPU, Speicher oder Prozesse.
• Volumes sind unklar dokumentiert: Niemand weiß genau, wo persistente Daten liegen.
• Es gibt keinen dokumentierten Restore-Test für den kompletten Stack.

Keiner dieser Punkte bedeutet automatisch, dass das System kompromittiert ist. Aber jeder Punkt erhöht die Angriffsfläche oder erschwert die Wiederherstellung im Ernstfall.

Root im Container ist bequem – und oft unnötig

Ein häufiger Fehler: Die App läuft im Container als Root-Benutzer, weil das Image so gebaut wurde oder weil es beim ersten Deployment schneller ging. OWASP empfiehlt, Container mit einem unprivilegierten User zu betreiben. Das kann im Dockerfile über USER oder zur Laufzeit über entsprechende Optionen gesetzt werden (OWASP Docker Security Cheat Sheet).

Das ist kein Allheilmittel. Aber es ist ein wichtiger Schritt: Wenn ein Angreifer aus der Anwendung heraus Code ausführen kann, sollte dieser Code nicht automatisch mit unnötig hohen Rechten laufen. Für bestimmte Umgebungen kann zusätzlich Rootless Docker sinnvoll sein. Docker beschreibt Rootless Mode als Möglichkeit, Docker-Daemon und Container als Nicht-Root-User auszuführen, um Risiken im Daemon und Container-Runtime-Bereich zu reduzieren (Docker Docs: Rootless mode).

Der Docker-Socket ist kein harmloser Shortcut

Der Docker-Socket /var/run/docker.sock ist besonders heikel. Wer Zugriff darauf hat, kann über die Docker API sehr weitreichende Aktionen auf dem Host auslösen. OWASP formuliert es deutlich: Zugriff auf den Socket ist faktisch sehr nah an Root-Zugriff auf dem Host (OWASP Docker Security Cheat Sheet).

Trotzdem taucht der Socket in vielen Setups auf, etwa für Management-UIs, automatische Deployment-Tools oder Monitoring-Container. Das ist nicht immer falsch. Aber es darf nie beiläufig passieren. Wenn ein Container Zugriff auf den Docker-Socket braucht, sollte dokumentiert sein, warum der Zugriff notwendig ist, welche Alternative geprüft wurde, wer Zugriff auf die Oberfläche hat und wie diese Komponente aktualisiert wird.

Ein Docker-Socket-Mount ist kein kleines Detail. Er ist eine Architekturentscheidung.

Image-Scanning ist kein Luxus mehr

Container-Images enthalten Betriebssystempakete, Laufzeitumgebungen und Abhängigkeiten. Diese Bestandteile können bekannte Schwachstellen haben. Docker Scout analysiert Images, erstellt eine Software Bill of Materials (SBOM) und gleicht die enthaltenen Komponenten mit einer Vulnerability-Datenbank ab (Docker Docs: Docker Scout).

Für kleine Teams heißt das nicht, dass jeder CVE sofort Panik auslösen muss. Scanner produzieren auch Rauschen. Entscheidend ist ein praktikabler Prozess: Images regelmäßig scannen, kritische Findings priorisieren, Base Images bewusst aktualisieren, Updates testen und akzeptierte Risiken dokumentieren.

Secrets gehören nicht ins Image

Ein weiteres klassisches Problem: API Keys, Datenbankpasswörter oder Tokens landen im Build-Prozess, in .env-Dateien, in CI-Logs oder sogar im Image selbst. Das ist gefährlich, weil Images kopiert, gecacht, gepusht und in Registries gespeichert werden. Ein Secret, das einmal im Image-Layer liegt, ist oft schwer wieder sauber zu entfernen.

Praktischer Mindeststandard: Keine Secrets im Dockerfile, keine produktiven Secrets als normale Build-Args, .env-Dateien nicht committen, CI/CD-Logs prüfen, Secrets über Hosting-Environment, Secret Manager, Docker Secrets oder vergleichbare Mechanismen bereitstellen und nach Team- oder Vendorwechsel rotieren.

Was Website-Pflichtencheck prüfen würde

Ein Docker-Sicherheitscheck ist kein abstrakter Audit für Enterprise-Folien. Für viele Websites reicht ein praktischer Blick auf die tatsächliche Deployment-Realität:

• Läuft die Anwendung mit unnötigen Root-Rechten?
• Sind Dockerfile und Compose-Dateien nachvollziehbar aufgebaut?
• Werden gefährliche Mounts wie der Docker-Socket verwendet?
• Sind Ports, Netzwerke und Volumes bewusst konfiguriert?
• Gibt es Healthchecks, Restart-Regeln und Resource Limits?
• Werden Images regelmäßig gescannt?
• Sind Base Images, Runtime-Versionen und Abhängigkeiten gepflegt?
• Sind Secrets sauber vom Image getrennt?
• Ist dokumentiert, wie die Website aus Backup und Repository wiederhergestellt werden kann?
• Ist klar, wer im Incidentfall Zugriff hat und wer nicht?

Das Ziel ist nicht, jedes Projekt künstlich komplex zu machen. Das Ziel ist, unangenehme Überraschungen zu vermeiden.

Fazit: Ein laufender Container ist kein Sicherheitsnachweis

Docker macht Deployments leichter. Aber ein Container, der startet, beweist nur eines: Er startet.

Er beweist nicht, dass Berechtigungen minimal sind. Er beweist nicht, dass Secrets sauber behandelt werden. Er beweist nicht, dass das Image aktuell ist. Und er beweist nicht, dass das Projekt im Ernstfall schnell wiederhergestellt werden kann.

Wenn Ihr Webprojekt auf Docker läuft und niemand die oben genannten Fragen sicher beantworten kann, ist ein technischer Check sinnvoll. Nicht als Panikmaßnahme, sondern als nüchterner Realitätsabgleich. Website-Pflichtencheck kann genau dabei helfen: Risiken sichtbar machen, technische Schwachstellen dokumentieren und konkrete nächste Schritte priorisieren, bevor aus einem kleinen Deployment-Detail ein teurer Vorfall wird.