ingress-nginx Retirement: Vier Wege nach vorn

Die Aussage “der Kubernetes-Controller ingress-nginx wird bald nicht mehr gewartet” passt schon lange nicht mehr — die Wartung ist bereits beendet. Das GitHub-Repository wurde am 2026-03-24 archiviert und auf read-only gestellt, und die eigene Beschreibung des Projekts steht inzwischen in der Vergangenheitsform: es war ein Ingress Controller. Für eine Software, die Berichten zufolge nach wie vor vor rund der Hälfte aller Cloud-native-Workloads läuft, ist das eine abgeschlossene Tatsache, kein Countdown.

Das ist Teil 1 eines Field Guides zur Migration weg davon. Dieser Teil ist bewusst nicht-technisch — er richtet sich an alle, die entscheiden müssen, was zu tun ist, noch nicht an diejenigen, die die eigentliche Migrationsarbeit übernehmen. Die folgenden Teile werden konkret: eine Inventur der tatsächlich genutzten Funktionen, eine Annotation-Kompatibilitätsmatrix, Migrationsmechanik und ein reproduzierbares Lab.

Das ist die deutsche Ausgabe vom englischen ingress-nginx Retirement: Four Ways Forward.

Serien-Navigation: Die weiteren Teile dieser Serie (Teil 2 bis 7) sind nur auf Englisch verfügbar.

• Field Guide (Übersicht): ingress-nginx Migration: A Field Guide
• Teil 1 — Entscheidung (dieser Beitrag)

Was tatsächlich nicht mehr gewartet wird — und was schon🔗

Die Retirement-Ankündigung ist beim Scope präzise, und die Unterscheidung ist wichtig — man rutscht hier leicht vom konkreten Fall auf eine überzogene generelle Annahme.

Bestehende Deployments werden dadurch nicht kaputt. Bereits veröffentlichte Helm-Charts und Container-Images bleiben verfügbar. Was aufhört, ist alles Zukunftsgerichtete: keine neuen Releases, keine Bugfixes — und der Teil, der bei allem Internet-facing tatsächlich zählt — keine Fixes für die nächste gefundene Sicherheitslücke.

Warum “es funktioniert noch” nicht der richtige Weg ist🔗

Die Erklärung des Kubernetes Steering Committee und des Security Response Committee ist ungewöhnlich direkt darüber, warum das passiert: ingress-nginx wurde über Jahre von ein bis zwei Personen unbezahlt gepflegt, und die angesammelten technischen Altlasten sowie sicherheitsrelevante Designentscheidungen (vor allem die snippet-Annotations) machten eine Weiterpflege “nicht mehr sinnvoll oder überhaupt möglich… selbst wenn sich Ressourcen finden würden.” Das ist eine Aussage über die Software selbst, nicht nur über die Finanzierung — die Committees stellen explizit klar, dass ein neuer Maintainer das nicht einfach umkehren würde.

Die Einstellung der Wartung hat bereits ein konkretes Beispiel für das Risiko geliefert. Am 2026-02-02 wurden vier CVEs in einem einzigen Batch offengelegt — zwei davon mit HIGH-Severity (CVSS 8.8 laut NVD): eine Configuration-Injection, die zu Remote Code Execution und Secret-Offenlegung führen kann (CVE-2026-24512), und eine Authentication-Bypass-Schwachstelle bei der auth-url-Annotation (CVE-2026-1580); plus CVE-2026-24513 und CVE-2026-24514 mit niedrigem (3,1) bzw. mittlerem (6,5) Risiko. Fixes existierten dafür, weil die Offenlegung noch vor dem Archivierungsdatum lag; dieselbe Offenlegung heute würde keinen mehr bekommen.

Es gibt auch eine Compliance-Seite, die es wert ist, offen zu benennen, auch ohne eine einzelne kanonische Quelle dafür: End-of-Life-Software im Request-Pfad ist genau das, wonach SOC 2, PCI-DSS, ISO 27001 und HIPAA-Audits gezielt suchen. Wer einem dieser Rahmenwerke unterliegt, wird “es funktioniert noch” wahrscheinlich nicht als Antwort durchgehen lassen — siehe dazu die eigene Compliance-Vertiefung dieses Blogs, wie PCI-DSS, HIPAA, NIS2, DORA und CRA-Controls sich konkret auf Kubernetes-Konfiguration abbilden.

Risiko-Zeitleiste🔗

Die Abfolge ist kurz und, an diesem Punkt, vollständig Vergangenheit:

1. 2025-11-11 — Kubernetes kündigt das Ende der Wartung an (Best-effort-Pflege bis März 2026).
2. 2026-01-29 — Steering Committee und Security Response Committee bekräftigen die Entscheidung in einer eigenen Erklärung.
3. 2026-02-02 — Vier CVEs werden in einem Batch offengelegt, zwei davon mit HIGH-Severity.
4. 2026-03-24 — Das Repository kubernetes/ingress-nginx wird archiviert und read-only gestellt.

Nichts in dieser Liste steht noch aus. Der einzige verbleibende Zukunfts-Punkt ist, welche Schwachstelle als nächste ungepatcht bleibt.

Vier ehrliche Wege nach vorn🔗

Keiner davon wird hier als die Antwort präsentiert — welcher Weg passt, hängt von der eigenen Annotation-Nutzung, der Team-Kapazität und der eigenen Risikotoleranz ab, die die folgenden Teile tatsächlich messbar machen, statt sie zu erraten.

1. Auf ingress-nginx bleiben und das Risiko akzeptieren. Als kurzfristige Position valide, wenn die Exposition ehrlich bewertet wurde — siehe “Warum “es funktioniert noch” nicht der richtige Weg ist“ — rein interner Traffic, eine kurze Vorlaufzeit bis zu einer geplanten Migration, oder eine kompensierende Kontrolle wie eine WAF davor. Nicht mehr valide, sobald es zum Standard wird, weil Migrieren zu einem anderen Ingress Controller zu viel Arbeit macht.
2. Zu einem anderen Ingress Controller wechseln. Der Weg mit dem geringsten Aufwand, wenn man bereits auf die Ingress API festgelegt ist und nur eine gepflegte Implementierung braucht. Teil 4 dieser Serie behandelt die konkreten Kandidaten und was von den bestehenden nginx.ingress.kubernetes.io/*-Annotations tatsächlich übernommen werden kann.
3. Zu Gateway API migrieren. Die strategische Option — dort geht die Kubernetes-Netzwerkwelt hin, und dort investiert jede größere Implementierung (Envoy Gateway, Cilium, Istio, die Managed-Angebote der Cloud-Anbieter). Auch die Option mit der meisten Migrationsmechanik, die es richtig zu machen gilt — dafür ist Teil 5 gedacht.
4. Einen gepflegten Fork als Übergangslösung nutzen. Chainguards EmeritOSS-Programm hat ingress-nginx genau für diesen Übergang geforkt: Der freie Fork auf GitHub bekommt Dependency-Updates und Best-effort-CVE-Fixes, aber keine neuen Features und keine vorgebauten Images; eine kommerzielle Stufe bringt vorgebaute Container-Images, eine Remediation-SLA und eine FIPS-Variante. In beiden Fällen wird es von den eigenen Maintainern als Zeitgewinn für eine bewusste Migration verstanden, nicht als dauerhafter Ersatz.

Was der Rest dieser Serie behandelt🔗

Dieser Teil hat eine Frage beantwortet: ob man handeln muss. Die ehrliche Antwort für praktisch jeden, der ingress-nginx auf internetseitiger Infrastruktur betreibt, ist Ja — auf einer Zeitachse, die man selbst festlegt, aber nicht auf unbegrenzte Zeit ignorieren kann. Der Field Guide verlinkt bereits auf alle Teile dieser Serie; Teil 2 (auf Englisch) beginnt die praktische Arbeit mit einer Inventur, was die eigenen Cluster tatsächlich benötigen, bevor irgendetwas verändert wird.

Quellen🔗

• Ingress NGINX Retirement: What You Need to Know — kubernetes.io (2025-11-11)
• Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees — kubernetes.io (2026-01-29)
• kubernetes/ingress-nginx — GitHub (archiviert 2026-03-24)
• Fork Yeah: We’re keeping ingress-nginx alive — Chainguard (2026)
• Introducing Chainguard EmeritOSS: Sustainable stewardship for mature open source — Chainguard (2026)
• Gateway API — Kubernetes SIG Network