Docker macht Deployment einfach – aber einfach bedeutet nicht automatisch sicher. Ein Container ist kein Sicherheitsmechanismus, sondern ein Isolierungsmechanismus. Was drin läuft, bestimmst du. Diese sechs Maßnahmen kosten zusammen keine Stunde Implementierungszeit, aber sie schließen die häufigsten Angriffsvektoren, die wir in der Praxis sehen. 1. Nicht als Root laufen Standardmäßig läuft jeder Container-Prozess als root (UID 0). Das bedeutet: Wenn ein Angreifer aus dem Container ausbricht, hat er auf dem Host root-Rechte. Das ist kein theoretisches Risiko. FROM node:20-alpine WORKDIR /app COPY . . RUN npm ci --omit=dev RUN addgroup -S app && adduser -S app -G app USER app CMD ["node", "server.js"] Viele offizielle Images bieten bereits einen Non-Root-User an ( node , nginx , www-data ). Nutze ihn. 2. Filesystem read-only Ein Container, der nichts schreiben kann, kann keine Malware ablegen, keine Konfiguration manipulieren und keine Backdoor installieren. services: api: image: myapp:latest read_only: true tmpfs: - /tmp - /run 3. Den Docker-Socket niemals mounten Das ist der gefährlichste Fehler in produktiven Setups. Wenn du den Docker-Socket in einen Container mountest, hast du dem Container volle Kontrolle über den gesamten Docker-Daemon gegeben – und damit über den Host. # Niemals so: volumes: - /var/run/docker.sock:/var/run/docker.sock # Stattdessen: rootless Docker, Podman oder einen Socket-Proxy verwenden 4. Resource Limits setzen Ohne Limits kann ein einziger kompromittierter Container den gesamten Host in die Knie zwingen – sei es durch eine Endlosschleife, einen Fork-Bomb-Exploit oder einen Memory-Leak. services: worker: image: myworker:latest mem_limit: 512m memswap_limit: 512m cpus: "0.5" pids_limit: 100 5. Secrets nicht ins Image Ein ENV DB_PASSWORD=supersecret im Dockerfile landet in jeder Image-Schicht, ist in docker inspect sichtbar und wird in Container-Registries gespeichert. Für immer. # Niemals so: ENV DB_PASSWORD=meinpasswort123 # Richtig: zur Laufzeit übergeben docker run --env-file .env myapp:latest 6. Images regelmäßig scannen Jedes Image ist ein Snapshot. Abhängigkeiten, die heute sicher sind, haben morgen bekannte CVEs. Automatisches Scannen in der CI-Pipeline verhindert, dass verwundbare Images in Produktion landen. # Docker Scout (Plugin installieren falls noetig): # docker scout install docker scout cves myapp:latest # Trivy (Open-Source): trivy image myapp:latest Fazit Containerisierung gibt dir Isolation – aber keine Sicherheit. Diese sechs Maßnahmen sind die Mindestanforderungen für jeden produktiven Docker-Workload. Kombiniert brauchst du weniger als 30 Minuten, um sie auf ein bestehendes Projekt anzuwenden.
