Docker Hardening Guide für Linux-Server

Praxisnaher Docker Hardening Guide für Linux-Server: weniger Rechte, sichere Images, Netzwerk-Hardening und bessere Secrets.

· 3 Minuten zu lesen
Docker Hardening Guide für Linux-Server

Warum Docker-Hardening wichtig ist

Docker macht es extrem einfach, Anwendungen in Containern bereitzustellen. Ohne sinnvolle Sicherheitsmaßnahmen können Container aber Angriffsflächen vergrößern: unsichere Images, zu weitreichende Rechte, falsche Netzwerk-Konfiguration oder fehlende Updates. In diesem Guide schauen wir uns praxisnah an, wie du Docker auf Linux-Servern sicherer betreibst.

1. Docker-Installation absichern

Offizielle Repositories nutzen

Verwende nach Möglichkeit die offiziellen Docker-Repositories oder die Distributionspakete, um Sicherheitsupdates zeitnah zu erhalten.

Nur benötigte Komponenten installieren

Auf Produktivsystemen sollte nur installiert sein, was du wirklich brauchst: Engine, CLI, ggf. Compose. Test-Tools wie ctop oder GUI-Tools gehören nicht auf produktive Server.

2. Docker-Daemon einschränken

Remote-API deaktivieren oder absichern

Die Docker-API darf nicht ungeschützt im Netzwerk lauschen. Standardmäßig ist sie nur auf dem Unix-Socket erreichbar – das sollte so bleiben, es sei denn du hast ein klares Konzept für TLS-geschützte Remote-APIs.

Rootless Docker als Option

Docker Rootless Mode reduziert das Risiko, dass ein Container-Breakout sofort Root-Zugriff auf den Host bedeutet. Für viele Workloads kann dieser Modus eine sinnvolle zusätzliche Absicherung sein.

3. Nutzer- und Gruppenrechte

Das Hinzufügen von Benutzern zur Gruppe docker entspricht einem Root-ähnlichen Zugriff, weil über die Docker-API praktisch Vollzugriff auf den Host möglich ist. Gib diese Rechte daher nur sehr selektiv und dokumentiere, wer Zugriff hat.

4. Container als nicht-root laufen lassen

Viele Images starten Prozesse standardmäßig als Root. Passe Dockerfiles und Compose-Dateien so an, dass innerhalb des Containers ein dedizierter Benutzer verwendet wird.

Beispiel Dockerfile

FROM debian:12-slim

# User anlegen
RUN useradd -r -u 1000 appuser

# Dateien kopieren und Rechte setzen
COPY app /opt/app
RUN chown -R appuser:appuser /opt/app

USER appuser
CMD ["/opt/app/start.sh"]

5. Linux Capabilities und Privileges reduzieren

Standardmäßig besitzen Container eine Reihe von Linux-Capabilities, die oft nicht benötigt werden. Reduziere diese mit --cap-drop und erlaube nur das Nötigste.

Beispiel

docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  my-app:latest

6. Keine privilegierten Container

--privileged sollte nur in Ausnahmefällen genutzt werden (z. B. in Lab-Umgebungen). Privilegierte Container haben nahezu alle Rechte des Hosts – ein erfolgreicher Angriff auf so einen Container bedeutet in der Regel einen vollständigen Host-Kompromiss.

7. Dateisysteme und Mounts absichern

Nur notwendige Verzeichnisse mounten

Vermeide es, ganze Host-Verzeichnisse wie /, /etc oder /var direkt in Container zu mounten. Nutze dedizierte Datenverzeichnisse, z. B. /srv/appdata/<service>.

Read-only Root Filesystem

Viele Services benötigen kein schreibbares Root-Dateisystem. Mit --read-only kannst du das Root-FS des Containers read-only mounten und nur einzelne Pfade beschreibbar machen.

docker run \
  --read-only \
  -v /var/log/myapp:/var/log/myapp \
  my-app:latest

8. Netzwerk-Hardening

Veröffentliche nicht jeden Container-Port direkt am Host. Nutze interne Docker-Netzwerke und exponiere nur diejenigen Ports, die wirklich von außen erreichbar sein müssen.

Beispiel: internes Netzwerk

docker network create app-net

docker run -d --name backend --network app-net backend:latest
docker run -d --name frontend --network app-net -p 80:80 frontend:latest

Hier ist nur der Frontend-Container von außen erreichbar, Backend und Datenbank bleiben intern.

9. Secrets sicher handhaben

Umgebungsvariablen sind bequem, aber nicht ideal für hochsensible Geheimnisse wie Datenbank-Passwörter oder API-Keys. Nutze nach Möglichkeit:

  • Docker Swarm Secrets
  • Kubernetes Secrets (falls du K8s einsetzt)
  • oder externe Secret Stores wie HashiCorp Vault

10. Image-Sicherheit

Vertrauenswürdige Registries

Nutze offizielle Images oder selbst gepflegte Base-Images. Unbekannte Images aus öffentlichen Registries sollten nicht ungeprüft in der Produktion verwendet werden.

Images regelmäßig aktualisieren

Baue Images regelmäßig neu, damit Sicherheitspatches der Basis-Distributionen einfließen. Automatisiere Builds (z. B. via CI/CD) und versieh Images mit klaren Tags (1.2.3 statt nur latest).

Image-Scanning

Tools wie Trivy, Grype oder Docker Scout können Images auf bekannte Schwachstellen prüfen.

11. Logging & Monitoring

Stelle sicher, dass Logs zentral gesammelt werden (z. B. Loki, Elasticsearch, Graylog). Überwache außerdem:

  • Container-Neustarts
  • ungewöhnliche Ressourcennutzung
  • fehlgeschlagene Logins/Requests

12. Hardening-Checkliste

  • Keine offene Remote-API ohne TLS
  • Minimale Zahl an Nutzern mit Docker-Rechten
  • Container laufen nicht als root
  • Capabilities reduziert, keine privilegierten Container
  • Nur notwendige Mounts, idealerweise read-only
  • Interne Netzwerke sinnvoll genutzt
  • Secrets nicht im Image oder in Git
  • Images regelmäßig aktualisiert und gescannt
  • Überwachung von Logs und Metriken eingerichtet

Fazit

Docker bietet viel Komfort, aber Sicherheit kommt nicht automatisch mit. Mit einigen gezielten Maßnahmen kannst du deine Container-Umgebung deutlich härten und das Risiko eines erfolgreichen Angriffs stark reduzieren. Wichtig ist vor allem: klare Standards, wiederverwendbare Compose-Templates und regelmäßige Überprüfung der Konfigurationen.

Kommentare