Docker-Container absichern

Was dieser Artikel über Docker-Sicherheit behandelt

• Warum Container-Sicherheit wichtig ist.
• Wie Rootless-Docker das Risiko reduziert.
• Wie Capabilities, Seccomp und AppArmor helfen.
• Sichere Netzwerke und Portbindungen.
• Image-Scanning und aktuelle Basis-Images.

Einleitung: Docker-Container absichern

Docker vereinfacht den Betrieb von Anwendungen, eröffnet aber auch neue Angriffsflächen. Container, die als root laufen, mit zu vielen Capabilities oder ungeschützt im Netzwerk veröffentlicht sind, können zum Einfallstor werden. Besonders bei KI-Diensten wie Ollama, Open WebUI oder Datenbanken fliessen sensible Daten, weshalb eine solide Container-Absicherung Pflicht ist.

Dieser Artikel zeigt, wie man Docker-Container absichert, ohne den Betrieb unnötig zu erschweren.

Wichtige Begriffe

• Rootless: Docker als normaler Benutzer ohne root-Rechte ausführen.
• Capabilities: Feingranulierte Berechtigungen für Linux-Prozesse.
• Seccomp: Filter für Systemaufrufe.
• AppArmor / SELinux: Mandatory Access Control für Prozesse.
• Read-only Filesystem: Container-Dateisystem schreibgeschützt.
• No-new-privileges: Container kann keine zusätzlichen Rechte erlangen.
• Image Scanning: Überprüfung von Images auf bekannte Schwachstellen.
• Least Privilege: Nur minimale nötige Rechte vergeben.

Nicht als root laufen lassen

Viele Images starten standardmässig als root. Besser ist ein eigener Benutzer:

FROM python:3.11-slim
RUN useradd -m appuser
USER appuser

In Compose:

services:
  app:
    image: mein-image
    user: "1000:1000"

Rootless Docker

Rootless Docker führt den Docker-Daemon im Benutzerkontext aus. Ein Container-Breakout hat dann nur Rechte des Benutzers, nicht von root.

dockerd-rootless-setuptool.sh install

Nachteile:

• Nicht alle Features verfügbar.
• Netzwerk- und Speicherfunktionen teils eingeschränkt.
• GPU-Passthrough braucht zusätzliche Konfiguration.

Capabilities einschränken

Standardmässig hat Docker einige Capabilities. Oft sind diese nicht nötig:

services:
  app:
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETGID
      - SETUID

Read-only Filesystem

Container, die nicht schreiben müssen, sollten schreibgeschützt sein:

services:
  app:
    read_only: true
    tmpfs:
      - /tmp

Für Ollama oder Datenbanken ist read_only nicht sinnvoll, da diese in Volumes schreiben.

No-new-privileges

Verhindert, dass ein Prozess durch setuid mehr Rechte erhält:

services:
  app:
    security_opt:
      - no-new-privileges:true

Netzwerke einschränken

• Ports nur an 127.0.0.1 binden.
• Container in separate Netzwerke legen.
• Keine --network host ohne triftigen Grund.
• Externe Dienste über Reverse Proxy erreichbar machen.

Beispiel:

services:
  ollama:
    ports:
      - "127.0.0.1:11434:11434"

Secrets richtig nutzen

Secrets niemals in Images oder Compose-Dateien im Klartext ablegen:

services:
  app:
    env_file:
      - .env

Besser sind Docker Secrets, HashiCorp Vault, Infisical oder verschlüsselte .env-Dateien mit dotenvx oder SOPS.

Image-Scanning

Images sollten regelmässig auf Schwachstellen geprüft werden:

docker scout cves mein-image:latest

Oder mit Trivy:

trivy image mein-image:latest

Aktuelle und kleine Basis-Images

• Offizielle Images aus vertrauenswürdigen Quellen nutzen.
• Tags mit fester Version statt latest verwenden.
• Schlankere Varianten wie alpine, slim oder distroless wählen.
• Regelmässig Updates einspielen.

Protokollierung und Überwachung

• Container-Logs zentral sammeln.
• Audit-Regeln aktivieren.
• Überwachung auf ungewöhnliche Netzwerkaktivität.
• Container-Runtime-Security-Tools wie Falco prüfen.

Beispiel für einen sichereren Compose-Service

services:
  app:
    image: mein-image:1.2.3
    user: "1000:1000"
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    networks:
      - backend
    env_file:
      - .env
    restart: unless-stopped

networks:
  backend:

Typische Stolpersteine

• Container läuft als root: Unnötiges Risiko.
• Alle Capabilities erlaubt: Überprüfen, was wirklich gebraucht wird.
• Ports an 0.0.0.0: Öffentliche Erreichbarkeit ohne Absicherung.
• Secrets in Images: Werden bei Push in Registries preisgegeben.
• Veraltete Images: Enthalten bekannte Sicherheitslücken.
• Keine Log-Überwachung: Angriffe bleiben unentdeckt.
• Rootless vermeintlich zu kompliziert: Für sensible Umgebungen lohnenswert.

Weiterführende Links und Infos

• BotServ.de Docker Netzwerk
• BotServ.de Docker Reverse Proxy
• BotServ.de Docker Volumes
• BotServ.de Ollama Sicherheit
• BotServ.de Secret-Management

FAQ: Docker-Sicherheit

Sollte ich Rootless Docker nutzen? Für sehr sensible Umgebungen ja, aber nicht jede GPU-Workload funktioniert sofort.

Ist root im Container gefährlich? Ja, weil ein Container-Breakout dann root-Rechte auf dem Host bedeuten kann.

Wie scanne ich Docker-Images? Mit Docker Scout, Trivy oder Snyk.

Sollte ich latest vermeiden? Ja, fixe Versionen erhöhen Reproduzierbarkeit und Sicherheit.

Was ist besser: Capabilities oder rootless? Beides ergänzt sich. Rootless reduziert Daemon-Risiko, Capabilities einschränken Prozessrechte.

Quellen und weiterführende Literatur

• Docker Security: https://docs.docker.com/engine/security/
• Docker Bench Security: https://github.com/docker/docker-bench-security
• Trivy: https://trivy.dev/
• Rootless Docker: https://docs.docker.com/engine/security/rootless/

Zusammenfassung: Docker-Container absichern

Docker-Sicherheit beginnt bei kleinen Massnahmen: Container nicht als root laufen lassen, Capabilities einschränken, read-only Filesystem nutzen, Netzwerkports nur an 127.0.0.1 binden und Secrets auslagern. Regelmässiges Image-Scanning und aktuelle Basis-Images reduzieren Angriffsflächen. Wer Rootless Docker, no-new-privileges und separate Netzwerke kombiniert, bekommt eine deutlich robustere Container-Infrastruktur für KI-Dienste. Sicherheit ist kein Einmalprojekt, sondern ein fortlaufender Prozess aus Absicherung, Monitoring und regelmässigen Updates.