Docker und Container sicher betreiben: 15 Best Practices für 2026

Docker und Container sicher betreiben bedeutet, Anwendungen über ihren gesamten Lebenszyklus zu schützen. Dazu gehören der Build-Prozess, die Registry, der Container-Host und der laufende Betrieb. Ebenso wichtig sind Netzwerke, Zugangsdaten und Protokolle.

Container erleichtern die Bereitstellung moderner Anwendungen. Sie starten schnell und benötigen weniger Ressourcen als klassische virtuelle Maschinen. Dennoch entsteht Sicherheit nicht automatisch durch Isolation. Container teilen sich normalerweise den Kernel des Hostsystems. Eine Schwachstelle kann deshalb weitreichende Folgen haben.

Viele Risiken entstehen durch unsichere Images, unnötige Root-Rechte oder öffentlich erreichbare Dienste. Auch fest eingebaute Passwörter stellen eine ernste Gefahr dar. Zusätzlich bleiben veraltete Pakete oft lange unbemerkt.

Ein wirksames Sicherheitskonzept kombiniert daher mehrere Schutzebenen. Dazu zählen minimale Images, eingeschränkte Rechte und regelmäßige Schwachstellenscans. Außerdem sollten Sie Netzwerke trennen und auffällige Aktivitäten überwachen.

Dieser Artikel zeigt Ihnen 15 praktische Maßnahmen für eine sichere Container-Umgebung. Die Beispiele richten sich an Administratoren, Entwickler und Betreiber kleiner sowie mittlerer Infrastrukturen.

Kurz erklärt

Was ist das Thema? Der sichere Aufbau und Betrieb von Docker-Containern.
Warum ist es wichtig? Fehlkonfigurationen können Anwendungen, Daten und den Host gefährden.
Wer profitiert davon? Administratoren, Entwickler, DevOps-Teams, Hoster und Betreiber containerisierter Webanwendungen.

Das Wichtigste in 30 Sekunden

Verwenden Sie kleine und vertrauenswürdige Images.

Starten Sie Anwendungen nicht als Root.

Speichern Sie keine Secrets im Image.

Begrenzen Sie Rechte, Ressourcen und Netzwerkzugriffe.

Scannen, aktualisieren und überwachen Sie alle Komponenten.

Table of Contents

Inhaltsverzeichnis

Warum Container-Sicherheit wichtig ist
Das Sicherheitsmodell von Docker verstehen
Docker und Container sicher betreiben: 15 Best Practices
Sichere Docker-Compose-Konfiguration
Container-Images und Lieferkette schützen
Netzwerk und veröffentlichte Ports absichern
Secrets und sensible Daten verwalten
Überwachung, Protokollierung und Incident Response
Docker in Kubernetes sicher einsetzen
Häufige Sicherheitsfehler
Vorteile und Grenzen von Containern
Zusammenfassende Checkliste
Fazit
FAQ

Warum Container-Sicherheit wichtig ist

Container verpacken eine Anwendung mit ihren benötigten Bibliotheken und Laufzeitkomponenten. Dadurch läuft die Anwendung in verschiedenen Umgebungen weitgehend gleich. Diese Portabilität vereinfacht Entwicklung und Betrieb.

Allerdings sind Container keine vollständigen virtuellen Maschinen. Sie verwenden normalerweise den Kernel des Hosts gemeinsam. Ein erfolgreicher Ausbruch aus einem Container kann daher den Host gefährden. Besonders kritisch sind privilegierte Container und eingebundene Systemverzeichnisse.

Zusätzlich stammen viele Images aus öffentlichen Registrys. Solche Images können veraltete Pakete oder bekannte Schwachstellen enthalten. Bei unbekannten Herausgebern besteht außerdem das Risiko manipulierter Inhalte.

Ein weiteres Problem betrifft die kurze Lebensdauer vieler Container. Herkömmliche Sicherheitswerkzeuge erkennen schnell gestartete Prozesse möglicherweise zu spät. Deshalb müssen Kontrollen bereits während des Builds beginnen.

Container-Sicherheit umfasst somit mehrere Bereiche:

Schutz des Docker-Hosts
Absicherung des Docker-Daemons
Kontrolle der Container-Images
Begrenzung der Berechtigungen
Schutz von Netzwerken und Daten
Überwachung der laufenden Workloads
Absicherung der Software-Lieferkette

Merke: Ein Container ist eine zusätzliche Isolationsschicht. Er ersetzt jedoch keine sichere Konfiguration des Hosts oder der Anwendung.

Das Sicherheitsmodell von Docker verstehen

Docker verwendet mehrere Funktionen des Linux-Kernels. Dazu gehören Namespaces, Control Groups und Linux Capabilities. Gemeinsam trennen sie Prozesse und begrenzen deren Zugriff.

Namespaces isolieren beispielsweise Prozesse, Netzwerke und Dateisysteme. Control Groups begrenzen hingegen Ressourcen wie Arbeitsspeicher oder CPU-Zeit. Linux Capabilities teilen klassische Root-Rechte zusätzlich in einzelne Berechtigungen auf.

Docker nutzt außerdem standardmäßig ein Seccomp-Profil. Seccomp filtert Systemaufrufe, die ein Prozess an den Kernel senden darf. Dadurch sinkt die Angriffsfläche des Hosts.

Diese Mechanismen bieten jedoch nur Schutz, wenn sie nicht umgangen werden. Optionen wie --privileged heben zahlreiche Einschränkungen auf. Ebenso gefährlich kann die Einbindung des Docker-Sockets sein.

Die folgende Tabelle ordnet wichtige Schutzmechanismen ein:

Mechanismus	Aufgabe	Sicherheitsnutzen
Namespaces	Trennen Prozesse und Ressourcen	Begrenzen die Sicht eines Containers
Control Groups	Begrenzen CPU und Arbeitsspeicher	Reduzieren Ressourcenmissbrauch
Capabilities	Teilen Root-Rechte auf	Erlauben gezielten Rechteentzug
Seccomp	Filtert Systemaufrufe	Verkleinert die Kernel-Angriffsfläche
AppArmor oder SELinux	Kontrolliert Datei- und Prozesszugriffe	Begrenzt kompromittierte Anwendungen
Rootless Mode	Betreibt Docker ohne Root-Daemon	Reduziert Folgen eines Daemon-Angriffs

Jeder Mechanismus deckt nur einen Teilbereich ab. Deshalb entsteht wirksame Sicherheit erst durch ihre Kombination.

Docker und Container sicher betreiben: 15 Best Practices

Die folgenden Maßnahmen bilden eine belastbare Grundlage. Passen Sie diese jedoch an Ihre Anwendungen und deren Schutzbedarf an.

1. Docker-Host minimal und aktuell halten

Der Docker-Host bildet die wichtigste Vertrauensgrenze. Ein kompromittierter Host gefährdet grundsätzlich alle darauf laufenden Container.

Installieren Sie deshalb nur benötigte Pakete und Dienste. Aktivieren Sie außerdem automatische Sicherheitsupdates, sofern Ihr Betriebsmodell dies erlaubt. Produktive Hosts sollten keine alltäglichen Benutzeranwendungen ausführen.

Prüfen Sie regelmäßig folgende Komponenten:

Linux-Kernel und Betriebssystem
Docker Engine oder alternative Container-Runtime
Laufzeitkomponenten wie containerd und runc
SSH-Konfiguration
Firewall-Regeln
AppArmor- oder SELinux-Richtlinien

Zusätzlich sollten nur autorisierte Administratoren Zugriff erhalten. Nutzen Sie SSH-Schlüssel und eine zentrale Identitätsverwaltung. Protokollieren Sie außerdem administrative Anmeldungen.

2. Rootless Docker verwenden

Im Rootless Mode laufen Docker-Daemon und Container ohne Root-Rechte. Dadurch besitzt ein erfolgreicher Angreifer zunächst weniger Rechte auf dem Host.

Rootless Docker eignet sich insbesondere für Entwicklungsumgebungen und viele Einzelserver. Bestimmte Netzwerkfunktionen oder privilegierte Ports können jedoch Einschränkungen verursachen.

Prüfen Sie zunächst die Voraussetzungen:

docker info | grep -i rootless

Die Einrichtung erfolgt auf unterstützten Linux-Systemen über das Rootless-Installationswerkzeug. Testen Sie danach Netzwerke, Volumes und bestehende Compose-Projekte.

Der Rootless Mode ersetzt dennoch keine weiteren Schutzmaßnahmen. Auch ein unprivilegiertes Benutzerkonto kann sensible Daten oder Anwendungen besitzen.

3. Container nicht als Root starten

Viele Container laufen standardmäßig als Root. Ein Angreifer erhält dann innerhalb des Containers umfassende Rechte. Bei weiteren Schwachstellen kann daraus ein Angriff auf den Host entstehen.

Legen Sie deshalb bereits im Dockerfile einen Benutzer fest:

FROM python:3.13-slim

RUN groupadd --system appgroup \
    && useradd --system --gid appgroup --no-create-home appuser

WORKDIR /app
COPY --chown=appuser:appgroup . /app

USER appuser
CMD ["python", "app.py"]

Kontrollieren Sie danach die effektive Benutzer-ID:

docker run --rm mein-image id

Die Ausgabe sollte keine UID 0 zeigen. Falls die Anwendung Schreibzugriff benötigt, geben Sie nur einzelne Verzeichnisse frei.

4. Kleine und vertrauenswürdige Images einsetzen

Ein großes Image enthält oft zahlreiche ungenutzte Pakete. Jedes zusätzliche Paket kann Schwachstellen mitbringen. Deshalb sollten Sie möglichst kleine Basis-Images verwenden.

Geeignet sind beispielsweise schlanke Debian-Varianten oder sorgfältig getestete Distroless-Images. Alpine Linux ist ebenfalls klein. Allerdings kann dessen musl-Bibliothek Kompatibilitätsprobleme verursachen.

Beachten Sie bei der Auswahl folgende Punkte:

offizieller oder verifizierter Herausgeber
dokumentierter Update-Prozess
regelmäßige Sicherheitsaktualisierungen
geringe Anzahl installierter Pakete
nachvollziehbare Versionskennzeichnung
Unterstützung Ihrer Anwendung

Entfernen Sie außerdem Compiler und Build-Werkzeuge aus dem finalen Image. Multi-Stage Builds helfen dabei.

5. Images auf feste Versionen festlegen

Ein allgemeines Tag wie latest ist nicht unveränderlich. Heute kann es auf ein anderes Image zeigen als morgen. Das erschwert reproduzierbare Builds und sichere Rollbacks.

Verwenden Sie mindestens eine konkrete Version:

FROM nginx:1.28.0

Für besonders kontrollierte Umgebungen können Sie zusätzlich einen Digest festlegen:

FROM nginx:1.28.0@sha256:BEISPIEL_DIGEST

Ein Digest identifiziert einen konkreten Image-Inhalt. Allerdings erhalten Sie danach keine Aktualisierung automatisch. Deshalb muss ein Update-Werkzeug neue Digests kontrolliert einspielen.

6. Multi-Stage Builds verwenden

Multi-Stage Builds trennen die Erstellung einer Anwendung vom späteren Betrieb. Dadurch bleiben Compiler, Quellcode und temporäre Dateien außerhalb des Produktiv-Images.

Ein vereinfachtes Beispiel sieht so aus:

FROM golang:1.25 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/webapp ./cmd/webapp

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/webapp /webapp
USER nonroot:nonroot
ENTRYPOINT ["/webapp"]

Das finale Image enthält nur die ausführbare Anwendung. Somit sinken Größe und Angriffsfläche. Gleichzeitig übertragen Sie weniger interne Build-Dateien in die Produktion.

7. Schwachstellenscans automatisieren

Scannen Sie Images nicht erst nach der Bereitstellung. Integrieren Sie die Prüfung direkt in Ihre CI/CD-Pipeline.

Mögliche Werkzeuge sind Docker Scout, Trivy, Grype oder Scanner Ihrer Registry. Sie erkennen bekannte Schwachstellen anhand öffentlicher Datenbanken. Zudem können sie Software Bills of Materials auswerten.

Ein Scan mit Docker Scout kann beispielsweise so aussehen:

docker scout cves mein-image:1.0

Definieren Sie danach verbindliche Regeln. Ein Build könnte beispielsweise bei kritischen Schwachstellen scheitern. Berücksichtigen Sie jedoch, ob die betroffene Komponente wirklich erreichbar ist.

Tipp: Bewerten Sie nicht ausschließlich den CVSS-Wert. Beachten Sie zusätzlich Ausnutzbarkeit, Erreichbarkeit und Bedeutung der Anwendung.

8. Linux Capabilities reduzieren

Container erhalten standardmäßig ausgewählte Kernel-Berechtigungen. Viele Anwendungen benötigen davon nur einen kleinen Teil.

Entfernen Sie daher zunächst alle Capabilities. Fügen Sie anschließend nur benötigte Rechte wieder hinzu:

docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  meine-anwendung:1.0

Ein Webserver benötigt NET_BIND_SERVICE nur für Ports unter 1024. Alternativ können Sie intern einen höheren Port verwenden. Dann entfällt auch diese Capability.

Vermeiden Sie insbesondere mächtige Berechtigungen wie SYS_ADMIN. Diese Capability umfasst viele Funktionen und vergrößert das Risiko erheblich.

9. Privilegierte Container vermeiden

Die Option --privileged gewährt einem Container weitreichenden Zugriff auf den Host. Zudem werden zahlreiche Schutzmechanismen abgeschwächt.

Nutzen Sie diese Option daher nicht aus Bequemlichkeit. Ermitteln Sie stattdessen, welche konkrete Berechtigung fehlt. Geben Sie anschließend nur diese Capability oder dieses Gerät frei.

Prüfen Sie bestehende Container mit:

docker inspect \
  --format '{{.Name}} privileged={{.HostConfig.Privileged}}' \
  $(docker ps -q)

Privilegierte Container können für spezielle Infrastrukturkomponenten erforderlich sein. In diesem Fall sollten sie auf getrennten Hosts oder Nodes laufen. Dokumentieren Sie außerdem die Begründung.

10. Dateisystem schreibgeschützt einbinden

Viele Anwendungen müssen ihren Programmcode während des Betriebs nicht verändern. Ein schreibgeschütztes Root-Dateisystem erschwert daher Manipulationen.

Starten Sie einen Container beispielsweise so:

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  meine-anwendung:1.0

Die Anwendung kann dann lediglich in ausdrücklich freigegebene Volumes oder temporäre Dateisysteme schreiben. Dadurch werden auch unerwartete Schreibzugriffe sichtbar.

Testen Sie diese Einstellung gründlich. Manche Anwendungen schreiben Cache-Dateien, PID-Dateien oder temporäre Daten in ungeeignete Verzeichnisse.

11. Ressourcen begrenzen

Ein fehlerhafter oder angegriffener Container kann den Host überlasten. Begrenzen Sie deshalb Arbeitsspeicher, CPU-Zeit, Prozesse und Log-Größe.

Ein Beispiel:

docker run \
  --memory=512m \
  --cpus=1.0 \
  --pids-limit=200 \
  meine-anwendung:1.0

Setzen Sie realistische Werte anhand von Messdaten. Zu enge Grenzen verursachen hingegen unnötige Ausfälle.

Begrenzen Sie zusätzlich die Protokollgröße:

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "5"

Ohne Rotation können Container-Logs den Speicherplatz des Hosts vollständig belegen.

12. Docker-Socket niemals unkontrolliert einbinden

Der Docker-Socket /var/run/docker.sock steuert den Docker-Daemon. Ein Container mit Zugriff auf diesen Socket kann häufig neue Container starten oder Host-Verzeichnisse einbinden.

Damit entspricht der Zugriff praktisch weitreichenden Administratorrechten. Geben Sie den Socket deshalb nicht an gewöhnliche Anwendungen weiter.

Falls ein Verwaltungswerkzeug ihn benötigt, gelten mindestens diese Maßnahmen:

separates und vertrauenswürdiges Managementsystem
eingeschränkter Socket-Proxy
genau definierte API-Endpunkte
Netzwerksegmentierung
laufende Überwachung
dokumentierte Risikofreigabe

Auch eine schreibgeschützte Einbindung schützt nicht zuverlässig. Die Docker-API kann weiterhin zustandsverändernde Anfragen erlauben.

13. Secrets sicher verwalten

Passwörter, API-Schlüssel und Zertifikate gehören nicht in ein Dockerfile. Ebenso dürfen sie nicht in Image-Layern oder öffentlichen Repositorys landen.

Nutzen Sie stattdessen eine Secret-Verwaltung. Docker Swarm, Kubernetes und verschiedene Cloud-Plattformen bieten dafür eigene Mechanismen. Externe Systeme wie HashiCorp Vault sind ebenfalls möglich.

Beachten Sie folgende Regeln:

Secrets erst zur Laufzeit bereitstellen
Zugriffe nach dem Minimalprinzip vergeben
Schlüssel regelmäßig rotieren
Zugriffe protokollieren
Secrets nicht in Logs ausgeben
keine Zugangsdaten in Build-Argumenten speichern

Umgebungsvariablen sind bequem. Sie können jedoch über Prozessinformationen, Diagnoseausgaben oder Fehlermeldungen sichtbar werden. Eingebundene Secret-Dateien sind daher häufig geeigneter.

14. Netzwerke segmentieren

Alle Container müssen nicht miteinander kommunizieren. Erstellen Sie deshalb getrennte Netzwerke für Frontend, Anwendung und Datenbank.

Ein Reverse Proxy darf beispielsweise den Webdienst erreichen. Die Datenbank sollte hingegen nur mit dem Anwendungsdienst sprechen.

Veröffentlichen Sie außerdem nur zwingend benötigte Ports. Bei einem lokalen Verwaltungsdienst können Sie an die Loopback-Adresse binden:

ports:
  - "127.0.0.1:8080:8080"

Dadurch ist der Dienst nicht direkt über alle Netzwerkschnittstellen erreichbar. Eine Firewall bleibt dennoch erforderlich.

15. Laufzeit überwachen und regelmäßig prüfen

Ein sicher gebautes Image kann während des Betriebs angegriffen werden. Deshalb benötigen Sie Protokolle, Metriken und Warnungen.

Überwachen Sie insbesondere:

unerwartete Prozesse
neue Netzwerkverbindungen
Änderungen an wichtigen Dateien
fehlgeschlagene Anmeldungen
ungewöhnliche Ressourcennutzung
Container-Neustarts
Änderungen an Images und Konfigurationen

Werkzeuge wie Falco erkennen verdächtige Laufzeitereignisse. Zusätzlich können Prometheus, Grafana und ein zentrales Log-System technische Auffälligkeiten sichtbar machen.

Definieren Sie außerdem Verantwortlichkeiten. Ein Alarm ohne klaren Bearbeiter bietet nur begrenzten Schutz.

Docker und Container sicher betreiben mit Compose

Docker Compose erleichtert den Betrieb mehrerer Dienste. Gleichzeitig lassen sich wichtige Sicherheitsoptionen direkt in der Compose-Datei festlegen.

Beispiel einer gehärteten Compose-Konfiguration

Das folgende Beispiel zeigt einen eingeschränkten Webdienst:

services:
  web:
    image: registry.example.com/webapp:1.4.2
    user: "10001:10001"

    read_only: true

    tmpfs:
      - /tmp:size=64m,noexec,nosuid

    cap_drop:
      - ALL

    security_opt:
      - no-new-privileges:true

    pids_limit: 200

    mem_limit: 512m
    cpus: 1.0

    ports:
      - "127.0.0.1:8080:8080"

    networks:
      - frontend

    restart: unless-stopped

    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "5"

networks:
  frontend:
    driver: bridge

Die Anwendung läuft ohne Root-Rechte. Außerdem ist das Root-Dateisystem schreibgeschützt. Alle Linux Capabilities werden entfernt.

Der veröffentlichte Port lauscht nur lokal. Ein Reverse Proxy kann ihn daher erreichen, während ein externer Direktzugriff verhindert wird.

Schritt-für-Schritt zur sicheren Bereitstellung

Gehen Sie bei einer neuen Anwendung strukturiert vor:

Wählen Sie ein vertrauenswürdiges Basis-Image.
Legen Sie eine feste Version oder einen Digest fest.
Bauen Sie das Image mit einer Multi-Stage-Struktur.
Erstellen Sie einen unprivilegierten Anwendungsbenutzer.
Scannen Sie das Ergebnis auf Schwachstellen.
Entfernen Sie unnötige Capabilities.
Aktivieren Sie ein schreibgeschütztes Dateisystem.
Begrenzen Sie CPU, Arbeitsspeicher und Prozesse.
Veröffentlichen Sie nur benötigte Ports.
Testen Sie Protokollierung, Backup und Wiederherstellung.

Führen Sie danach einen Funktionstest durch. Prüfen Sie zudem, ob die Anwendung nach einem Container-Neustart korrekt arbeitet.

Container-Images und Lieferkette schützen

Die Software-Lieferkette umfasst Quellcode, Abhängigkeiten, Build-System und Registry. Ein Angriff auf eine dieser Stationen kann vertrauenswürdig wirkende Images erzeugen.

Images signieren und Herkunft prüfen

Digitale Signaturen helfen bei der Prüfung eines Images. Sie bestätigen, wer ein Artefakt veröffentlicht hat. Dafür eignen sich beispielsweise Sigstore Cosign oder integrierte Funktionen einer Registry.

Zusätzlich sollten Sie nur Images aus freigegebenen Registrys einsetzen. Ein Admission-Controller kann in Kubernetes nicht signierte Images blockieren.

Eine Signatur garantiert jedoch nicht automatisch fehlerfreie Software. Sie bestätigt in erster Linie Herkunft und Integrität. Schwachstellenscans bleiben daher notwendig.

SBOM erstellen

Eine Software Bill of Materials, kurz SBOM, listet enthaltene Komponenten auf. Sie funktioniert ähnlich wie eine Zutatenliste.

Bei einer neuen Sicherheitslücke können Sie damit schnell nach betroffenen Images suchen. Außerdem verbessert eine SBOM die Nachvollziehbarkeit gegenüber Kunden oder Prüfern.

Erzeugen Sie die SBOM möglichst während des Builds. Speichern Sie sie anschließend zusammen mit dem Image und dessen Signatur.

Registry absichern

Schützen Sie private Registrys durch starke Authentifizierung und rollenbasierte Berechtigungen. Entwickler benötigen beispielsweise nicht automatisch Löschrechte.

Aktivieren Sie außerdem TLS und Audit-Protokolle. Bereinigen Sie veraltete Images erst nach einer definierten Aufbewahrungsfrist. Rollbacks müssen weiterhin möglich bleiben.

Netzwerk und veröffentlichte Ports absichern

Docker kann Firewall-Regeln automatisch verändern. Administratoren sollten deshalb genau verstehen, welche Ports tatsächlich veröffentlicht werden.

Prüfen Sie die aktuellen Zuordnungen mit:

docker ps --format \
  'table {{.Names}}\t{{.Ports}}\t{{.Networks}}'

Kontrollieren Sie zusätzlich die Firewall des Hosts. Docker-Regeln und eigene Filterregeln müssen zusammenwirken.

Praxisbeispiel: Webanwendung mit Datenbank

Eine typische Anwendung besteht aus Reverse Proxy, Webdienst und Datenbank. Nur der Reverse Proxy benötigt einen öffentlich erreichbaren Port.

Der Webdienst bleibt in einem internen Netzwerk. Die Datenbank erhält ebenfalls keinen Host-Port. Somit kann ein externer Client sie nicht direkt ansprechen.

Diese Trennung reduziert laterale Bewegungen. Ein kompromittierter Frontend-Dienst erreicht dadurch weniger interne Komponenten.

Secrets und sensible Daten verwalten

Sensible Daten können an mehreren Stellen versehentlich auftauchen. Dazu zählen Git-Repositorys, Build-Logs, Image-Historien und Sicherungen.

Prüfen Sie ein Image deshalb auch auf versehentlich eingebettete Dateien:

docker history --no-trunc mein-image:1.0

Nutzen Sie für Build-Zugangsdaten die Secret-Mounts von BuildKit. Dadurch gelangen die Werte nicht dauerhaft in einen Layer.

Backups von Volumes benötigen ebenfalls Schutz. Verschlüsseln Sie sensible Sicherungen und testen Sie die Wiederherstellung regelmäßig. Ein vorhandenes Backup ist wertlos, wenn es sich nicht zuverlässig einspielen lässt.

Überwachung, Protokollierung und Incident Response

Container erzeugen häufig viele kurzlebige Ereignisse. Eine zentrale Sammlung erleichtert deshalb die spätere Untersuchung.

Erfassen Sie mindestens folgende Informationen:

Containername und Image-Digest
Start- und Endzeit
Benutzer und Deployment-Quelle
Anwendungs- und Zugriffsprotokolle
sicherheitsrelevante Laufzeitereignisse
Änderungen an Netzwerken und Volumes

Synchronisieren Sie außerdem die Systemzeit. Andernfalls lassen sich Ereignisse verschiedener Hosts nur schwer vergleichen.

Vorgehen bei einem verdächtigen Container

Bei einem Sicherheitsverdacht sollten Sie Beweise erhalten und gleichzeitig Schäden begrenzen:

Isolieren Sie den betroffenen Dienst vom Netzwerk.
Dokumentieren Sie Container-ID, Image-Digest und Host.
Sichern Sie relevante Logs und Metadaten.
Prüfen Sie laufende Prozesse und Verbindungen.
Rotieren Sie erreichbare Secrets und Zugangsdaten.
Erstellen Sie ein bereinigtes Image aus vertrauenswürdigem Quellcode.
Stellen Sie den Dienst kontrolliert neu bereit.
Analysieren Sie anschließend Ursache und Eintrittsweg.

Ändern Sie einen kompromittierten Container nicht manuell weiter. Eine saubere Neuerstellung ist nachvollziehbarer und zuverlässiger.

Docker und Container sicher betreiben in Kubernetes

Kubernetes erweitert Container-Umgebungen um zusätzliche Komponenten. Dazu gehören API-Server, Nodes, Service Accounts und Admission-Regeln.

Die Kubernetes Pod Security Standards definieren abgestufte Sicherheitsprofile. Für produktive Anwendungen ist das Profil „Restricted“ eine gute Orientierung. Es fordert unter anderem eingeschränkte Rechte und einen Betrieb ohne Root.

Beispiel für einen Security Context

Eine gehärtete Pod-Konfiguration kann folgende Einstellungen enthalten:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001
  seccompProfile:
    type: RuntimeDefault

containers:
  - name: web
    image: registry.example.com/webapp:1.4.2
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Zusätzlich benötigen Sie Network Policies und eingeschränkte Service Accounts. Begrenzen Sie außerdem den Zugriff auf Kubernetes-Secrets.

Kubernetes dokumentiert, dass allowPrivilegeEscalation: false eine Rechteausweitung verhindert. readOnlyRootFilesystem bindet hingegen das Root-Dateisystem schreibgeschützt ein. Kubernetes-Dokumentation zum Security Context

Häufige Fehler bei der Container-Sicherheit

Viele Sicherheitsprobleme entstehen durch wiederkehrende Fehlkonfigurationen. Die folgende Tabelle zeigt typische Beispiele:

Fehler	Mögliche Folge	Bessere Lösung
Verwendung von `latest`	Unkontrollierte Änderungen	Version oder Digest festlegen
Container läuft als Root	Größere Auswirkungen eines Angriffs	Eigenen Benutzer definieren
`--privileged` aktiviert	Weitreichender Hostzugriff	Einzelne Rechte freigeben
Docker-Socket eingebunden	Kontrolle über Docker möglich	Socket vermeiden oder Proxy nutzen
Secrets im Dockerfile	Zugangsdaten bleiben im Image	Secret-Verwaltung einsetzen
Alle Ports veröffentlicht	Unnötige Angriffsfläche	Nur benötigte Ports freigeben
Keine Ressourcenlimits	Überlastung des Hosts	CPU, RAM und Prozesse begrenzen
Kein Image-Scan	Bekannte Lücken bleiben unentdeckt	Scans in CI/CD integrieren
Fehlende Log-Rotation	Datenträger läuft voll	Größe und Anzahl begrenzen
Container werden nur neu gestartet	Ursache bleibt bestehen	Image korrigieren und neu ausrollen

Besonders problematisch ist die Kombination mehrerer Fehler. Ein Root-Container mit Docker-Socket und öffentlich erreichbarem Dienst stellt beispielsweise ein erhebliches Risiko dar.

Vorteile und Grenzen sicherer Container

Container bieten viele betriebliche Vorteile. Dennoch müssen Betreiber ihre Grenzen berücksichtigen.

Vorteile

Eine konsequent gehärtete Container-Plattform bietet folgende Stärken:

reproduzierbare Bereitstellungen
klar definierte Abhängigkeiten
schnelle Aktualisierungen und Rollbacks
automatisierbare Sicherheitskontrollen
gute Trennung einzelner Anwendungen
einheitliche Tests in CI/CD
einfache Skalierung

Besonders hilfreich ist die Unveränderlichkeit von Images. Änderungen erfolgen über einen neuen Build statt durch manuelle Eingriffe.

Nachteile und Grenzen

Container erhöhen zugleich die technische Komplexität. Teams müssen Images, Hosts, Registrys und Pipelines absichern.

Außerdem teilen sich Container normalerweise den Host-Kernel. Virtuelle Maschinen bieten deshalb in bestimmten Szenarien eine stärkere Isolation. Das gilt insbesondere für nicht vertrauenswürdige oder stark regulierte Workloads.

Zusätzliche Werkzeuge verursachen ebenfalls Aufwand. Scanner und Laufzeitüberwachung benötigen Pflege, Regeln und kompetente Auswertung.

Zusammenfassende Checkliste

Nutzen Sie diese Checkliste für neue und bestehende Container-Umgebungen:

Docker-Host ist minimal installiert und vollständig aktualisiert.
Administrative Zugriffe sind eingeschränkt und protokolliert.
Rootless Docker wurde geprüft oder aktiviert.
Anwendungen laufen nicht als Root.
Images stammen aus vertrauenswürdigen Quellen.
Image-Versionen oder Digests sind festgelegt.
Multi-Stage Builds reduzieren unnötige Komponenten.
Images werden während des Builds gescannt.
Kritische Schwachstellen besitzen einen geregelten Prozess.
Alle unnötigen Linux Capabilities sind entfernt.
Privilegierte Container sind verboten oder begründet.
Das Root-Dateisystem ist möglichst schreibgeschützt.
CPU, Arbeitsspeicher und Prozessanzahl sind begrenzt.
Der Docker-Socket ist nicht unkontrolliert eingebunden.
Secrets befinden sich weder im Image noch im Repository.
Netzwerke trennen Frontend, Anwendung und Datenbank.
Nur erforderliche Ports sind veröffentlicht.
Logs werden zentral gesammelt und rotiert.
Laufzeitereignisse und Neustarts werden überwacht.
Backups und Wiederherstellung werden regelmäßig getestet.
Images können eindeutig einem Build zugeordnet werden.
SBOM und Signaturen werden für kritische Images eingesetzt.
Ein dokumentierter Incident-Response-Prozess ist vorhanden.

Fazit

Wer Docker und Container sicher betreiben möchte, benötigt mehr als einen Schwachstellenscanner. Entscheidend ist ein durchgängiges Sicherheitskonzept vom Quellcode bis zum laufenden Container.

Beginnen Sie mit einem minimalen und aktuellen Host. Verwenden Sie anschließend kleine Images und starten Sie Anwendungen ohne Root-Rechte. Entfernen Sie unnötige Capabilities und vermeiden Sie privilegierte Container.

Schützen Sie zudem Secrets, Netzwerke und den Docker-Socket. Automatisierte Scans erkennen bekannte Schwachstellen bereits während des Builds. Eine Laufzeitüberwachung deckt hingegen verdächtige Aktivitäten im Betrieb auf.

Sie müssen nicht alle Maßnahmen gleichzeitig einführen. Priorisieren Sie zunächst Root-Rechte, Secrets, privilegierte Container und öffentlich erreichbare Ports. Ergänzen Sie danach Signaturen, SBOMs und automatisierte Richtlinien.

Container-Sicherheit ist kein einmaliges Projekt. Sie ist ein wiederkehrender Prozess aus Aktualisierung, Kontrolle und Verbesserung.

FAQ zu Docker- und Container-Sicherheit

Wie kann ich Docker und Container sicher betreiben?

Verwenden Sie aktuelle Hosts, vertrauenswürdige Images und feste Versionen. Starten Sie Container zudem ohne Root-Rechte. Begrenzen Sie Capabilities, Ressourcen und Netzwerkzugriffe. Secrets dürfen nicht im Image liegen. Automatisierte Scans und eine laufende Überwachung ergänzen diese Maßnahmen.

Sind Docker-Container automatisch sicher voneinander getrennt?

Docker trennt Container durch Kernel-Funktionen wie Namespaces und Control Groups. Diese Isolation ist jedoch nicht mit einer vollständigen virtuellen Maschine identisch. Fehlkonfigurationen, Kernel-Lücken oder privilegierte Rechte können die Trennung schwächen.

Sollte Docker im Rootless Mode betrieben werden?

Rootless Docker reduziert die Rechte von Daemon und Containern auf dem Host. Deshalb verbessert es die Sicherheit vieler Umgebungen. Allerdings können bestimmte Netzwerk- oder Speicherfunktionen eingeschränkt sein. Testen Sie daher bestehende Anwendungen vor der Umstellung.

Warum sollte ein Container nicht als Root laufen?

Ein Root-Prozess besitzt innerhalb des Containers weitreichende Rechte. Bei einer weiteren Schwachstelle können daraus größere Auswirkungen auf Host oder eingebundene Volumes entstehen. Ein unprivilegierter Benutzer begrenzt hingegen den möglichen Schaden.

Sind kleine Container-Images sicherer?

Kleine Images enthalten meist weniger Pakete und Werkzeuge. Dadurch sinken Angriffsfläche und Anzahl möglicher Schwachstellen. Dennoch ist nicht jedes kleine Image automatisch sicher. Herkunft, Updates und Konfiguration bleiben entscheidend.

Reicht ein Image-Scan für sichere Container aus?

Nein. Ein Scan erkennt hauptsächlich bekannte Schwachstellen in Paketen und Abhängigkeiten. Fehlkonfigurationen, gestohlene Zugangsdaten oder Angriffe während der Laufzeit bleiben möglicherweise unentdeckt. Deshalb benötigen Sie mehrere Schutzebenen.

Darf ich den Docker-Socket in einen Container einbinden?

Das sollte nur in begründeten Ausnahmefällen geschehen. Zugriff auf den Docker-Socket ermöglicht häufig weitreichende Kontrolle über den Host. Nutzen Sie möglichst eine andere Schnittstelle oder einen eingeschränkten Socket-Proxy.

Wie oft sollten Container-Images aktualisiert werden?

Bauen Sie Images regelmäßig und bei sicherheitsrelevanten Änderungen neu. Ein automatisierter Prozess sollte neue Basis-Images und Schwachstellen erkennen. Kritische Lücken benötigen einen beschleunigten Patch- und Rollout-Prozess.

Empfehlung zum Weiterlesen

Wie sicher ist Ihre Container-Umgebung? Nutzen Sie die Checkliste und prüfen Sie Ihre Docker-Hosts, Images und Compose-Dateien. Weitere praxisnahe Anleitungen zu Linux, Server-Sicherheit und Schwachstellenmanagement finden Sie bei Lumio Studios.