Container Security

• Nicht als Root laufen lassen! USER 1001 im Dockerfile. Wenn du als Root im Container bist, bist du (oft) auch Root auf dem Host, wenn du ausbrichst.
• Minimal Base Images: Nutze alpine oder distroless. Was nicht da ist (kein curl, keine Shell), kann der Hacker nicht nutzen ("Living off the land").
• Read-Only Filesystem: Verbiete dem Container, Dateien zu schreiben, wenn er es nicht muss.

Praxisroutine

In der Praxis lernst du Container Security, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Image Scanning (Trivy / Clair)

Scanner zerlegen das Image Layer für Layer. Sie vergleichen installierte Pakete mit Datenbanken (CVEs). "Hilfe, dein Image nutzt openssl 1.0 -> High Severity CVE!" Das passiert vor dem Deployment (in der CI/CD Pipeline).

2. Admission Controllers (OPA Gatekeeper)

Türsteher für Kubernetes. "Du willst diesen Container starten? Er läuft als Root? -> Zugriff verweigert!" Policy as Code direkt im Cluster.

Technische Einordnung im System

Technisch ist Container Security nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. Linux Capabilities (Dropping)

Auch ein Prozess, der nicht "root" ist, kann verheerenden Schaden anrichten. Der Linux-Kernel teilt Superuser-Mächte in feingranulare Capabilities auf. Ein Default-Docker-Container startet mit einem Standard-Set, das CAP_CHOWN (Darf er File-Owner ändern?) oder CAP_DAC_OVERRIDE erlaubt. Eines der stärksten Security-Prinzipien ist es, alle Capabilities zu droppen (--cap-drop=ALL) und nur jene, die wirklich gebraucht werden (z. B. CAP_NET_BIND_SERVICE, um einen Server auf Port 80 zu starten), wieder hinzuzugeben. Damit wird der Blast-Radius beim Container Escape radikal minimiert.

2. Seccomp-BPF & AppArmor

Wie verhindert man, dass ein Container-Prozess Systemaufrufe (Syscalls) startet, mit denen er den Kernel exploitieren könnte? Mit Seccomp (Secure Computing Mode). Durch Injection eines BPF-Profils verbietet man hunderte von ungenutzten Syscalls (wie ptrace zum RAM-Lesen anderer Prozesse). Versucht die Malware im Container den Aufruf, crasht der Container durch Kernel-Intervention (SIGKILL). Systeme wie AppArmor oder SELinux legen das als Mandatory Access Control (MAC) für Dateisysteme aus: "Dieser NGINX-Container darf streng nur /usr/share/nginx/html/ lesen und absolut keinen Write auf /etc/ machen, selbst wenn die Linux Discretionary Permissions es erlauben würden."

3. eBPF Runtime Threat Security

Werden statische Scanner (Trivy/Clair) überlistet (z.B. Zero-Day-Exploiting im Memory), greift die Runtime Security Cloud Native Ära an (Tools wie Falco oder Tetragon). Durch eBPF hängen sich Security-Dämonen direkt in den Kernel Space und überwachen System-Aufrufe live: Startet plötzlich ein unschuldiger NGINX-Prozess via execve eine bash Binärdatei? Öffnet der Frontend-Pod (der mit dem Internet redet) eine TCP-Verbindung direkt in den versteckten Payment-Pod? Die eBPF Rule-Engine schlägt innerhalb von Mikrosekunden Alarm oder schlachtet den manipulierten Container.