Container Security -- Best Practices für die Produktion

“Container sind isoliert, also sind sie sicher.” Das dachten wir – bis ein Penetrationstester innerhalb einer halben Stunde aus einem Container zum Root auf dem Host eskalierte. Container sind keine VMs, und das Sicherheitsmodell ist grundlegend anders.

Ein Container ist keine Sandbox¶

Ein Docker-Container teilt sich den Kernel mit dem Host. Namespaces und Cgroups bieten Prozess-, Netzwerk-Stack- und Dateisystem-Isolation – aber es ist keine Hardware-Virtualisierung. Ein Kernel-Exploit innerhalb eines Containers = ein Kernel-Exploit auf dem Host. Das ist der fundamentale Unterschied zu VMs, und das muss berücksichtigt werden.

Das bedeutet nicht, dass Container unsicher sind. Es bedeutet, dass Sie die Sicherheit auf jeder Ebene adressieren müssen – vom Base Image über die Build-Pipeline bis zur Runtime-Konfiguration.

Base Image – Angriffsfläche minimieren¶

Jedes Paket in einem Image ist eine potenzielle Schwachstelle. Ein Ubuntu-Base-Image enthält Hunderte von Paketen, die Ihre Anwendung nicht braucht – und jedes davon kann eine CVE haben. Regel Nummer eins: Verwenden Sie ein minimales Base Image.

# Container Security -- Best Practices für die Produktion
FROM ubuntu:16.04

# ✅ Besser -- Alpine, 5 MB, minimale Pakete
FROM alpine:3.6

# ✅ Am besten -- Distroless, nur Runtime
FROM gcr.io/distroless/java:latest

Alpine Linux ist ein guter Kompromiss – 5 MB, musl libc, apk Package Manager. Für maximale Sicherheit sollten Sie Distroless Images von Google in Betracht ziehen: keine Shell, kein Package Manager, keine Utilities. Ein Angreifer, der in den Container gelangt, hat nicht einmal ls.

Multi-Stage Builds – Build und Runtime trennen¶

Build-Tools (gcc, npm, maven) haben in einem Produktions-Image nichts zu suchen. Multi-Stage Builds trennen die Kompilierung vom finalen Image.

FROM golang:1.9 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .

FROM alpine:3.6
RUN adduser -D -u 1001 appuser
COPY --from=builder /app/server /server
USER appuser
EXPOSE 8080
CMD ["/server"]

Das resultierende Image enthält nur die Binärdatei und Alpine. Kein Go-Toolchain, kein Quellcode, keine Build-Abhängigkeiten. Kleineres Image = kleinere Angriffsfläche = schnelleres Deployment.

Nicht als Root ausführen¶

Eine überraschende Anzahl von Docker-Images läuft als Root. Wenn die Anwendung keinen privilegierten Port oder Zugriff auf Systemressourcen benötigt, fügen Sie immer eine USER-Direktive hinzu. Root innerhalb eines Containers kann unter bestimmten Umständen zu Root auf dem Host eskalieren.

In Kubernetes verwenden Sie securityContext auf Pod-Ebene:

securityContext:
  runAsNonRoot: true
  runAsUser: 1001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

readOnlyRootFilesystem verhindert Schreibvorgänge im Dateisystem des Containers – ein Angreifer kann keine Malware persistieren. drop ALL capabilities entfernt Linux-Capabilities, die die Anwendung nicht benötigt.

Image Scanning – CVEs vor dem Angreifer finden¶

Jedes Image sollte vor dem Deployment in die Produktion einen Vulnerability Scanner durchlaufen. Tools wie Clair, Trivy oder Anchore analysieren Image-Schichten und vergleichen Pakete mit CVE-Datenbanken.

Wir scannen an zwei Stellen: in der CI-Pipeline (Build-Zeit) und in der Registry (kontinuierlicher Scan). Build-Zeit-Scanning blockiert Deployments mit kritischen CVEs. Kontinuierliches Scanning erkennt neu entdeckte Schwachstellen in Images, die bereits in der Produktion laufen.

Der Schlüssel ist die Festlegung einer Policy: Was ist akzeptabel und was nicht. Null Toleranz für kritische CVEs im Base Image. Mittlere Schweregrade mit einem Behebungsplan innerhalb von 30 Tagen. Niedrige Schweregrade werden verfolgt, blockieren aber nicht das Deployment.

Supply Chain – Vertrauen, aber prüfen¶

docker pull node:latest – wissen Sie genau, was Sie herunterladen? Wer hat dieses Image erstellt? Wurde es modifiziert? Docker Content Trust (Notary) ermöglicht das Signieren von Images. Aktivieren Sie es und akzeptieren Sie nur signierte Images.

Verwenden Sie spezifische Tags, nicht :latest. Noch besser: Pinnen Sie auf einen Digest. Ein Tag kann überschrieben werden; ein Digest ist ein unveränderlicher Hash. Und betreiben Sie Ihre eigene Registry (Harbor, GitLab Registry) statt direkt vom Docker Hub zu ziehen.

Runtime-Schutz¶

Build-Zeit-Sicherheit reicht nicht aus. Zur Laufzeit brauchen Sie Anomalie-Erkennung. Seccomp-Profile beschränken Systemaufrufe – ein Container, der normalerweise HTTP-Anfragen stellt, hat keinen Grund, ptrace oder mount aufzurufen. AppArmor oder SELinux-Profile fügen eine weitere Schicht von Mandatory Access Control hinzu.

Network Policies in Kubernetes fungieren als Firewall zwischen Pods. Default Deny – kein Pod kommuniziert mit einem anderen, es sei denn, Sie erlauben es explizit. Ein Zahlungs-Microservice hat keinen Grund, mit dem CMS zu kommunizieren.

Secrets Management¶

Backen Sie niemals Secrets in ein Image ein. Weder als Umgebungsvariable im Dockerfile noch als Datei im Build-Kontext. Secrets gehören in Kubernetes Secrets (idealerweise mit einem externen Backend wie HashiCorp Vault), gemountet als Volumes, automatisch rotiert.

Scannen Sie die Image-Layer-Historie – docker history zeigt alle Schichten einschließlich gelöschter Dateien. Ein Secret, das hinzugefügt und dann im nächsten RUN-Befehl gelöscht wurde, befindet sich immer noch in der vorherigen Schicht.

Sicherheit als kontinuierlicher Prozess¶

Container Security ist kein einmaliges Audit. Es ist ein kontinuierlicher Prozess, der in den gesamten Lebenszyklus integriert ist – vom Dockerfile über die CI-Pipeline bis zum Runtime-Monitoring. Beginnen Sie mit den Grundlagen: Non-Root, minimale Images, CI-Scanning. Fügen Sie schrittweise Seccomp, Network Policies und Runtime-Erkennung hinzu. Jede Schicht erschwert dem Angreifer die Arbeit.