Docker Container härten – 6 Sicherheitsregeln

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.

Docker-Container härten: 6 Sicherheitsregeln, die jeder kennen sollte