Von NGINX Ingress zur Gateway API: Airlock Microgateway als Sicherheitsupgrade für Kubernetes

Paradigmenwechsel in der Kubernetes-Infrastruktur

Die Kubernetes-Community erlebt derzeit einen grundlegenden Wandel. Der NGINX Ingress Controller, über Jahre hinweg die bevorzugte Lösung für Traffic-Management in Clustern, gerät zunehmend unter Druck. Die Entwicklung des Projekts verlangsamt sich, die technische Basis zeigt Alterungserscheinungen, und die Kubernetes Ingress API selbst erhält keine neuen Features mehr.

Aktuelle Sicherheitslücken wie CVE-2025-1974 verdeutlichen die Risiken veralteter Ingress-Implementierungen. Unternehmen stehen vor der Frage: Wie lässt sich Kubernetes-Infrastruktur zukunftssicher und sicher gestalten?

Technische Limitation klassischer Ingress-Lösungen

Die Kubernetes Ingress API (networking.k8s.io/v1) befindet sich im Feature-Freeze. Neue Funktionalität wird nicht mehr entwickelt. In der Praxis führt dies zu umfangreichen Annotation-basierten Konfigurationen, die schwer wartbar und fehleranfällig sind.

NGINX selbst wurde ursprünglich als Webserver konzipiert, nicht als Cloud-Native-Komponente. Die Architektur erfordert Configuration-Reloads bei Änderungen und bietet nur eingeschränkte Observability. Mit der angekündigten Einstellung von Ingress-NGINX zum 26. März 2026 wird die Situation zusätzlich verschärft.

Im Bereich Web Application Firewall (WAF) steht ModSecurity vor dem End-of-Life, während NGINX-ModSecurity-WAF bereits eingestellt wurde. OWASP Coraza präsentiert sich als moderne Alternative, befindet sich jedoch in einer frühen Entwicklungsphase. Unternehmen müssen Integration, Betrieb und Tooling eigenständig umsetzen – ein Aufwand, der unter Compliance-Anforderungen schwer kalkulierbar ist.

Gateway API als offizieller Nachfolger

Die Kubernetes Gateway API löst Ingress als Standard ab. Sie bietet eine klare Rollentrennung: Plattform-Teams verwalten GatewayClass und Gateway, während Anwendungsteams eigenständig HTTPRoute-Objekte konfigurieren. Mehrere Teams können parallel dieselben Hostnamen nutzen, ohne sich gegenseitig zu beeinträchtigen.

Funktional geht die Gateway API deutlich über Ingress hinaus. Header-basiertes Matching, Traffic-Splitting zwischen mehreren Backends, dedizierte TLS-Policies und externe Authentifizierung sind native Bestandteile der API. Die Standardisierung verhindert Vendor-Lock-in durch proprietäre Annotations.

Envoy bildet die technische Basis vieler Gateway-API-Implementierungen. Im Gegensatz zu NGINX wurde Envoy für Cloud-Umgebungen entwickelt: dynamische Konfiguration ohne Reloads, umfassende Observability und hochperformante Request-Verarbeitung.

Airlock Microgateway: Security-first-Ansatz

Airlock Microgateway nutzt das Policy Attachment Model der Gateway API konsequent. Routing-Konfigurationen bleiben Standard-Kubernetes-YAML, während Sicherheitsrichtlinien über Custom Resource Definitions (CRDs) wie AccessControlPolicy und ContentSecurityPolicy angebunden werden.

Web Application and API Protection

Die ContentSecurityPolicy implementiert einen restriktiven Ansatz: Anstatt bekannte Angriffsmuster zu blockieren, wird ausschließlich definiertes Verhalten zugelassen. Schema-Validierung und Path-Filtering basieren auf OpenAPI-Spezifikationen. Nicht explizit erlaubte Requests werden abgewiesen.

Standardmäßig ist jede Anwendung geschützt, ohne dass manuelle Konfiguration erforderlich ist. Anpassungen werden nur bei Abweichungen von den Vorgaben vorgenommen. Dies minimiert das Risiko, dass Dienste ungeschützt exponiert werden.

Identity und Access Management

Airlock Microgateway integriert IAM-Funktionen direkt auf Gateway-Ebene. Token Introspection prüft Access Tokens beim Authorization Server auf Gültigkeit, Revocation-Status und Claims. JWT-Verifikation erfolgt über JWKS-Endpunkte.

Token Exchange ermöglicht die Transformation externer Tokens (etwa von Entra ID) in interne Formate. Backend-Services erhalten konsistente Token-Strukturen, unabhängig vom ursprünglichen Identity Provider.

Path-basierte Authentisierung erlaubt granulare Regelungen:

• Öffentliche Endpunkte ohne Authentifizierung, aber mit WAAP-Schutz
• API-Endpunkte mit Token-Validierung und Scope-Prüfung
• Administrative Bereiche mit zusätzlichen MFA-Anforderungen

In Kombination mit Airlock IAM als Customer Identity and Access Management (cIAM) entsteht eine durchgängige Plattform. Das IAM verwaltet Identitäten, Single Sign-On und adaptive Authentifizierung, während der Microgateway Policy Enforcement übernimmt. Die Komponenten sind technisch aufeinander abgestimmt, alternativ ist die Integration anderer IAM-Systeme über JWT oder OIDC möglich.

Migration und Implementierung

Die Umstellung von NGINX Ingress auf Gateway API mit Airlock Microgateway erfolgt schrittweise. Praktische Beispiele demonstrieren die Konfiguration von HTTPRoutes, Security-Policies und IAM-Integration. Die Gateway API ermöglicht parallelen Betrieb während der Migrationsphase.

Fazit: Architektur für die nächste Dekade

Die Entscheidung für oder gegen Legacy-Ingress-Lösungen ist strategisch. Airlock Microgateway verbindet Cloud-Native-Architektur auf Envoy-Basis mit etablierter Security-Expertise. Strukturierte Policies ersetzen Annotation-Chaos, fortgeschrittene IAM-Integration die rudimentäre Basic Authentication.

Unternehmen, die NGINX Ingress einsetzen, sollten die Migration zur Gateway API priorisieren. Der Wechsel zu einer ingress-basierten Zwischenlösung verlängert lediglich die technische Schuld. Mit Gateway API und Airlock Microgateway entsteht eine zukunftsfähige Kubernetes-Security-Architektur.

Weiterlesen

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk