Die Kubernetes-Welt steht vor einem massiven Umbruch. Jahrelang war der NGINX Ingress Controller der De-facto-Standard für den Traffic in den Clustern. Doch die Zeichen stehen auf Sturm: Das Projekt NGINX verliert an Fahrt, die ursprüngliche Architektur zeigt ihr Alter, und Kubernetes Ingress selbst ist offiziell «frozen».
Vielleicht haben Sie von den Warnrufen bezüglich der «Ingress Nightmare»-Sicherheitslücken (wie CVE-2025-1974) gehört. Es ist Zeit, der Realität ins Auge zu sehen: Legacy Ingress ist ein Sicherheitsrisiko.
In diesem Beitrag zeigen wir Ihnen, warum der Wechsel auf die Kubernetes Gateway API mit dem Airlock Microgateway nicht nur ein notwendiges Übel, sondern ein massives Upgrade für Sicherheit und Architektur ist.
Der «Ingress Nightmare» und das Ende einer Ära
Warum jetzt handeln? Zwei Gründe:
- Ingress ist eingefroren: Die Kubernetes Ingress API (networking.k8s.io/v1) wird nicht mehr weiterentwickelt. Sie ist funktional limitiert und führt zu «Annotation Hell» – unübersichtliche Konfigurationen, die schwer zu warten sind.
- NGINX Architektur-Schwächen: NGINX ist ein fantastischer Webserver, war aber nie «Cloud Native».
- Ingress-NGINX wird zum 26. März 2026 eingestellt.
Hier kommt Envoy ins Spiel. Im Gegensatz zu NGINX wurde Envoy für die Cloud gebaut: dynamisch, ohne Config-Reloads und hochgradig observierbar. Airlock Microgateway basiert vollständig auf Envoy – und erbt damit dessen «Cloud Native»-Architektur.
Dazu kommt das WAF‑Thema (“Secure by Design”):
- ModSecurity ist faktisch im EOL‑Übergang, NGINX‑ModSecurity‑WAF wurde abgekündigt.
- OWASP Coraza ist als moderne Engine spannend, aber eher ein Baukasten: junges Ökosystem, sie müssen Integration, Betrieb und Tooling selbst lösen.
Für unternehms- und sicherheitskritische Infrastrukturen ist dieser Stack schwer kalkulierbar – gerade unter Compliance‑Druck.
Airlock Microgateway & Gateway API: Der neue Standard
Die Ingress‑API bleibt minimal und stabil, ist aber „feature‑frozen“. Für alles, was über simples Host/Path‑Routing hinausgeht, landet die Community bei Gateway API, mit folgenden Vorteilen:
- Rollenbasiert: Plattform‑Team verwaltet GatewayClass/Gateway, App‑Teams HTTPRoutes. Mehrere Teams können eigene HTTPRoute-Objekte mit denselben Hostnamen verwenden, ohne Nebenwirkungen beim Rollout von Applikationen.
- Leistungsstarke Funktionen: Header‑Matching, Traffic‑Splitting, mehrere Backends, TLS‑Policies, externe Authentifizierung.
- Portabel & zukunftssicher: Gemeinsamer Standard statt Vendor‑Annotations. Kein Lock-in auf bestimmte Lieferanten.
Kurz: Ingress ist Vergangenheit, Gateway API die Zukunft. Wer ohnehin migriert (z.B. weg von Ingress-NGiNX), sollte nicht noch einmal auf einen reinen Ingress‑Controller setzen.
Gateway API ist der offizielle Nachfolger von Ingress. Sie trennt sauber zwischen Routing und Security. Airlock Microgateway nutzt dieses Design perfekt durch das sogenannte Policy Attachment Model.
Das bedeutet: Ihre Routes bleiben Standard-Kubernetes-YAML, während die Security via Airlock CRDs (z.B. AccessControlPolicy & ContentSecurityPolicy) «angeheftet» wird.
1. WAAP DNA: ContentSecurityPolicy
Während viele Ingress-Controller erst jetzt versuchen, Security-Features nachzurüsten, macht Airlock seit über 20 Jahren nichts anderes.
Über die ContentSecurityPolicy bringen Sie bewährte WAAP-Features (Web Application and API Protection) an Ihren Service.
Der Ansatz ist ein anderer – Immediately armed – Secure by Design:
Anstatt (wie bei NGINX oft üblich) alles zu erlauben und explizit Böses zu blockieren, drehen wir den Spiess um. Wir definieren strikt, was erlaubt ist (z.B. Schema-Validierung & erlaubte Pfade via OpenAPI Specs). Alles andere wird verworfen. Das ist Secure by Design.
Selbst ohne explizite Konfiguration wird jede Applikation automatisch geschützt (Immediately armed)! Eine Konfiguration ist nur nötig, um Abweichungen der Standardeinstellungen vorzunehmen. So ist sichergestellt, dass Security nicht vergessen und eine Applikation niemals ungeschützt exponiert werden kann.
2. Starke Authentisierung & IAM‑Integration
Filtern ist gut – Wissen, wer agiert, noch besser.
Deshalb bringt Airlock Microgateway Identity & Access Management direkt ins Gateway – ein klarer Unterschied zu klassischen Ingress‑Setups.
Zentrale Features:
- Token Introspection: Der Microgateway prüft Access Tokens beim ausstellenden Authorization Server (gültig, revoked, Claims/Scopes).
- JWT verification via JWKS
- Token Exchange: Externe Tokens (z.B. von Entra ID oder Partner‑IdPs) werden in interne Tokens übersetzt, die genau zu deinen APIs passen. Backends sehen nur noch ein konsistentes, internes Token‑Format.
- Path‑basierte Authentisierung: Über Policies lässt sich z.B. definieren:
- /public/** → ohne Auth, nur WAAP
- /api/** → Access Token mit bestimmten Scopes
- /admin/** → zusätzliche MFA‑Anforderungen
Zusammen mit Airlock IAM als cIAM‑Lösung (SSO, MFA, Adaptive Auth, Self‑Service) entsteht eine durchgängige Plattform:
- Microgateway setzt Policies durch und schützt Services,
- IAM verwaltet Identitäten, Logins und Risiko,
- beide sind technisch aufeinander abgestimmt (aber eine Integration mit andern IAM ist via JWT oder OIDC dennoch möglich).
Statt Ingress‑NGINX + ModSecurity/Coraza + IdP + Eigenbau‑Glue bekommen Sie WAAP + IAM aus einer Hand – ready to protect!
Migration leicht gemacht
Schauen Sie sich unser Running Example an.
Fazit: Jetzt die Weichen stellen
Das Festhalten an NGINX und Ingress V1 ist technologische Schuldenverwaltung. Mit Airlock Microgateway wechseln Sie das Paradigma:
- Von «Legacy Webserver» zu «Cloud Native».
- Von «Annotation-Chaos» zu «Strukturierten Policies (AccessControl & ContentSecurity)».
- Von «Basic Auth» zu «Advanced IAM Integration».
Warten Sie nicht, bis es zu spät ist! Starten Sie Ihre Migration jetzt!