Docker macht es einfach, Anwendungen zu containerisieren, aber die Standardeinstellungen sind alles andere als sicher. Container, die als Root laufen, aufgeblähte Images mit unnötigen Packages und fehlende Resource Limits stellen ernsthafte Risiken dar. In diesem praxisnahen Tutorial gehen wir jeden Schritt durch, um Ihre Docker-Container produktionsbereit und sicher zu machen.
Minimale Base Images und Multi-Stage Builds
Die erste Regel der Container-Sicherheit: Minimieren Sie die Angriffsfläche. Verwenden Sie Alpine Linux (5 MB) oder Distroless Images anstelle von vollständigen Ubuntu- oder Debian-Images. Jedes zusätzliche Package in Ihrem Image ist eine potenzielle Schwachstelle. Mit Multi-Stage Builds kompilieren Sie Ihre Anwendung in einer Builder-Stage mit allen Entwicklungstools und kopieren nur das endgültige Artefakt in ein minimales Runtime-Image.
Scannen Sie Ihre Images regelmäßig mit Tools wie Trivy, Snyk oder Docker Scout. Integrieren Sie dies in Ihre CI/CD-Pipeline, damit verwundbare Images nie in die Produktion gelangen. Pinnen Sie Ihre Base-Image-Versionen mit einem spezifischen Digest-Hash anstelle von mutablen Tags wie :latest, um Supply-Chain-Risiken zu vermeiden.
# Optimales Dockerfile mit Multi-Stage Build
# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
# Stage 2: Runtime (minimales Image)
FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
# Als Non-Root-Benutzer ausführen (uid 1000)
USER 1000
EXPOSE 3000
CMD ["dist/server.js"]Non-Root-Benutzer, Read-Only-Dateisysteme und Resource Limits
Container laufen standardmäßig als Root — ein enormes Sicherheitsrisiko. Wenn ein Angreifer aus dem Container ausbricht, hat er Root-Zugriff auf den Host. Verwenden Sie immer die USER-Direktive in Ihrem Dockerfile, um als Non-Root-Benutzer zu laufen. Erstellen Sie einen dedizierten Benutzer oder verwenden Sie den eingebauten node-, www-data- oder nobody-Benutzer.
Führen Sie Container mit einem Read-Only-Root-Dateisystem über --read-only aus. Mounten Sie nur bestimmte Verzeichnisse als beschreibbar, wo Ihre Anwendung temporäre Dateien schreiben muss. Setzen Sie auch immer Resource Limits mit --memory und --cpus, um zu verhindern, dass ein kompromittierter Container das gesamte System erschöpft. Entfernen Sie alle Linux-Capabilities mit --cap-drop ALL und fügen Sie nur die strikt notwendigen wieder hinzu.
- Verwenden Sie Distroless oder Alpine als Base Image — vermeiden Sie aufgeblähte Images
- Laufen Sie immer als Non-Root mit der USER-Direktive
- Aktivieren Sie Read-Only-Root-Dateisystem mit --read-only Flag
- Setzen Sie Memory- und CPU-Limits für jeden Container
- Entfernen Sie alle Capabilities mit --cap-drop ALL und fügen Sie nur notwendige hinzu
- Scannen Sie Images mit Trivy oder Snyk in Ihrer CI/CD-Pipeline
Runtime-Sicherheit und Secrets in Docker
Build-Time-Sicherheit ist nur die halbe Geschichte. Verwenden Sie Dockers Seccomp-Profil, um Syscalls einzuschränken, und AppArmor oder SELinux für Mandatory Access Control. Aktivieren Sie auch --no-new-privileges, um zu verhindern, dass Prozesse im Container ihre Privilegien nach dem Start erhöhen.
Speichern Sie niemals Secrets in Docker-Images oder Umgebungsvariablen. Verwenden Sie Docker Secrets (in Swarm) oder externe Secret Manager wie HashiCorp Vault. Für die Entwicklung können Sie Docker Compose mit einer .env-Datei verwenden, die in .gitignore steht. In der Produktion mounten Sie Secrets als Dateien in einem tmpfs-Volume mit restriktiven Berechtigungen (0400). Vergessen Sie nicht, Ihren Docker-Daemon selbst abzusichern: Aktivieren Sie TLS, beschränken Sie den API-Zugriff und halten Sie Docker aktuell.
Profi-Tipp
Führen Sie jetzt docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image <Ihr-Image> auf Ihren Produktionsimages aus. Sie werden wahrscheinlich kritische Schwachstellen in Ihren Base Images finden. Wechseln Sie dann zu einem Distroless- oder Alpine-Base-Image, fügen Sie USER 1000 zu jedem Dockerfile hinzu, und Sie haben in weniger als einer Stunde 80% der häufigsten Container-Schwachstellen eliminiert.
Artikel teilen