Kubernetes-Laufzeitsicherheit: Über das Image-Scanning hinaus

Das Scannen Ihrer Docker-Images vor dem Deployment ist notwendig, aber unzureichend. Kritische Kubernetes-CVEs in 2024–2025 zeigen, dass die gefährlichsten Angriffe zur Laufzeit stattfinden, wenn Container ausgeführt werden. So sichern Sie Ihren Cluster über das Image-Scanning hinaus.

Aktuelle CVEs: Warum die Laufzeit zählt

CVE-2024-9042: Befehlsausführung auf Windows-Knoten

CVSS-Score 9.8. Diese Schwachstelle ermöglicht es einem Angreifer, beliebige Befehle auf Windows-Knoten eines Kubernetes-Clusters über die Logging-API auszuführen. Ein einfacher nicht authentifizierter API-Aufruf reicht aus, um Code als SYSTEM auf dem Knoten auszuführen. Betrifft Kubernetes 1.27–1.30 mit Windows-Knoten.

CVE-2025-1767: Ausbruch über gitRepo-Volumes

gitRepo-Volumes ermöglichen es einem Pod, beim Start ein Git-Repository zu klonen. Diese CVE offenbart, dass der Repository-Inhalt manipuliert werden kann, um über symbolische Links auf Dateien des Host-Knotens zuzugreifen. Ein Angreifer, der ein Git-Repository kontrolliert, kann so aus dem Container ausbrechen und auf das Dateisystem des Knotens zugreifen.

Beide CVEs haben eine Gemeinsamkeit: Kein Image-Scan erkennt sie. Es handelt sich um Schwachstellen im Orchestrator selbst, die nur zur Laufzeit ausnutzbar sind.

Build-Time vs. Laufzeit: zwei verschiedene Schlachtfelder

• Build-Time (Image-Scanning): erkennt verwundbare Pakete in Docker-Images. Tools: Trivy, Grype, Snyk Container. Unverzichtbar, aber unzureichend

• Laufzeit: überwacht, was in laufenden Containern passiert. Erkennt anomales Verhalten: Shell-Ausführung in einem Container, unerwarteter Netzwerkzugriff, Änderung sensibler Dateien, Privilegien-Eskalation

Build-Time-Sicherheit schützt Sie vor bekannten Schwachstellen in Ihren Abhängigkeiten. Laufzeitsicherheit schützt Sie vor unbekannten Schwachstellen (Zero-Days) und bösartigem Verhalten, das schwache Konfigurationen ausnutzt.

eBPF: die Kernel-Observability-Revolution

eBPF (extended Berkeley Packet Filter) ermöglicht es, Code im Linux-Kernel auszuführen, ohne ihn zu modifizieren. Für die Kubernetes-Sicherheit bedeutet dies Observability ohne signifikanten Overhead: Systemaufruf-Tracing, Netzwerk-Monitoring, Erkennung anomalen Verhaltens – alles mit weniger als 1 % Performance-Einbußen.

eBPF-basierte Tools (Cilium Tetragon, Falco mit eBPF-Treiber) können in Echtzeit Aktionen erkennen wie: /bin/bash-Ausführung in einem Produktionscontainer, ausgehende Verbindung zu einer unbekannten IP, Lesen von /etc/shadow, Mounten von hostPath-Volumes.

Falco: der De-facto-Standard

Falco (CNCF Graduated Project) ist die am weitesten verbreitete Laufzeit-Erkennungsengine. Sie überwacht Systemaufrufe und wendet Erkennungsregeln an:

• Interaktive Shell in einem Produktionscontainer

• Unerwarteter Prozess (Cryptominer, Reverse Shell)

• Systemdatei-Änderung

• Verdächtige Netzwerkverbindungen

• Zugriff auf Kubernetes-Secrets

Falco generiert Alerts, blockiert aber nicht. Für eine automatisierte Reaktion muss es mit einem Reaktionstool oder einem Agenten wie ThreatClaw integriert werden.

Network Policies und Pod Security Standards

Network Policies

Standardmäßig können alle Kubernetes-Pods miteinander kommunizieren. Network Policies ermöglichen die Einschränkung des Netzwerkverkehrs zwischen Pods, Namespaces und der Außenwelt. Es ist das Äquivalent einer mikrosegmentierten Firewall. Laut einer Datadog-Studie verwenden jedoch weniger als 30 % der Produktionscluster Network Policies.

Pod Security Standards

Pod Security Standards (Privileged, Baseline, Restricted) definieren drei Sicherheitsstufen für Pods. Die Stufe Restricted verbietet privilegierte Container, erzwingt ein Read-Only-Dateisystem, blockiert Privilegien-Eskalation und verlangt einen Non-Root-Benutzer.

ThreatClaw: Trivy + Grype + Laufzeit

ThreatClaw kombiniert Build-Time- und Laufzeitsicherheit in seinen Kubernetes-Skills:

• Trivy: Scannen von Images, Kubernetes-Konfigurationen (IaC), Lizenzen und Secrets

• Grype: Schwachstellen-Scanning mit SBOM-Matching für ergänzende Abdeckung zu Trivy

• Konfigurationsaudit: Überprüfung von Network Policies, Pod Security Standards, RBAC, Service Accounts

• Laufzeit-Korrelation: Integration von Falco/Tetragon-Alerts mit CTI-Kontext für angereicherte Erkennung

FAQ

Trivy oder Grype: Welches Tool wählen?

Beide sind hervorragend und Open Source. Trivy (Aqua Security) bietet breitere Abdeckung (Images, IaC, SBOM, Secrets). Grype (Anchore) ist beim reinen Schwachstellen-Scanning schneller und hat ein granulareres Paket-Matching. Idealerweise nutzen Sie beide komplementär, was ThreatClaw nativ tut.

Mein Cluster ist klein. Brauche ich Laufzeitsicherheit?

Ja. Die Clustergröße ist nicht das Kriterium. Ein kleiner, im Internet exponierter Cluster mit einem kompromittierten Container kann als Eintrittspunkt in Ihr internes Netzwerk dienen, Kryptowährung schürfen oder an einem Botnet teilnehmen. Laufzeitsicherheit ist eine minimale Investition mit hohem ROI.

Wird eBPF auf allen Clustern unterstützt?

eBPF erfordert Linux-Kernel 4.14+ (idealerweise 5.x+). Verwaltete Kubernetes-Distributionen (EKS, GKE, AKS) unterstützen alle eBPF. Für On-Premise-Cluster prüfen Sie die Kernel-Version. Windows-Knoten unterstützen kein eBPF.

Wie integriert sich ThreatClaw in meine CI/CD-Pipeline?

ThreatClaw kann in Ihre CI/CD-Pipeline für Build-Time-Scanning (Trivy/Grype) integriert werden und die Laufzeit nach dem Deployment überwachen. Der Agent korreliert beides: Eine im Build-Time erkannte Schwachstelle, die zur Laufzeit ausgenutzt wird, löst einen Alert mit höchster Priorität aus. Sehen Sie sich unsere Angebote für Details an.