Containersicherheit: Härtung von Images und Laufzeitschutz

Container bündeln Anwendungscode und seine Abhängigkeiten in isolierten Einheiten, die sich den Kernel des Hostbetriebssystems teilen – anders als VMs, die ein vollständiges Gastbetriebssystem enthalten. Diese gemeinsame Nutzung macht Container schlank und schnell, führt aber zu einem anderen Sicherheitsmodell: Eine Schwachstelle zum Ausbruch aus einem Container könnte einem Angreifer ermöglichen, den Container zu verlassen und direkt auf den Hostkernel zuzugreifen, wodurch alle anderen Container betroffen wären. Containersicherheit konzentriert sich auf drei Ebenen: das Image (was darin enthalten ist), die Laufzeit (was der Container während des Betriebs tun kann) und die Orchestrierungsplattform (wie Container verwaltet werden).

Jedes in einem Container-Image installierte Paket stellt eine potenzielle Angriffsfläche dar. Das Prinzip der minimalen Basis-Images besteht darin, mit einer möglichst kleinen Grundlage zu beginnen: Alpine Linux (5 MB, minimale Anzahl an Paketen), Distroless-Images (Images von Google, die nur die Laufzeitumgebung und die Anwendung enthalten, aber keine Shell und keinen Paketmanager) oder scratch (vollständig leer, für statisch kompilierte Binärdateien). Bei einem Container ohne Shell kann ein Angreifer, der Codeausführung erreicht, nicht ohne Weiteres wget, curl oder andere Tools ausführen, um seinen Angriff auszuweiten – ein Prinzip, das als Abwehr durch minimale Angriffsfläche bezeichnet wird.

Standardmäßig werden Docker-Container als root (UID 0) ausgeführt. Wenn ein Angreifer eine Schwachstelle in der containerisierten Anwendung ausnutzt, erhält er Root-Rechte innerhalb des Containers. Wenn der Container ein Volume gemeinsam nutzt oder Einbindungen des Hosts besitzt, kann root innerhalb des Containers root auf dem Host entsprechen. Die Lösung ist einfach: Erstellen Sie einen dedizierten Benutzer im Dockerfile und wechseln Sie mit der Direktive USER vor dem abschließenden CMD/ENTRYPOINT zu diesem Benutzer. Viele Tools zur Überprüfung der Containersicherheit melden jedes Image ohne Nicht-Root-Benutzer als Befund.

Unveränderliche Container sind Container, deren Dateisystem zur Laufzeit nicht verändert werden kann. Die Aktivierung von --read-only in Docker (oder readOnlyRootFilesystem: true in Kubernetes) verhindert, dass Angreifer Schadsoftware auf die Festplatte schreiben, Konfigurationsdateien ändern oder Tools in einem laufenden Container installieren. Anwendungen, die tatsächlich Daten schreiben müssen (Protokolle, temporäre Dateien), können bestimmte tmpfs-Volumes für flüchtige Schreibvorgänge einbinden. Unveränderliche Container setzen das Prinzip durch, dass der Laufzeitstatus ausschließlich aus dem Image und der Konfiguration stammen sollte und nicht aus Änderungen innerhalb des Containers, die Ihre CI/CD-Sicherheitspipeline umgehen.

Tools zum Scannen von Container-Images analysieren die in einem Docker-Image installierten Pakete anhand von Schwachstellendatenbanken (NVD, CVE) und melden bekannte CVEs. Zu den führenden Scannern gehören Trivy (Aqua Security, schnell und kostenlos), Grype (Anchore), Snyk Container und das AWS ECR image scanning. Das Scannen sollte in die CI/CD-Pipeline integriert werden, damit jedes Image mit kritischen oder hohen CVEs die Pipeline nicht erfolgreich durchläuft, bevor es in eine Registry übertragen wird. Die Scanner sollten außerdem nach Geheimnissen (API-Schlüsseln, Passwörtern) suchen, die versehentlich in Image-Layern eingebettet wurden.

Ein häufiger und gefährlicher Fehler besteht darin, Geheimnisse (API-Schlüssel, Datenbankpasswörter, TLS-Zertifikate) in Docker-Images einzubetten – entweder als in das Image übernommene Umgebungsvariablen oder in Dateien, die über COPY hinzugefügt wurden. Diese Geheimnisse sind für alle sichtbar, die Zugriff auf das Image haben, etwa über docker history oder durch das Extrahieren der Image-Layer. Selbst wenn eine nachfolgende Layer die Datei löscht, bleibt sie in der Image-Historie erhalten. Geheimnisse sollten zur Laufzeit über Umgebungsvariablen aus einem Secrets-Manager, über Docker secrets oder über als Volumes eingebundene Kubernetes Secrets injiziert werden.

Tools für die Laufzeitsicherheit überwachen das Verhalten von Containern während ihrer Ausführung und melden oder blockieren anomale Aktivitäten. Falco (ein CNCF-Projekt bindet sich über eBPF oder Kernel-Module in den Linux-Kernel ein, fängt Systemaufrufe ab und vergleicht sie mit Regeln. So kann beispielsweise eine Regel einen Alarm auslösen, wenn ein Container eine Shell startet (execve('/bin/sh')), eine Netzwerkverbindung an einem unerwarteten Port öffnet oder /etc/shadow liest. Solche Verhaltensindikatoren weisen häufig auf einen aktiven Angriff hin, selbst wenn keine bekannte CVE ausgenutzt wurde. Sysdig Secure und Aqua Security bieten kommerzielle Plattformen für den Laufzeitschutz.

Docker verwirft standardmäßig viele Linux-Capabilities, behält aber weiterhin mehr bei, als die meisten Anwendungen benötigen. Capabilities teilen Root-Berechtigungen in einzelne Einheiten auf (z. B. CAP_NET_ADMIN, CAP_SYS_ADMIN). Als Best Practice gilt, alle Capabilities zu entfernen und nur die benötigten mit --cap-drop=ALL --cap-add=NET_BIND_SERVICE wieder hinzuzufügen. Seccomp (Secure Computing Mode)-Profile legen fest, welche Systemaufrufe ein Container ausführen darf – Docker enthält ein standardmäßiges Seccomp-Profil, das etwa 44 gefährliche Systemaufrufe blockiert. Benutzerdefinierte Seccomp-Profile für bestimmte Anwendungen können dies weiter einschränken, indem sie alle Systemaufrufe blockieren, die die Anwendung nicht auf legitime Weise verwendet.

Container-Registries (Docker Hub, AWS ECR, Google Artifact Registry) speichern und verteilen Images. Zur Absicherung der Registry gehören: das Aktivieren des Schwachstellen-Scannens beim Push, die Beschränkung des Push-Zugriffs auf CI/CD-Servicekonten, das Aktivieren der Image-Signierung mit Sigstore/Cosign oder Docker Content Trust (Notary), damit Laufzeitumgebungen nur kryptografisch signierte Images aus vertrauenswürdigen Quellen abrufen, sowie das Konfigurieren der Unveränderlichkeit von Images, damit Tags nicht überschrieben werden können. Dadurch werden Tag-Manipulationsangriffe verhindert, bei denen ein Angreifer einen vertrauenswürdigen :latest-Tag durch ein schädliches Image ersetzt.

Angreifer, denen eine Codeausführung innerhalb eines Containers gelingt, können versuchen, einen Container-Escape durchzuführen, um auf den Host zuzugreifen. Zu den üblichen Techniken gehören das Ausnutzen verwundbarer privilegierter Container (--privileged gewährt nahezu uneingeschränkten Zugriff auf den Host), der Missbrauch offengelegter Docker-Sockets (/var/run/docker.sock gewährt einem in einen Container eingebundenen Container vollständigen Zugriff auf die Docker-API, einschließlich des Erstellens privilegierter Container) sowie das Ausnutzen von Kernel-Schwachstellen über unzureichend abgesicherte Capabilities. Schutzmaßnahmen: Verwenden Sie den privilegierten Modus niemals, sofern er nicht unbedingt erforderlich ist, binden Sie den Docker-Socket niemals in Anwendungscontainer ein, halten Sie den Host-Kernel aktuell und verwenden Sie gVisor oder Kata Containers für Workloads, die eine starke Isolation erfordern.

Der Center for Internet Security (CIS) Docker Benchmark enthält detaillierte Richtlinien zur Sicherheitskonfiguration von Docker-Hosts und -Containern. Er deckt die Daemon-Konfiguration, die Image-Hygiene, Einstellungen für die Container-Laufzeit und Netzwerksteuerungen ab. Tools wie Docker Bench for Security automatisieren die Prüfung der Compliance anhand des CIS-Benchmarks und erstellen einen bewerteten Bericht mit bestandenen und nicht bestandenen Prüfpunkten. Wenn Sie diesen Benchmark regelmäßig ausführen und in die CI/CD-Pipeline integrieren, wird eine Abweichung von der Sicherheitskonfiguration schnell erkannt. Kandidaten für Security+ sollten wissen, dass CIS Benchmarks im Prüfungskontext eine zentrale Referenz für die Härtung von Betriebssystemen und Plattformen sind.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: minimale Basis-Images und Nicht-Root-Benutzer reduzieren die Angriffsfläche und die Berechtigungsstufe containerisierter Workloads; Laufzeitschutz-Tools wie Falco erkennen anomale Syscall-Muster, die auf aktive Angriffe innerhalb von Containern hinweisen; und verwenden Sie niemals privilegierte Container und binden Sie den Docker-Socket nicht in Anwendungscontainer ein, da diese Konfigurationen einen Container-Escape ermöglichen. Als Nächstes behandeln wir die Kubernetes-Sicherheit einschließlich RBAC, Netzwerkpolicies und Pod-Sicherheitsstandards.