DevOps 13 Min Lesezeit

Docker hat die Art und Weise revolutioniert, wie wir Software entwickeln, ausliefern und betreiben. Container ermöglichen isolierte Umgebungen, reproduzierbare Deployments und eine nie dagewesene Flexibilität. Doch mit dieser Freiheit kommt Verantwortung: Container teilen sich den Host-Kernel, laufen oft mit weitreichenden Berechtigungen und können bei falscher Konfiguration ein massives Sicherheitsrisiko darstellen.

Gerade 2026, wo Container in nahezu jeder Produktionsumgebung zum Standard gehören, ist ein fundiertes Verständnis der Docker-Sicherheit unverzichtbar. Von der Container-Runtime über Image-Scanning bis hin zu Netzwerksicherheit und Secrets-Management – dieser Guide zeigt dir alle relevanten Maßnahmen, um deine Docker-Container produktionssicher zu betreiben.

Wer sein Docker-Wissen vertiefen möchte, findet bei Amazon eine gute Auswahl an Docker- und Security-Literatur*.

Warum Docker-Sicherheit wichtiger ist als je zuvor

Der Mythos, dass Container von Natur aus sicher isoliert seien, hält sich hartnäckig. Tatsächlich nutzen Container – anders als VMs – den gemeinsamen Kernel des Hosts. Ein erfolgreicher Container-Breakout gewährt einem Angreifer daher potenziell direkten Zugriff auf das Host-System. Hinzu kommen unsichere Images aus öffentlichen Registries, offene Docker-Sockets, fehlende Ressourcenlimits und unbedacht gemountete Host-Verzeichnisse.

Laut aktuellen Sicherheitsreports des CIS (Center for Internet Security) sind über 40 Prozent der produktiven Docker-Installationen unzureichend gehärtet. Typische Angriffsvektoren sind privilegierte Container, veraltete Images mit bekannten CVEs, fehlende Network Isolation und die Verwendung des latest-Tags ohne Versionierung. Wer Docker sicher betreiben will, muss daher jede Ebene des Stacks betrachten:

Container-Runtime absichern

Der erste Hebel für mehr Sicherheit ist die Docker-Runtime selbst. Viele Standardeinstellungen sind bewusst permissiv ausgelegt, um die Einstiegshürde niedrig zu halten. Für den Produktionseinsatz musst du diese Einstellungen jedoch nachschärfen.

Non-Root User in Containern

Container, die als root laufen, sind das häufigste Sicherheitsproblem. Zwar sind Prozesse innerhalb des Containers durch Linux-Namespaces vom Host-Root getrennt – dennoch erhöht Root im Container die Angriffsfläche massiv. Verwende stattdessen in deinem Dockerfile den USER-Befehl, um einen dedizierten Benutzer anzulegen:

FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
COPY --chown=appuser:appgroup . /app
WORKDIR /app
CMD ["node", "server.js"]

Viele offizielle Images (Nginx, PostgreSQL, Redis) bieten längst vorkonfigurierte Non-Root-Varianten an – nutze sie! Der Docker-User-Namespace-Modus (--userns-remap) kann zusätzlich Root-Rechte im Container auf einen unprivilegierten Host-User abbilden.

Read-Only Filesystem

Starte Container standardmäßig mit einem --read-only-Filesystem. Das verhindert, dass ein Angreifer nach einer erfolgreichen Exploitation Schadsoftware persistieren kann. Für Verzeichnisse, in die geschrieben werden muss (z. B. temporäre Uploads, Logs oder Caches), mountest du explizit beschreibbare Volumes:

docker run --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --tmpfs /var/run:rw,noexec,nosuid \
  myapp:latest

Seccomp- und AppArmor-Profile

Seccomp (Secure Computing Mode) filtert die Systemaufrufe, die ein Container tätigen darf. Docker liefert ein Standard-Seccomp-Profil mit, das etwa 44 Prozent der möglichen Syscalls blockt. Für eine noch restriktivere Konfiguration erstellst du ein eigenes Profil:

docker run --security-opt seccomp=custom-profile.json myapp

AppArmor arbeitet auf Ebene der Dateizugriffe und Programme. Das Docker-Profil docker-default ist bereits aktiv, du kannst es aber mit eigenen Regeln ergänzen. Zusätzlich verringerst du die Angriffsfläche, indem du unnötige Capabilities mit --cap-drop=ALL und --cap-add=NEEDED entfernst.

Image-Security: Vertrauen ist gut, Scannen ist besser

Die Sicherheitskette beginnt bereits beim Image. Wenn du ein Image aus Docker Hub oder einer anderen Registry ziehst, importierst du potenziell Code und Abhängigkeiten mit unbekanntem Sicherheitsstatus. Image-Scanning ist daher ein essenzieller Bestandteil jeder Docker-Security-Strategie.

Image-Scanning mit Trivy und Grype

Trivy (von Aqua Security) und Grype (von Anchore) sind die beiden führenden Open-Source-Tools zum Scannen von Container-Images auf bekannte Schwachstellen. Beide durchsuchen das Image nach installierten Paketen, Bibliotheken und Betriebssystem-Komponenten und gleichen diese mit CVE-Datenbanken ab:

# Trivy
trivy image nginx:1.25-alpine

# Grype
grype nginx:1.25-alpine

Integriere das Scannen in deine CI/CD-Pipeline – docker build sollte nur durchlaufen, wenn das resultierende Image keine kritischen oder hohen CVEs enthält. So stellst du sicher, dass keine unsicheren Images in deine Registry oder Produktion gelangen.

Docker Content Trust

Mit export DOCKER_CONTENT_TRUST=1 aktivierst du die Signaturprüfung für Images aus Docker Hub. Nur signierte Images werden dann akzeptiert. Das verhindert Man-in-the-Middle-Angriffe und stellt sicher, dass das Image tatsächlich vom angegebenen Publisher stammt. In Kombination mit einem privaten Registry-Mirror, der nur gescannte und signierte Images vorhält, erreichst du ein hohes Sicherheitsniveau.

Zur Vertiefung der Image-Security-Thematik lohnt sich ein Blick in die Fachliteratur: Docker Image Security bei Amazon*.

Registry-Security: Privates Repository bevorzugen

Öffentliche Images aus Docker Hub sind bequem, aber nicht immer vertrauenswürdig. Verwende nach Möglichkeit eine private Container Registry (z. B. Harbor, GitLab Container Registry oder die AWS ECR) mit integriertem Vulnerability-Scanning. Nur geprüfte und genehmigte Images sollten in deiner Registry landen.

Netzwerksicherheit: Container richtig isolieren

Docker-Netzwerke sind standardmäßig liberal: Container im selben Netzwerk können einander uneingeschränkt erreichen. In der Produktion brauchst du klare Grenzen.

Netzwerk-Isolation strikt durchsetzen

Lege pro Projekt oder sogar pro Service dedizierte Docker-Netzwerke an. Verbinde nur Container, die tatsächlich kommunizieren müssen. Ein Reverse-Proxy-Container sollte beispielsweise nur im Proxy-Netz hängen, die Datenbank nur im internen Backend-Netz:

networks:
  proxy:
    external: true
  backend:
    internal: true

Der Zusatz internal: true verhindert, dass Container dieses Netzwerks auf das Internet zugreifen können – ideal für Datenbanken und Caches.

Nicht den Docker Socket mounten

Eines der größten Sicherheitsrisiken in Docker-Umgebungen ist das Mounten des Docker-Sockets (/var/run/docker.sock) in einen Container. Wer Zugriff auf den Socket hat, hat Root-Zugriff auf die gesamte Docker-Daemon-API – und damit auf alle Container des Hosts. Verwende stattdessen API-basierte Alternativen oder Socket-Proxy-Tools mit eingeschränkten Berechtigungen.

Secrets-Management: Passwörter gehören nicht in Umgebungsvariablen

Klassische Umgebungsvariablen sind bequem, aber unsicher: Sie sind über docker inspect, in Logs und in History-Dateien einsehbar. Docker bietet ab Version 20.10 ein natives Secrets-Management für Swarm-Mode. Für Compose-Setups nutzt du docker secret oder externe Tools wie Hashicorp Vault oder Bitwarden Secrets Manager.

secrets:
  db_password:
    file: ./secrets/db_password.txt

services:
  app:
    secrets:
      - db_password

Ein wichtiger Grundsatz: Secrets niemals im Git-Repository ablegen. Nutze .gitignore, um sensitive Dateien auszuschließen, und setze restriktive Dateirechte (z. B. chmod 600).

Ressourcenlimits: Container zähmen

Container ohne Ressourcenlimits können den gesamten Host lahmlegen – absichtlich durch einen Angreifer oder versehentlich durch einen Speicherleck.

Setze deshalb für jeden Container CPU- und Speicherlimits:

docker run --memory="512m" --cpus="1.0" --memory-reservation="256m" myapp

# In docker-compose.yml:
services:
  app:
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M

Mit --memory-reservation gibst du dem Scheduler einen Hinweis, wie viel Speicher der Container idealerweise bekommen sollte. Bei Speicherknappheit greift Docker auf diese Reservierungen zurück. --oom-kill-disable verhindert das Beenden des Containers bei Speichermangel – setze das aber nur mit Bedacht ein.

Rootless-Mode: Docker ohne Root-Rechte

Der Rootless-Mode ist einer der größten Sicherheitsfortschritte in der Docker-Welt. Statt als Root-Daemon läuft die gesamte Docker-Engine in einem User-Namespace ohne echte Root-Rechte auf dem Host. Ein Container-Breakout führt dann nicht mehr zur vollen Host-Kontrolle.

Die Einrichtung ist unkompliziert:

# Voraussetzung: neueuidmap / newgidmap installiert
dockerd-rootless-setuptool.sh install
systemctl --user start docker

# Danach läuft alles rootless:
docker run hello-world

Der Rootless-Mode ist inzwischen produktionsreif und wird von vielen Projekten standardmäßig empfohlen. Beachte jedoch, dass einige Docker-Features (insbesondere eingeschränkte Netzwerkmöglichkeiten) im Rootless-Mode nicht verfügbar sind. Prüfe daher vor dem Umstieg, ob dein Setup kompatibel ist.

Weiterführende Hardware und Tools für den Docker-Betrieb findest du auch bei Amazon zum Thema Docker & Container-Security*.

Docker Bench Security: Der automatisierte Security-Check

Das CIS (Center for Internet Security) hat einen umfassenden Benchmark für Docker-Härtung veröffentlicht. Docker Bench Security setzt diese Empfehlungen in ein automatisiertes Testskript um:

# Docker Bench Security ausführen
docker run --rm --net=host \
  --pid=host --userns=host \
  --cap-add=audit_control \
  -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc:/etc:ro \
  docker/docker-bench-security

Das Tool prüft über 100 Einzelpunkte in den Kategorien Host-Konfiguration, Docker-Daemon-Konfiguration, Container-Images, Container-Runtime, Docker-Sicherheitsoperationen und mehr. Arbeite die Warnungen systematisch ab und dokumentiere Abweichungen.

Monitoring & Auditing: Sicherheit ist kein einmaliges Projekt

Einmal gehärtet, heißt nicht dauerhaft sicher. Regelmäßiges Monitoring und Auditing sind essenziell für die langfristige Sicherheit deiner Docker-Umgebung.

Container-Logging und -Überwachung

Docker-Logs sollten zentralisiert und auf verdächtige Aktivitäten geprüft werden. Tools wie Loki + Promtail oder der ELK-Stack eignen sich hervorragend für die Log-Aggregation. Achte darauf, Logs durch Log-Rotation zu begrenzen:

# In docker-compose.yml
services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Docker-Events überwachen

Mit docker events erhältst du einen Live-Stream aller Aktivitäten der Docker-Engine – vom Starten und Stoppen von Containern bis zu Mount-Vorgängen und Netzwerkänderungen. Integriere diese Events in dein Monitoring-System und schlage bei ungewöhnlichen Aktivitäten Alarm.

Regelmäßige Audits

Führe mindestens monatlich einen Docker-Bench-Security-Lauf durch und gleiche die Ergebnisse mit deiner Baseline ab. Automatisiere das Scannen aller laufenden Images auf neue CVEs – ein Image, das gestern noch sauber war, kann heute eine kritische Lücke enthalten.

Häufige Fehler bei der Docker-Absicherung

🔒 Praxis-Tipp: Starte mit der Docker Bench Security und arbeite die WARN-Meldungen von oben nach unten ab. Schon die ersten zehn umgesetzten Punkte reduzieren die Angriffsfläche um 80 Prozent. Kombiniere das mit regelmäßigem Trivy-Scanning und aktiviertem Rootless-Mode – das ist der schnellste Weg zu einer produktionsreifen Docker-Sicherheit.

📖 Ähnliche Artikel