Docker-Container richtig absichern — ein Praxisbericht

Nach mehreren Vorfällen in meinem Homelab — darunter ein Container, der durch eine schlecht konfigurierte Volume-Mount das gesamte Host-Dateisystem lesen konnte — habe ich meine Docker-Setups komplett überarbeitet. Dieser Beitrag fasst zusammen, was wirklich geholfen hat und was sich im Nachhinein als reines Placebo herausgestellt hat.

1. Read-only Filesysteme

Der einfachste und wirksamste Schritt: das Root-Dateisystem des Containers schreibgeschützt mounten. Wer keine Persistenz braucht, sollte das immer tun.

services:
  app:
    image: nginx:alpine
    read_only: true
    tmpfs:
      - /tmp
      - /var/cache/nginx
      - /var/run

Für Anwendungen, die zwingend schreiben müssen, empfiehlt sich ein dediziertes Volume mit rw, alles andere bleibt ro.

2. Capabilities reduzieren

Standardmäßig bekommt jeder Container ein ganzes Bündel an Linux-Capabilities, die er in 99% der Fälle nie braucht. Mit cap_drop: [ALL] wirft man alles weg und gibt nur das Nötigste zurück.

cap_drop:
  - ALL
cap_add:
  - NET_BIND_SERVICE

3. User-Namespaces

Der userns-remap-Modus sorgt dafür, dass root im Container nicht root auf dem Host ist. Ein oft unterschätzter Schutzmechanismus, der aber voraussetzt, dass alle Volumes korrekt zugeordnet sind.

4. Was nicht funktioniert hat

AppArmor-Profile klingen in der Theorie großartig, aber die Standardprofile von Docker sind so löchrig, dass sie kaum etwas bringen. Wer es ernst meint, muss eigene Profile schreiben — und das ist Aufwand, der sich für ein Homelab selten lohnt.

Ähnlich verhält es sich mit seccomp: Die Default-Konfiguration blockiert nur die exotischsten Syscalls. Wer wirklich absichern will, muss hier ebenfalls Hand anlegen.

Fazit

Read-only, Capabilities wegwerfen, User-Namespaces aktivieren — diese drei Maßnahmen bringen 90% des Sicherheitsgewinns bei minimalem Aufwand. Alles darüber hinaus ist eine Frage der Risikobewertung.