Docker Security Hardening: 15 konkrete Maßnahmen für Production:
15 konkrete Maßnahmen für Production

Warum Docker-Hardening kein Nice-to-have ist

Docker ist schnell, flexibel und produktiv – aber out-of-the-box nicht automatisch "sicher genug" für kritische Workloads. Viele Incidents entstehen nicht durch Zero-Days, sondern durch fehlende Basis-Hygiene: zu offene Netzwerkpfade, überprivilegierte Container oder unkontrollierte Images.

Die gute Nachricht: Mit wenigen Standards kannst du das Risiko stark reduzieren, ohne die Entwicklergeschwindigkeit zu verlieren.

15 konkrete Hardening-Maßnahmen

1. Rootless Docker wo möglich aktivieren.
2. Container nicht als root laufen lassen (USER im Dockerfile).
3. Read-only Filesystem für stateless Services.
4. Capabilities minimieren (z. B. --cap-drop=ALL).
5. No-new-privileges setzen.
6. Seccomp-Profile nutzen (Default oder gehärtet).
7. AppArmor/SELinux aktiv einsetzen.
8. Trusted Base Images mit kleiner Angriffsfläche (distroless/alpine wo sinnvoll).
9. Image-Scanning in CI integrieren (Trivy/Grype).
10. Image-Signing und Verifikation (Cosign/Sigstore).
11. Secrets niemals im Image, nur via Secret Store injizieren.
12. Netzwerksegmentierung mit getrennten Docker Networks.
13. Keine unnötigen Ports veröffentlichen.
14. Resource Limits setzen (CPU/RAM/PIDs).
15. Logging & Auditing zentralisieren und Alerts definieren.

Beispiel: Gehardete Compose-Definition

services:
  app:
    image: ghcr.io/example/app:1.2.3
    user: "10001:10001"
    read_only: true
    cap_drop: ["ALL"]
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp:size=64m,noexec,nosuid
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M

Hardening in die CI/CD-Pipeline bringen

Security wird stabil, wenn sie automatisiert ist. Baue Scans und Policy-Checks als Gate in deine Pipeline – nicht als manuellen Nachtrag kurz vor Go-Live.

trivy image --severity HIGH,CRITICAL --exit-code 1 ghcr.io/example/app:1.2.3
cosign verify ghcr.io/example/app:1.2.3

Praxis-Checkliste für den Rollout in 7 Tagen

Damit Hardening nicht in Tickets stecken bleibt, hier ein kompakter Rollout-Plan:

• Tag 1: Inventory aller produktiven Container + Owner festlegen.
• Tag 2: Non-root + cap_drop + no-new-privileges als Standard.
• Tag 3: Image-Scanning als CI-Gate aktivieren (HIGH/CRITICAL blockieren).
• Tag 4: Secrets aus Images entfernen, nur noch Secret Store/Runtime-Injection.
• Tag 5: Netzwerksegmentierung und Port-Exposure minimieren.
• Tag 6: Read-only RootFS + tmpfs für schreibbare Pfade.
• Tag 7: Alerting auf Security-Ereignisse + kurzer Restore-/Incident-Drill.

Typische Fehler in der Praxis

• "Privileged" als Quick-Fix: kurzfristig bequem, langfristig hohes Risiko.
• Zu breite Exceptions: eine Ausnahme wird schnell zum neuen Standard.
• Security nur im Audit-Monat: ohne Pipeline-Automation fällt man sofort zurück.

Hardening-Roadmap für kleine Teams

Wenn ihr mit wenig Kapazität arbeitet, priorisiert in dieser Reihenfolge: erst Runtime-Rechte (non-root, no-new-privileges), dann Supply-Chain (Scanning + Signing), danach Netzwerk und Monitoring. Diese Reihenfolge reduziert das Risiko am schnellsten.

Wichtig: Definiert einen "Security Owner" pro Service. Ohne klare Ownership werden Hardening-Maßnahmen meist nur halb umgesetzt und später wieder aufgeweicht.

Fazit

Docker-Sicherheit ist kein einzelnes Tool, sondern ein Set aus Standards. Fang mit den Top-5 an (non-root, cap-drop, read-only, scanning, secrets) und erweitere iterativ. So bekommst du schnell messbare Sicherheitsgewinne ohne Delivery zu bremsen.