▸ saaro:~/blog ▊ Notizen & Artikel
← zurück

📷 "P1170336" by hiSaifi is licensed under CC BY-NC-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/2.0/.

Kubernetes-Sicherheit 2026: Warum der Ingress-NGINX-Ruhestand die dringendste Bedrohung ist

04. August 2026 · 4 min · Martin Jochum #Kubernetes#Sicherheit#DevOps#Ingress#Gateway API#Cloud Native

Der März 2026 markierte eine Zäsur für die Kubernetes-Community: Das Ingress-NGINX-Projekt, seit Jahren eines der am weitesten verbreiteten Ingress-Controller weltweit, wurde offiziell eingestellt. Rund die Hälfte aller Cloud-Native-Umgebungen war auf dieses eine Tool angewiesen – gewartet von nur ein bis zwei ehrenamtlichen Entwicklern. Der Ruhestand ist kein abstrakter Warnhinweis mehr, sondern eine akute Sicherheitslage. Gleichzeitig zeigt sich, wie die Kubernetes-Sicherheitslandschaft 2026 insgesamt auf eine neue Grundlage gestellt wird.

Ingress-NGINX: Warum der Ruhestand unausweichlich war

Die Geschichte des Ingress-NGINX-Controllers ist eine der Schattenseiten von Open-Source-Erfolg. Das Projekt entstand als Referenzimplementierung der Ingress-API und wurde aufgrund seiner Flexibilität und Plattformunabhängigkeit enorm populär. Laut Datadog-Forschung setzten rund 50 Prozent aller Cloud-Native-Umgebungen darauf. Doch der Wartungsaufwand wuchs unverhältnismäßig: Was einst als nützliche Flexibilität galt – etwa die Möglichkeit, beliebige NGINX-Konfigurationen über Annotationen einzubetten – entwickelte sich zu einer schweren Sicherheitslast.

Bereits im März 2025 offenbarten die IngressNightmare-Sicherheitslücken (CVE-2025-1974, CVSS 9.8) die Verwundbarkeit des Projekts. Ein nicht authentifizierter Angreifer im Pod-Netzwerk konnte vollständige Codeausführung auf dem Controller erzwingen und damit potenziell den gesamten Cluster kompromittieren. Das Security Response Committee und SIG Network zogen daraufhin die Konsequenzen: Im November 2025 wurde der Ruhestand angekündigt, ab März 2026 gab es keinerlei Sicherheitsupdates oder Bugfixes mehr. Das Kubernetes-Steering-Committee stellte unmissverständlich klar: „Die Hälfte von euch wird betroffen sein. Ihr habt zwei Monate Zeit, euch vorzubereiten."

Die bittere Wahrheit: Bestehende Installationen arbeiten einfach weiter. Es gibt keine Fehlermeldung, keinen funktionalen Bruch – nur ein still wachsendes Sicherheitsrisiko. Neue Schwachstellen in der ungepatchten Codebasis sind bereits dokumentiert.

Gateway API als der empfohlene Nachfolger

Die offizielle Empfehlung der Kubernetes-Community lautet, auf die Gateway API zu migrieren. Diese hat sich 2026 rasant weiterentwickelt: Version 1.5 (Februar 2026) brachte zahlreiche experimentelle Features in den stabilen Status, und mit Version 1.6 (Juni 2026) sind nun auch TCPRoute und UDPRoute als Standard-Ressourcen verfügbar.

Die Gateway API löst die zentralen Probleme des klassischen Ingress-API-Stils: Sie ist rollenbasiert aufgebaut – Plattform-Teams definieren Gateways, während Anwendungs-Teams Routes konfigurieren – und unterstützt nativ L7- und nun auch L4-Routing. Wer sich für einen alternativen Ingress-Controller entscheidet, hat zudem Optionen wie NGINX Ingress Controller (das kommerziell unterstützte Pendant), Traefik, Contour oder Cilium als Netzwerkebene.

Der Migrationsaufwand ist nicht trivial – kein Nachfolger ist ein direkter Drop-in-Ersatz –, aber der Zeitpunkt ist günstig. Die Gateway API ist produktionsreif, breit unterstützt und in den letzten zwölf Monaten sprunghaft gereift.

Die fünf Sicherheitsfindings, die 2026 wirklich zählen

Der Ingress-NGINX-Ruhestand ist das spektakulärste, aber nicht das einzige Sicherheitsthema. Sicherheitsanalysen produktiver Cluster zeigen, dass sich das reale Risiko auf fünf wiederkehrende Probleme konzentriert:

  1. Ungewartete Komponenten. Ein Großteil der Angriffsfläche entsteht nicht durch Zero-Days im Kubelet, sondern durch Addons und Controller, die niemand aktiv pflegt. Strukturierte Inventarisierung und automatisierte Erkennung von End-of-Life-Versionen sind daher die erste Verteidigungslinie.

  2. Statische Kubeconfigs als neue SSH-Keys. In vielen Organisationen existieren langlebige, kaum gescope Administrator-Zugänge auf Entwicklerrechnern, in CI-Pipelines und geteilten Secrets-Vaults. Der Standard sollte kurzlebige, identitätsbasierte Zugriffe sein.

  3. Secrets im Klartext in Git. 28,65 Millionen hartcodierte Secrets landeten laut Studien allein 2025 in öffentlichen GitHub-Commits. KI-gestützte Commits beschleunigen das Problem sogar noch. Verschlüsselung mit SOPS und AGE sowie entsprechende CI-Policies sind der Stand der Technik.

  4. Ungeprüfte Änderungen. Viele Sicherheitsvorfälle beginnen nicht mit einem Angreifer, sondern mit einem manuellen kubectl-Befehl – oder einem KI-Agenten, der ohne Review auf Produktion losgelassen wird. Ein klarer Change-Review-Prozess und GitOps-verankerte Prüfungen sind daher unverzichtbar.

  5. Fehlende Runtime-Isolation. Die User-Namespaces für Pods sind in Kubernetes 1.35 standardmäßig aktiviert und bieten eine wichtige Isolationsschicht. eBPF-basierte Tools wie Falco, Tetragon oder Cilium ermöglichen Echtzeit-Überwachung auf Kernel-Ebene, ohne dass Sidecar-Proxies nötig sind.

Fazit

Der Ruhestand von Ingress-NGINX ist ein Weckruf – aber auch eine Chance. Noch nie war die Kubernetes-Sicherheitslandschaft so gut aufgestellt wie heute: Mit der Gateway API als modernem, produktionsreifem Standard, eBPF als neuer Grundlage für Runtime Security und strukturellen Verbesserungen wie User Namespaces und robusten Service-Account-Tokens. Wer jetzt die Migration angeht und gleichzeitig die grundlegenden Sicherheitsfindings adressiert, fährt sein Cluster langfristig sicherer, als er es mit Ingress-NGINX je war.

Die Prüfung ist einfach: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. Wer eine Ausgabe sieht, handelt am besten noch heute.

Quellen