Docker-Sicherheit ist oft ein nachträglicher Gedanke, bis es zu einem Verstoß kommt. Im Jahr 2026 gehören die Ausführung von Containern als Root, die Verwendung nicht gescannter Bilder und die Offenlegung unnötiger Ports zu den häufigsten Sicherheitsfehlern in der Produktion. In diesem Leitfaden wird die Härtung der Docker-Sicherheit von Dockerfile bis zur Laufzeit behandelt.
📋 Table of Contents
Die größten Docker-Sicherheitsrisiken
- Container als Root-Benutzer ausführen
- Verwendung veralteter Basisbilder mit bekannten CVEs
- Geheimnisse in Bildern fest kodieren oder Dateien erstellen
- Den Docker-Daemon-Socket verfügbar machen
- Neuestes Tag verwenden (nicht angeheftete Versionen)
- Übermäßig freizügige Fähigkeiten
- Keine Ressourcenlimits (CPU/Speicher)
Sichere Dockerfile-Muster
# SECURE: Multi-stage, minimal base, non-root user
FROM python:3.12-slim AS builder
# Pin all package versions
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt && pip install pip-audit && pip-audit # fail build if known CVEs
FROM gcr.io/distroless/python3-debian12 # minimal, no shell
# OR use: python:3.12-slim (if you need shell for debugging)
# Never run as root
RUN groupadd -r appgroup && useradd -r -g appgroup -u 1001 appuser
WORKDIR /app
# Copy only what's needed
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY --chown=appuser:appgroup src/ .
# Declare what's sensitive (documentation, not actual protection)
# NEVER put actual secrets here
ENV APP_ENV=production
USER appuser # non-root!
# Make filesystem read-only (app should write to /tmp or mounted volumes)
VOLUME ["/tmp", "/var/run"]
EXPOSE 8000
# Health check
HEALTHCHECK --interval=30s --timeout=10s --retries=3 CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
Geheimnismanagement
# WRONG: secrets in compose file
services:
app:
environment:
DB_PASSWORD: mysecretpassword # visible in 'docker inspect'!
# CORRECT: use Docker secrets or env file
services:
app:
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt # .gitignore this!
# OR for Docker Swarm:
# external: true
# Never embed secrets in images!
# Bad: COPY .env /app/.env
# Bad: ENV DB_PASSWORD=secret
# Good: pass at runtime
docker run -e DB_PASSWORD="$(cat ~/.secrets/db_password)" myapp
# Better: use a secret manager
# AWS Secrets Manager, HashiCorp Vault, Azure Key Vault
# Check for leaked secrets
docker history --no-trunc myimage:latest | grep -i secret
docker inspect myimage | grep -i password
Laufzeitsicherheit
# compose.yaml — secure runtime config
services:
app:
image: myapp:1.2.3 # pin exact version!
read_only: true # read-only root filesystem
tmpfs:
- /tmp:size=100m,noexec # writable temp, no execution
security_opt:
- no-new-privileges:true # prevent privilege escalation
cap_drop:
- ALL # drop all capabilities
cap_add:
- NET_BIND_SERVICE # add only what's needed
user: "1001:1001" # non-root UID:GID
ulimits:
nofile:
soft: 1024
hard: 2048
mem_limit: 512m
cpus: '1.0'
networks:
- backend # isolated network
# Never expose Docker socket:
# volumes:
# - /var/run/docker.sock:/var/run/docker.sock # DANGEROUS!
networks:
backend:
driver: bridge
internal: true # no external access
Bildscannen
# Trivy — fast, free vulnerability scanner
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:latest image --severity HIGH,CRITICAL myapp:latest
# Docker Scout (built into Docker Desktop 2024+)
docker scout cves myapp:latest
docker scout recommendations myapp:latest
# Snyk
snyk container test myapp:latest
# In CI/CD pipeline
name: Security Scan
on: [push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
format: sarif
exit-code: '1' # fail on HIGH/CRITICAL
severity: 'HIGH,CRITICAL'
Netzwerksicherheit
# Use user-defined networks (not default bridge)
docker network create --driver bridge --subnet 172.20.0.0/16 appnet
# Verify containers can't reach each other on default network
# By default, containers on same network CAN reach each other
# Use 'internal: true' to prevent external access
# Limit exposed ports
# WRONG: 0.0.0.0:5432:5432 (exposed to all interfaces)
# CORRECT: 127.0.0.1:5432:5432 (localhost only)
# Or don't expose at all — access via internal network name
Docker-Sicherheitscheckliste
- Nicht-Root-Benutzer in Dockerfile
- Angepinnte Bildversionen (Nr.: Neueste)
- Mehrstufiger Aufbau (minimales endgültiges Bild)
- Keine Geheimnisse in Bildern oder in der Kompositionsumgebung
- Schreibgeschütztes Root-Dateisystem
- Löschen Sie alle Funktionen und fügen Sie nur die erforderlichen Funktionen hinzu
- Ressourcenlimits festgelegt (Speicher/CPU)
- Das Bild wurde vor der Bereitstellung mit Trivy oder Snyk gescannt
- Docker-Socket nicht in Containern montiert
- Isolierte Netzwerke pro Serviceebene
- Geheimnisse über Docker-Geheimnisse oder Vault (niemals env vars)
Docker-Sicherheit im Jahr 2026: Das Bedrohungsmodell ist real – Container-Escapes, geheime Lecks und Rechteausweitung sind dokumentierte Angriffsvektoren. Implementieren Sie Nicht-Root-Benutzer, schreibgeschützte Dateisysteme, Bildscans in CI und eine ordnungsgemäße Geheimnisverwaltung, bevor Sie mit der Produktion beginnen. Der Aufwand ist im Vergleich zum Risiko eines Verstoßes minimal.
🔗 Share this article
✍️ Leave a Comment