Docker Security Best Practices 2025 – Container absichern

Die häufigsten Docker-Sicherheitsfehler

1. Container laufen als root
2. Ungeprüfte Images aus Docker Hub
3. Zu viele Linux Capabilities
4. Sensitive Daten in Umgebungsvariablen oder Images
5. Veraltete Images ohne Patches
6. Docker-Socket als Volume gemountet

1. Rootless Container

# Schlechtes Beispiel – läuft als root
FROM node:20
WORKDIR /app
COPY . .
CMD ["node", "server.js"]

# Gutes Beispiel – eigener Benutzer
FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --chown=appuser:appgroup . .
USER appuser
CMD ["node", "server.js"]

Überprüfen:

docker run --rm myapp whoami
# Ausgabe: appuser (nicht root!)

2. Images scannen mit Trivy

# Trivy installieren
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Image auf CVEs scannen
trivy image nginx:latest
trivy image --severity HIGH,CRITICAL myapp:latest

# In CI/CD – Build abbrechen bei kritischen CVEs
trivy image --exit-code 1 --severity CRITICAL myapp:latest

3. Capabilities reduzieren

# Alle Capabilities entfernen, nur benötigte hinzufügen
docker run -d \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  nginx:alpine

# Keine neuen Privileges erlauben
docker run -d \
  --security-opt no-new-privileges:true \
  myapp:latest

4. Read-only Filesystem

# Nur bestimmte Pfade schreibbar
docker run -d \
  --read-only \
  --tmpfs /tmp \
  --tmpfs /run \
  -v /logs:/app/logs \
  myapp:latest

5. Secrets nicht in Images

# Schlechtes Beispiel
docker run -e DB_PASSWORD=geheim123 myapp

# Besser: Docker Secrets (Swarm) oder Umgebungsdatei
docker run --env-file /etc/myapp/secrets.env myapp

# Beste: Secrets-Manager (Vault, AWS Secrets Manager)

# NIEMALS Secrets im Dockerfile:
# ENV DB_PASSWORD=geheim  ← FALSCH!
# RUN curl -u user:pass   ← FALSCH! (in Layer sichtbar)

# Multi-Stage Build für Build-Secrets:
FROM golang:1.22 AS builder
RUN --mount=type=secret,id=github_token \
    cat /run/secrets/github_token | git clone ...

6. Docker Daemon absichern

// /etc/docker/daemon.json
{
  "userns-remap": "default",
  "no-new-privileges": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "icc": false,
  "default-ulimits": {
    "nofile": {"Name":"nofile","Hard":64000,"Soft":64000}
  }
}

7. Docker Socket nicht mounten

# GEFÄHRLICH – voller Root-Zugriff auf den Host!
docker run -v /var/run/docker.sock:/var/run/docker.sock myapp

# Alternative: Rootless Docker oder Socket-Proxy
docker run -d --name socket-proxy \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e CONTAINERS=1 \
  -p 127.0.0.1:2375:2375 \
  tecnativa/docker-socket-proxy

Security-Checkliste

• Container laufen nicht als root
• Images regelmäßig auf CVEs geprüft (Trivy)
• Capabilities auf Minimum reduziert
• Read-only Filesystem aktiviert
• Secrets nicht in Images oder Env-Vars
• Docker-Socket nicht als Volume
• Netzwerkisolation durch benutzerdefinierte Netze
• userns-remap in daemon.json aktiviert

FAQ

Wie richte ich Rootless Docker ein?
dockerd-rootless-setuptool.sh install – dann läuft der Docker-Daemon ohne root-Rechte.

Was ist der Unterschied zwischen rootless Docker und User-Namespace?
Rootless Docker: Der Daemon selbst läuft ohne root. User-Namespace (userns-remap): Der Daemon läuft als root, aber Container-Prozesse werden auf Host-UIDs gemappt.

Fazit

Container-Sicherheit ist nicht optional. Rootless Container, Image-Scanning und minimale Capabilities sind die drei wichtigsten Maßnahmen.

IT-Sicherheitsberatung für Container und Server in Heidelberg, Mannheim und der Rhein-Neckar-Region. Anfragen.