Seit März 2026 wird der Ingress-Controller ingress-nginx nicht mehr gepflegt. Bestehende Installationen laufen weiter, bekommen aber keine Sicherheitsupdates mehr. Da ingress-nginx in rund der Hälfte aller Cloud-native-Umgebungen den Verkehr in den Cluster steuert, ist das kein Randthema. Wie Sie herausfinden, ob Sie betroffen sind, und welche Wege es gibt.
Was ist passiert?
Im November 2025 haben die Kubernetes SIG Network und das Security Response Committee angekündigt, ingress-nginx einzustellen. Im März 2026 war es so weit: Die Wartung wurde beendet, das Projekt ist stillgelegt. Bereits im Jänner hatten das Steering Committee und das Security Response Committee ungewöhnlich deutlich gewarnt. Wer nach dem Stichtag bei ingress-nginx bleibt, macht sich und seine Nutzer angreifbar.
Die Gründe sind wenig spektakulär. Das Projekt hatte über Jahre zu wenige Maintainer, obwohl es extrem verbreitet war. Gleichzeitig ist die Flexibilität, die ingress-nginx so beliebt gemacht hat, zur Last geworden. Über Annotations und Snippets lässt sich nahezu beliebige NGINX-Konfiguration einschleusen. Das sicher zu pflegen, war mit den vorhandenen Ressourcen nicht mehr machbar.
Zwei Klarstellungen, weil sie in Gesprächen immer wieder auftauchen. Die Ingress-API selbst wird nicht abgeschafft, eingestellt ist nur dieser eine Controller. Und der NGINX Ingress Controller von F5, dem Unternehmen hinter NGINX, ist ein eigenständiges Projekt und von der Einstellung nicht betroffen. Die Namensähnlichkeit sorgt regelmäßig für Verwirrung.
Warum das ein Sicherheitsthema ist
Der Ingress-Controller ist in vielen Clustern die Komponente, die als erste mit Anfragen aus dem Internet in Berührung kommt. Gleichzeitig hat er oft Lesezugriff auf zahlreiche Secrets im ganzen Cluster, etwa auf TLS-Zertifikate. Eine Lücke an dieser Stelle ist deshalb besonders unangenehm.
Wie unangenehm, hat der März 2025 gezeigt. Unter dem Namen IngressNightmare wurden fünf Schwachstellen in ingress-nginx veröffentlicht. Die schwerste davon, CVE-2025-1974, erhielt 9,8 von 10 möglichen Punkten. Ein Angreifer ohne Anmeldung, der das Pod-Netzwerk erreicht, konnte unter bestimmten Bedingungen Code im Kontext des Controllers ausführen und im schlimmsten Fall den gesamten Cluster übernehmen. Damals gab es zügig Patches. Bei der nächsten Lücke dieser Art wird es keine mehr geben.
Bin ich betroffen? Der 10-Sekunden-Check
Mit Administratorrechten im Cluster genügt in den meisten Fällen ein einziger Befehl:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Liefert der Befehl Pods zurück, läuft ingress-nginx. Ergänzend lohnt ein Blick auf die IngressClasses mit kubectl get ingressclass. Steht dort als Controller k8s.io/ingress-nginx, ist die Sache klar. Prüfen Sie auch Helm-Releases und mitgelieferte Komponenten von Drittprodukten, denn ingress-nginx steckt mitunter in Installationen, die niemand bewusst ausgewählt hat. Und vergessen Sie Test- und Entwicklungscluster nicht.
Drei Wege aus der Sackgasse
Abbildung: Die Optionen für die Ablöse von ingress-nginx
Weg 1: Gateway API
Die Gateway API ist der offizielle Nachfolger der Ingress-API und die langfristige Richtung von Kubernetes. Sie trennt die Verantwortlichkeiten sauber: Die GatewayClass beschreibt die Infrastruktur, das Gateway gehört dem Plattform-Team und die HTTPRoutes verwalten die Anwendungsteams selbst. Vieles, wofür man bei ingress-nginx Annotations brauchte, etwa Header-basiertes Routing, Traffic-Splitting oder Weiterleitungen, ist in der Gateway API standardisiert und damit zwischen Implementierungen übertragbar.
Implementierungen gibt es reichlich, zum Beispiel Envoy Gateway, Cilium, Istio, Traefik, Kong oder NGINX Gateway Fabric. Für den Umstieg stellt das Kubernetes-Projekt das Werkzeug ingress2gateway bereit, das bestehende Ingress-Ressourcen in Gateway-API-Objekte übersetzt. Das Ergebnis ist ein guter Startpunkt, ersetzt aber nicht den prüfenden Blick eines Menschen.
Weg 2: anderer Ingress-Controller
Wer die Ingress-Ressourcen behalten möchte, tauscht nur den Controller, etwa gegen Traefik, HAProxy Ingress oder den NGINX Ingress Controller von F5. Das ist der kleinere Schritt, weil die Anwendungsteams kaum etwas ändern müssen. Die Annotations müssen allerdings auch hier übersetzt werden, denn jeder Controller hat seine eigenen.
Weg 3: zweistufig
In der Praxis wählen viele Teams einen Mittelweg. Zuerst wird ingress-nginx zügig durch einen gepflegten Controller ersetzt, um das Sicherheitsproblem zu lösen. Neue Anwendungen werden gleich mit der Gateway API ausgerollt, bestehende folgen nach und nach. So bleibt der Druck gering, und die Teams sammeln Erfahrung mit dem neuen Modell.
Die eigentliche Arbeit steckt in den Annotations
Ein neuer Controller ist schnell installiert. Aufwendig wird es bei dem, was sich über Jahre an Konfiguration in den Ingress-Ressourcen angesammelt hat. Einen guten ersten Überblick verschafft dieser Befehl, der alle verwendeten ingress-nginx-Annotations zählt:
kubectl get ingress -A -o yaml | grep -o 'nginx.ingress.kubernetes.io/[a-z-]*' | sort | uniq -c | sort -rn
Häufige Kandidaten wie rewrite-target, ssl-redirect oder proxy-body-size lassen sich meist gut übertragen. Schwierig wird es bei Snippets, also frei eingefügter NGINX-Konfiguration in configuration-snippet oder server-snippet. Dahinter stecken oft sicherheitsrelevante Regeln, Header oder Sonderfälle, die man erst verstehen muss, bevor man sie nachbauen kann. Achten Sie außerdem auf Unterschiede im Standardverhalten, etwa beim Pfad-Matching, bei Timeouts, der maximalen Upload-Größe, Websockets oder Sticky Sessions.
Bewährt hat sich ein Parallelbetrieb. Der neue Controller bekommt eine eigene IP-Adresse oder einen eigenen Load Balancer, die Anwendungen werden einzeln über DNS umgeschwenkt. Geht etwas schief, ist der Rückweg ein DNS-Eintrag.
Checkliste für die Ablöse
Ist in allen Clustern geprüft, ob ingress-nginx läuft, auch in Test- und Entwicklungsumgebungen?
Sind alle verwendeten Annotations und Snippets erfasst?
Ist entschieden, ob Gateway API, ein anderer Ingress-Controller oder ein zweistufiger Weg gewählt wird?
Sind TLS-Zertifikate und die Anbindung an cert-manager für den neuen Controller geklärt?
Kann der neue Controller in einer Testumgebung parallel betrieben werden?
Ist ein Rückweg über DNS oder Load Balancer vorbereitet?
Sind Monitoring und Alarmierung auf den neuen Controller angepasst?
Ein Partner, der vor der Übergabe viele unbequeme Fragen stellt, ist übrigens meist ein gutes Zeichen.
Häufige Fragen
Weil er nur so lange problemlos läuft, bis die nächste Schwachstelle bekannt wird. Dann gibt es keinen Patch, und die Migration muss unter Zeitdruck passieren.
Nein. Die Ingress-API bleibt Teil von Kubernetes. Eingestellt wurde nur der Controller ingress-nginx.
Nein. Ein anderer, gepflegter Ingress-Controller löst das Sicherheitsproblem ebenfalls. Langfristig ist die Gateway API aber die Richtung, in die sich Kubernetes entwickelt.
Das hängt weniger von der Zahl der Anwendungen ab als von Zahl und Art der Annotations. Ein Cluster mit Standardkonfiguration ist schnell umgestellt, viele Snippets bedeuten mehr Analyse.
Fazit
Das Ende von ingress-nginx zeigt, wie abhängig viele Umgebungen von Open-Source-Komponenten mit dünner Personaldecke sind. Die gute Nachricht: Die Alternativen sind ausgereift, und mit der Gateway API gibt es einen sauberen Standard. Wer die Annotations inventarisiert und auf einen Parallelbetrieb setzt, kann die Umstellung ohne Hektik erledigen. Warten, bis die nächste Lücke auftaucht, ist dagegen der teuerste Weg.
Klingt spannend? Reden wir darüber
Bei ONTEC betreiben und betreuen wir Kubernetes-Umgebungen für Unternehmen mit hohen Anforderungen an Stabilität und Sicherheit. Wenn Sie wissen möchten, ob und wo ingress-nginx bei Ihnen noch läuft, oder die Ablöse planen, unterstützen wir Sie gerne: von der Bestandsaufnahme der Annotations über die Auswahl des passenden Controllers bis zur Umstellung im laufenden Betrieb.
Hannes Gruber
ONTEC AG
Kundenorientierung bedeutet für mich sich in die Lage des Kunden versetzen zu können. Genaues Zuhören, verstehen und ein fachlich top aufgestelltes Team sind hierbei entscheidend, um den Kunden die optimale Lösung anzubieten.
