Kubernetes Gateway API

 (romaglushko.com)
4 Punkte von GN⁺ 4 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Im November 2025 kündigte Kubernetes die Deprecation des NGINX Ingress Controller für März 2026 an, der in über 40 % aller Cluster eingesetzt wurde; diese Entscheidung markierte einen Wendepunkt, an dem sich die Gateway API als Nachfolgerin der Ingress API etablierte
  • Die Gateway API deckt ein breites Spektrum der für das Management von inbound Traffic nötigen Funktionen ab, ist ausdrucksstärker als die Ingress API und trennt Zuständigkeiten zwischen Teams klarer
  • Zu den Grenzen der Ingress API zählen der enge API-Umfang, unflexible Erweiterbarkeit, fehlende Policy-Durchsetzung, unklare Besitzgrenzen und fehlende sichere Unterstützung für Cross-Namespace-Szenarien
  • Die Gateway API bietet ein getrenntes Ressourcenmodell mit GatewayClass, Gateway, Listener und Route sowie Sicherheits- und Erweiterungsmechanismen wie ReferenceGrant und Policy attachment
  • Die wiederholten CVEs des NGINX Ingress Controller gehen auf strukturelle Schwächen zurück; langfristig ist die Migration zur Gateway API die einzige grundlegende Lösung

Die Entwicklung von Ingress

  • Im frühen Kubernetes von 2014 war die Ressource Service das grundlegende Mittel, um Anwendungen bereitzustellen
    • ClusterIP stellte nur einen clusterinternen DNS-Namen bereit, externer Zugriff war nicht möglich
    • NodePort öffnete auf allen Nodes einen bestimmten Port, um externen Traffic anzunehmen; wenn die Node-IP veröffentlicht war, war ein externer Zugriff möglich
    • LoadBalancer provisionierte einen externen Load Balancer mit öffentlicher IP zur Weiterleitung von Traffic
    • ExternalName stellte per CNAME-Record einen clusterinternen Alias für einen externen Dienst bereit
  • Von den vier Varianten ermöglichten nur NodePort und LoadBalancer direkte externe Exposition
    • NodePort ist ein grundlegendes Primitive, aber zu Low-Level; externes Load Balancing zwischen Nodes und pfadbasiertes Routing mussten direkt selbst implementiert werden
  • LoadBalancer ergänzte NodePort um einen L4-Load-Balancer (TCP/UDP) mit automatischer Provisionierung, zuständig war der Cloud Controller Manager
    • Allerdings mussten viele öffentliche IPs und Load Balancer verwaltet werden, was die Kosten erhöhte, und es gab keinen zentralen Punkt für das Traffic-Management
  • Statt für jeden Service einen eigenen Load Balancer zu betreiben, entstand mit Ingress API und Ingress Controller eine Architektur, in der ein einzelner LoadBalancer-Service den gesamten Traffic entgegennimmt und an ein Reverse-Proxy-Deployment wie NGINX weiterleitet, das dann anhand von Pfaden und Hostnamen routet

Ingress Controller

  • 2015 führte das Kubernetes-Team die Ingress API ein, um Regeln für das Routing von externem HTTP(S)-Traffic zu internen Services zu definieren

  • Die Ingress API besteht aus den zwei Ressourcen IngressClass und Ingress; sie definiert nur eine gemeinsame Schnittstelle, für das tatsächliche Verhalten muss ein Ingress Controller installiert werden

  • IngressClass

    • Eine clusterweite Ressource, die festlegt, welcher Controller eine bestimmte Menge von Ingress-Ressourcen verarbeitet
    • Dadurch können in demselben Cluster mehrere Ingress Controller parallel betrieben werden; jeder Controller beobachtet nur die Ressourcen, die über seine IngressClass ausgewählt wurden
    • Der Controller benötigt ClusterRole-Berechtigungen, um IngressClass zu lesen und zu verwenden

  • Ingress-Ressource

    • Ingress ist die zentrale Ressource der Ingress API und kombiniert mehrere Elemente
      • Definiert das Routing zu internen Services über pfadbasierte (exact/prefix) und hostbasierte Matching-Regeln
      • Definiert die TLS-Konfiguration für inbound Traffic
    • Beim Erstellen der Ressource erkennt der Ingress Controller dies, aktualisiert seine eigene Konfiguration und wendet die Routing-Regeln an

  • Probleme der Ingress API

    • In realen Betriebsumgebungen traten folgende Probleme auf: sehr begrenzter API-Umfang, unflexible Erweiterbarkeit, fehlende Policy-Durchsetzung, unklare Besitzgrenzen und fehlende sichere Unterstützung für Cross-Namespace-Szenarien

  • Sehr begrenzter API-Umfang

    • Die Ingress API ist nicht nur einfach, sondern zu simpel (simplistic) und deckt nur das absolute Minimum für die Konfiguration von Ingress-Traffic ab
    • Die folgenden in NGINX häufig gewünschten Funktionen werden nicht direkt unterstützt
      • Request-Timeout, CORS, Begrenzung der maximalen Body-Größe, Sticky-Cookie-Sessions, Canary-Traffic-Splitting, Rate Limiting, Routing basierend auf Headern, Querys oder Cookies sowie Header-Manipulation
    • Dadurch wurden Custom Annotations zum Standardweg, um zusätzliche Konfigurationen zu übergeben; einige Controller wie Traefik verwenden eigene CRDs
    • Werden mehrere Ingress Controller gleichzeitig genutzt, fehlt eine einheitliche Konfigurationsmethode; dadurch unterscheiden sich die Annotations je nach Controller und die Portabilität sinkt
    • Ingress behandelt nur HTTP(S)-Routing; gRPC (L7) sowie TCP und UDP (L4) werden je nach Implementierung über Custom Annotations verarbeitet

  • Unflexible Erweiterbarkeit

    • Custom Annotations sind nur Schlüssel-Wert-Paare aus Strings; komplexe Konfigurationen müssen daher als Strings serialisiert werden, was die Ausdrucksstärke einschränkt

  • Fehlende Policy-Durchsetzung

    • Anwendungsteams können Ingress-Ressourcen beliebige Annotations hinzufügen und etwa das vom Plattformteam für alle Routen erwartete Rate Limiting deaktivieren
    • Da die Ingress API selbst keinen Mechanismus zur Durchsetzung globaler Verhaltensregeln bietet, ist man auf externe Policy-Engines wie Kyverno oder OPA Gatekeeper angewiesen

  • Unklare Besitzgrenzen

    • Die Ingress-Ressource vermischt mehrere Konfigurationen
      • Routing-Regeln liegen in der Regel in der Verantwortung des Anwendungsteams
      • Hostname- und Port-Konfigurationen liegen in der Verantwortung des Plattformteams, das DNS, Load Balancer und Networking verwaltet
      • TLS-Konfigurationen liegen in der Verantwortung des Plattformteams, das die Zertifikatsbereitstellung übernimmt
      • Custom Annotations können beiden Teams gehören
    • In komplexen Systemen, die über ein Umbrella-Helm-Chart ausgerollt werden, befindet sich Ingress meist im Application-Subchart, doch das Plattformteam muss Teile davon ebenfalls aktualisieren oder durchsetzen
    • Aus Sicht des Single-Responsibility-Prinzips ist es wünschenswert, Ingress in stärker fokussierte Ressourcen aufzuteilen, da es mehr als einen Grund für Änderungen gibt
    Anzeige

  • Keine sichere Cross-Namespace-Unterstützung

    • Eine Ingress-Ressource kann keine Services oder TLS-Secrets außerhalb ihres eigenen Namespace referenzieren; in rules[].backend.service gibt es nicht einmal ein Feld zur Angabe eines Namespace
    • Als Workaround kann man im selben Namespace einen ExternalName-Service anlegen, der auf den clusterinternen DNS-Namen des Ziel-Service zeigt
    • Allerdings enthält dieser Ansatz unmittelbar ein Problem, das einem Confused-Deputy-Angriff entspricht

Gateway API

  • Die Gateway API ist die nächste Generation der Ingress API und beseitigt diese Grenzen auf folgende Weise
    • Sie deckt einen deutlich größeren Funktionsumfang für das Management von inbound Traffic ab und erhöht die Ausdrucksstärke
    • Sie spiegelt gängige Muster beim Besitz von Ressourcen wider und macht die Trennung von Zuständigkeiten zwischen Teams klarer
    • Sie enthält mit Policies einen definierten Erweiterungsmechanismus und flexible objektübergreifende Referenzen über Namespaces hinweg

GatewayClass

  • Ähnlich wie IngressClass definiert sie eine Menge von Gateways, die einer bestimmten Deployment-Instanz eines Gateway-Controllers gehört; Bedeutung und Struktur sind IngressClass praktisch gleich
  • Zusätzlich kann sie auf eine Custom Resource verweisen, die implementierungsspezifische Gateway-Konfiguration enthält
    • Einschließlich der Art der Exposition des Gateway-Proxys, Bootstrap- und Laufzeit-Standardeinstellungen, Deployment-Rollout- und Skalierungsmethoden sowie weiterer controllerspezifischer Optionen

Gateway

  • Die Gateway-Ressource repräsentiert ein dynamisch provisioniertes Edge Gateway, eine Infrastrukturabstraktion, die inbound Traffic entgegennimmt und an passende Backend-Services weiterleitet

    • In der Ingress-Architektur übernahm der Ingress Controller diese Rolle, sodass man ihn als statisch provisionierte Gateway-Instanz sehen kann

  • Jedes Gateway referenziert eine GatewayClass, um festzulegen, welcher Controller es provisioniert und verwaltet; die wichtigste Komponente ist die Liste der Listener

  • Listener

    • Definieren, wie ein Gateway eingehenden Traffic annimmt; jeder Listener ist ein eigener Einstiegspunkt, beschrieben durch die Kombination aus Port, Protokoll und Hostname
    • TLS-Termination kann konfiguriert werden; in der Ingress-Welt befand sich diese Information innerhalb der Ingress-Ressource
    • Die kleinstmögliche Einheit, an die eine Route an ein Gateway angehängt werden kann

  • ListenerSet

    • Listener eignen sich gut, um Einstiegspunkt-Konfigurationen zu zentralisieren, sind aber ungeeignet, wenn Hunderte benötigt werden
    • Der häufigste Fall sind HTTPS-Listener mit service-spezifischen Hostname- und TLS-Einstellungen statt eines einzelnen Wildcard-TLS-Zertifikats; es kann so viele Listener geben wie es Microservices gibt
    • Bei der Modellierung mit einem einzelnen Gateway treten zwei Probleme auf
      • Ein Gateway unterstützt maximal 64 Listener
      • Wenn viele Teams Listener und TLS verwalten, wird das Gateway zum Koordinationsengpass
    • Um dies zu verteilen und mandantenfähig zu machen, wird die Ressource ListenerSet verwendet

  • Zugelassene Listener und Routes

    • Nach der Trennung der Konzepte Gateway und Route entsteht ein neues Problem: zu steuern, welcher Tenant Routes an welche Listener anhängen darf
    • Listener sind gemeinsame Infrastruktur und dienen unterschiedlichen Zwecken; zum Beispiel ist es unpassend, eine HTTPRoute an den Listener tls-passthrough-db anzuhängen, der ein Passthrough-Kanal zu einer Datenbank ist, und ebenso unpassend, eine Route aus einem anderen Namespace als db anzuhängen
    • Da Routes in selbstverwalteter Weise hinzugefügt werden, wird zur Vermeidung von Fehlkonfigurationen der Mechanismus allowedRoutes verwendet
    • allowedRoutes stellt eine Vertrauensbeziehung zwischen Gateway oder ListenerSet und Routes bestimmter Namespaces und Route-Typen her

Routes

  • Listener nehmen Traffic an, wissen aber nicht, wie er danach verarbeitet werden soll; das übernehmen die Route-Ressourcen, der Kern der Flexibilität der Gateway API

  • Es gibt fünf Route-Ressourcen für verschiedene Protokolle

    • HTTPRoute: robusteres und erweitertes Routing für HTTP-Traffic
    • GRPCRoute: gRPC-bewusstes Routing
    • TLSRoute: TLS-SNI-basiertes Routing
    • TCPRoute·UDPRoute: leiten TCP/UDP-Traffic auf einem Listener-Port direkt an Backends weiter
    Anzeige

  • Alle Route-Ressourcen (zusammenfassend xRoutes) haben eine ähnliche Hüllstruktur

    • parentRefs sind typisierte Objektreferenzen auf übergeordnete Ressourcen, die die Route aufnehmen, meist Gateway, ListenerSet oder ein Service in einem Service Mesh; mit den optionalen Angaben sectionName und port kann ein bestimmter Listener angegeben werden
    • rules enthalten protokollspezifische Routing-Regeln, Filter und Konfigurationen; jede Regel besteht aus matches, optionalen filters und optionalen backendRefs; wenn ein Filter die Anfrage vollständig verarbeitet, können backendRefs weggelassen werden
    • Falls das Protokoll es erlaubt, ist hostbasiertes Routing auf Route-Ebene über das Feld hostnames möglich

  • HTTPRoute

    • Definiert Routing-Regeln für HTTP(S)-Traffic auf L7-Ebene

    • Traffic-Matching

      • Ähnlich wie bei Ingress werden pfad- und hostbasiertes Routing sowie Matching-Regeln auf Basis von Headern, Query-Parametern und Methoden unterstützt
      • Beispiel: Ein Canary-Release nur für interne Clients kann per headerbasiertem Matching auf ein Test-Deployment geroutet werden
      • Die Data Plane wendet immer die spezifischste Regel an; die Reihenfolge der Regeldefinition ist daher unerheblich

    • URL-Rewrites

      • Mit Filtern können Teile der Request-URL umgeschrieben werden, bevor sie das Backend erreicht

    • Header-Änderungen

      • Es gibt den Filter HeaderModifier, um Request- und Response-Header hinzuzufügen, zu entfernen oder zu ändern
      • Es gibt außerdem einen dedizierten CORS-Filter für Cross-Origin Resource Sharing; konzeptionell ist das ein Sonderfall der Änderung von Response-Headern, wird aber als eigener Filtertyp angeboten

    • Redirects

      • Statt an ein Backend weiterzuleiten, kann eine Redirect-Response an den Client zurückgegeben werden; unterstützt werden pfadbasierte 3xx-Redirects sowie Redirects von HTTP zu HTTPS

    • Traffic-Steuerung

      • Per Weight kann Traffic zwischen Backend-Services aufgeteilt werden, nützlich für Blue-Green-Deployments und A/B-Tests
      • Traffic Mirroring sendet eine Kopie des produktiven Traffics an ein zusätzliches Backend und wird mit dem Filter RequestMirror konfiguriert; die ursprüngliche Anfrage geht weiterhin an das Standard-Backend
      • Mirroring ist eine Schlüsselkomponente von Tap-and-Compare-Tests, bei denen während Refactoring oder Migration die Ergebnisse alter und neuer Versionen verglichen werden

    • Sticky Sessions

      • Session-Persistenz wird unterstützt; Cookies und Header können als Session-Marker gesetzt werden, damit Anfragen desselben Clients konsistent an dieselbe Backend-Instanz geroutet werden

    • Externe Authentifizierung

      • Unterstützt einen gRPC- oder HTTP-basierten experimentellen Filter für externe Authentifizierung; das Gateway sendet vor der Weiterleitung an das Backend Request-Header an einen externen Authentifizierungsdienst, der Request-Body wird nur bei expliziter Aktivierung übertragen
      • Bei gRPC muss der externe Authentifizierungsdienst Envoys ext_authz-protobuf-API implementieren
      • Bei HTTP wird bei erfolgreicher Authentifizierung 200 zurückgegeben, jeder andere Status wird als Authentifizierungsfehler behandelt

    • Retries & Timeouts

      • Für einzelne Routen können Retry-Einstellungen gesetzt werden; BackendTrafficPolicy bietet ein globales Retry-Budget zur Vermeidung von Retry-Stürmen

  • GRPCRoute

    • Da gRPC auf HTTP/2 basiert, könnte es auch mit HTTPRoute behandelt werden, es gibt jedoch Gründe für eine Modellierung als eigene Ressource
      • Optionen wie URL-Rewrite, die für gRPC bedeutungslos sind, werden getrennt, sodass sich jede Ressource unabhängig passend zum Protokoll weiterentwickeln kann
      • gRPC-Responses liefern HTTP 200, drücken Anwendungsfehler aber über die Header grpc-status und grpc-message aus; das ist wichtig für korrekte Retries und Metriken
      • Die Definition von Regeln in gRPC-spezifischer Terminologie verbessert die User Experience
    • Der Path-Matcher von HTTPRoute wird durch einen Method-Matcher ersetzt; intern wird zwar der Pfad gematcht, nach außen wird dies aber in Form von Service und Methode dargestellt
    • Request- und Response-Header können verarbeitet werden, das gRPC-Payload wird jedoch nicht dekodiert, daher ist Routing auf Basis bestimmter Protobuf-Felder nicht möglich
    • Unterstützt einen Teil der HTTPRoute-Filter wie Traffic Mirroring, gewichtetes Load Balancing und Header-Änderungen

  • TCPRoute und UDPRoute

    • Leiten Traffic, der einen Listener-Port erreicht, einfach an Backend-Services weiter; Matcher und Filter werden derzeit nicht unterstützt
    • Beide Typen unterstützen gewichtetes Load Balancing über mehrere Backends hinweg

  • TLSRoute

    • Leitet TLS-verschlüsselten Traffic auf Basis des während des TLS-Handshakes bereitgestellten SNI an ein Backend weiter
    • Wird hauptsächlich für TLS-Passthrough verwendet: Das Gateway prüft das SNI, wählt das Backend aus und leitet dann die verschlüsselte Verbindung ohne TLS-Termination weiter; das Backend übernimmt die TLS-Termination
    • Einige Implementierungen wie Envoy Gateway oder kgateway unterstützen auch TLS-Termination am Edge, das ist jedoch eine Erweiterungsfunktion
    • Die Route muss einen Hostname angeben, der mit dem SNI-Wert übereinstimmt und sich mit dem Hostname des Gateway-Listeners überschneiden muss; Matcher und Filter werden nicht unterstützt, gewichtetes Load Balancing jedoch schon

  • Route-Filter-Erweiterungen

    • HTTPRoute und GRPCRoute enthalten mit dem Filter extensionRef einen Mechanismus zur Erweiterung um benutzerdefinierte Filter sowie Request-/Response-Verarbeitung; er verweist per typisierter Objektreferenz auf andere Ressourcen
    • Beispiel: Envoy Gateway bietet eine HTTPRouteFilter-CRD, die direkt eine Response zurückgeben kann, ohne einen Backend-Service zu verwenden

  • Backend-Ziele

    • Standardmäßig werden die regulären Service-Ressourcen (am gebräuchlichsten) sowie ServiceImport für Multi-Cluster als Backend-Ziele unterstützt.
    • Da sie als typed object reference angegeben werden, ist eine Erweiterung durch implementierungsspezifische Custom Resources möglich.
    • Beispiel: Envoy Gateway unterstützt eine benutzerdefinierte Backend-Ressource, die auf externe Upstreams wie FQDN, IP oder UNIX-Socket verweist.
    Anzeige

  • ReferenceGrant

    • Die Gateway API behandelt namespace-übergreifende Referenzen als erstklassiges Konzept im Standarddesign, allerdings bestehen Sicherheitsrisiken.
    • Beispiel für einen confused deputy attack: Wenn ein Angreifer die Kontrolle über einen Namespace übernimmt, kann er mit den Rechten zum Erstellen von Ingress-, Service- und EndpointSlice-Ressourcen den Zugriff auf geschützte Services abfließen lassen.
      • Ein neuer Ingress verweist auf einen neuen Service im kompromittierten Namespace.
      • Dieser Service ist selectorless, passt also zu keinem Deployment, sodass EndpointSlice manuell bereitgestellt werden kann.
      • Der Angreifer fälscht einen EndpointSlice, der die Pod-IP eines geschützten Backend-Pods aus einem anderen Namespace enthält, und schafft durch Port-Abgleich einen zweiten Zugang zum geschützten API-Endpunkt.
      • Dasselbe Ergebnis lässt sich auch mit einem ExternalName Service erreichen.
    • Zur Abmilderung wurde die Ressource ReferenceGrant eingeführt, ein Mechanismus für bidirektionales Vertrauen, mit dem ein Namespace festlegt, welche anderen Namespaces auf seine Ressourcen verweisen dürfen.
    • Der Gateway Controller berücksichtigt ReferenceGrant bei namespace-übergreifenden Referenzen auf Backend-Ziele und TLS-Secrets und erschwert damit confused deputy attack.
    • Allerdings garantiert ReferenceGrant nur die Legitimität der Referenz und greift nicht in das Verhalten nach der Weiterleitung des Datenverkehrs ein; ergänzend können NetworkPolicies den Zugriff auf geschützte API-Ports blockieren.

Policies

  • Policy Attachment ist ein mächtiges Erweiterungsmuster, mit dem sich Verhalten und Wirkung hierarchisch auf eine oder mehrere Gateway-API-Komponenten anwenden lassen, ohne die ursprüngliche Ressource zu ändern.
  • Authentifizierung ist ein typisches Beispiel.
    • Wenn Authentifizierung auf das gesamte Gateway (oder ListenerSet) angewendet wird, wirkt sie sich hierarchisch auf alle aktuell und künftig angehängten Routes aus; gleichzeitig sind Ausnahmen auf Route-Ebene wie öffentliche Routen möglich.
    • Die Authentifizierung kann von einem Team kontrolliert werden, das weder für Gateway noch Route zuständig ist, sodass diese Ressourcen bewusst nicht direkt geändert werden müssen.
    • Trotz Standards wie OAuth 2 und OIDC sind Authentifizierungs-Konfigurationen stark implementierungsabhängig, weshalb eine für alle Implementierungen passende Abstraktion schwierig ist.
  • Beispiel: Mit der Ressource SecurityPolicy von Envoy Gateway wird die Validierung von JWT-Tokens konfiguriert; Policies sind ein moderneres und ausdrucksstärkeres Modell als die annotationsbasierte Konfiguration aus der Ingress-Ära.
  • Es gibt nur zwei mitgelieferte Policies.
    • BackendTLSPolicy: weist das Gateway an, per TLS eine Verbindung zu Upstream-Backends aufzubauen.
    • BackendTrafficPolicy: legt das Retry-Budget für ein bestimmtes Backend fest; wird das globale Retry-Limit überschritten, wird 503 zurückgegeben. Das wirkt wie ein Circuit Breaker und verhindert Retry Storms.

Ownership

  • Gateway-API-Ressourcen im Cluster gehören in der Regel zwei Teams.
    • Das Platform-Team definiert GatewayClass, Gateway, ListenerSet sowie LoadBalancer- und TLS-Konfiguration und kann globale Policies verwalten, die für einen Teil oder das gesamte Gateway gelten.
    • Das Application-/Service-Team konzentriert sich hauptsächlich auf seine eigenen Route-Ressourcen und wendet bei Bedarf Policies auf Route-Ebene an.
  • Durch die hohe Flexibilität sind auch andere Ownership-Modelle möglich, etwa dass das Platform-Team alle Routes gesammelt in einem Namespace besitzt.

Typische Architektur

  • Die Gateway API setzt keine bestimmte Implementierungsarchitektur voraus, häufig ist jedoch eine Trennung von Control Plane und Data Plane.
  • Der Gateway Controller übernimmt die Rolle der Control Plane als Kubernetes-Operator, überwacht Gateway-API-Ressourcen und CRDs, aggregiert daraus die gewünschte Konfiguration der Data Plane und benötigt erweiterte Berechtigungen zum Lesen und Ändern von Ressourcen.
  • Die Gateway Data Plane ist ein Proxy, der den Verkehr gemäß der Konfiguration verarbeitet; häufig werden Envoy Proxy, NGINX oder Traefik verwendet, je nach Implementierung als dedizierter oder gemeinsam genutzter Proxy pro Gateway.
  • Die Trennung von Control Plane und Data Plane ist eine vorteilhafte Designentscheidung, um grundlegende Sicherheitslücken wie die im NGINX Ingress Controller zu vermeiden.

Ingress-Migration

  • Für die Reaktion auf die Deprecation des NGINX Ingress Controller gibt es vier Optionen, die in Reihenfolge steigender Eingriffstiefe betrachtet werden sollten.

  • Nichts tun

    • Das ist nicht optimal, kann aber in manchen Fällen funktionieren; in einem Homelab ist die Motivation dafür möglicherweise gering.

    • In Unternehmensumgebungen ist das jedoch wegen Regulierungs-, Sicherheits- und Compliance-Frameworks, die den Betrieb gewarteter und gepatchter Software erwarten, schwer zu rechtfertigen.

      • ISO 27001: erwartet Schwachstellenmanagement, Patches und Nachverfolgung von EOL.
      • SOC 2 Type II: erwartet Schwachstellenscans, Patch-Management und SLAs zur Behebung.
      • HIPAA Security Rule: verlangt, dass Legacy- und ungepatchte Software in die Risikoanalyse einbezogen wird.
      • PCI DSS v4.0.1: verlangt die Identifikation nicht unterstützter Komponenten, einen Behebungsplan sowie Fristen für den Umgang mit kritischen Schwachstellen.
      • FedRAMP: erwartet, dass nicht unterstützte Software durch gewartete Alternativen ersetzt wird, und definiert Behebungsfristen je nach Schweregrad.

    • In den meisten Frameworks wird EOL-Software bei Bekanntwerden neuer Schwachstellen zu einem realen Problem.

    • CVE-Analyse

      • CVE-Lage des NGINX Ingress Controller in den vergangenen fünf Jahren
        • Insgesamt 20 Schwachstellen
        • 2021 vier High-Schwachstellen im Zusammenhang mit Secret-Leaks
        • 2022 eine High-Schwachstelle im Zusammenhang mit dem Leak von Controller-Credentials
        • 2023–2024 drei High-Schwachstellen
        • 2025 sechs Schwachstellen, darunter eine Critical (IngressNightmare) und vier High-Schwachstellen im Zusammenhang mit NGINX-Konfigurationsinjektion
        • 2026 sechs Schwachstellen, darunter drei High-Schwachstellen im Zusammenhang mit NGINX-Konfigurationsinjektion
      • Die CVEs von 2021–2022 betrafen überwiegend unbereinigte, benutzerseitig gelieferte NGINX-Konfigurationen in annotations und führten zu Konfigurationsinjektion, Informationsoffenlegung und Secret-Leaks; Kubernetes ergänzte daraufhin Validierung.
      • Die CVEs von 2023–2024 waren vor allem Umgehungen dieser annotations-Validierung.
      • IngressNightmare (CVE-2025-1974) verschärfte die Lage: Zuvor waren Rechte zum Erstellen oder Ändern von Ingress-Ressourcen nötig, doch mit bloßem Netzwerkzugang zum Admission Controller wurde per bugähnlicher Konfigurationsinjektion Remote Code Execution im Kontext des ingress-nginx-Controllers möglich; anschließend konnten Secrets abgegriffen werden, auf die der Controller Zugriff hatte.
      • Auch die Serie von 2026 setzte das Muster der Konfigurationsinjektion über annotations, Pfade und Kommentare fort.
      • Diese Schwachstellen zielen immer wieder auf dieselbe Designschwäche.
        • Der Controller ist extrem flexibel und exponiert umfangreiche NGINX-Funktionen, wodurch vollständige Validierung schwierig ist und Konfigurationsinjektion wiederholt auftritt.
        • Der Controller führt Control Plane und Data Plane im gleichen Pod aus und teilt sich das Dateisystem, was im Schadensfall den Wirkungsbereich vergrößert.
        • Der Controller hat häufig Zugriff auf clusterweite Secrets, sodass erfolgreiche Konfigurationsinjektion zum Leak clusterweiter Secrets führen kann.
      • Aufgrund dieser strukturellen Probleme sind weitere CVEs zu erwarten; ohne Migrationsplan beim Original-Controller zu bleiben, ist eine riskante Entscheidung.
      Anzeige

  • Nutzung eines NGINX-Controller-Forks

    • Der einfachste Weg ist der Wechsel zu einem weiter gepflegten Fork.
      • Chainguards Fork stellt offenbar keine vorgefertigten Images bereit; dies scheint Teil des Angebots zu sein.
    • Damit lässt sich das Risiko neuer CVE-Exposition verringern und das System ohne größere Änderungen weiterbetreiben, es ist jedoch nur eine kurzfristige Lösung.
    • Chainguard verfolgt offenbar nicht das Ziel, den Controller langfristig weiterzuentwickeln, sondern bietet nach bestem Aufwand CVE-Korrekturen, um Nutzern Zeit für die Migration zu verschaffen.

  • Nutzung eines anderen Ingress Controllers

    • Da die Ingress-Ressource selbst nicht deprecated ist, ist auch ein Wechsel zu einem anderen weiterhin gepflegten Ingress Controller sinnvoll, etwa HAProxy, Istio oder Traefik
    • Eine Migration der Annotations im gesamten System ist erforderlich; der Aufwand variiert je nach Abhängigkeit von NGINX-spezifischen Funktionen
    • Künftig werden mehr Projekte zur Gateway API wechseln und der Anteil von Ingress wird sinken, doch vorerst ist auch Ingress weiterhin völlig ausreichend

  • Migration zur Gateway API

    • Die einzige langfristige Option ist der Wechsel von der Ingress API zur Gateway API
      • Installation der Gateway-API-CRDs und der Implementierung
      • Konfiguration von GatewayClass, Gateway und bei Bedarf Policy-Ressourcen
      • Migration bestehender Ingress-Ressourcen zu Routes
    • Das vom Kubernetes-Team entwickelte CLI ingress2gateway bietet eine automatische Umwandlung nach dem Best-Effort-Prinzip; benutzerdefinierte Annotations müssen anschließend noch manuell überprüft werden
    • Timeout-Werte, Dateiupload-Limits, Body-Size-Limits usw. müssen exakt migriert werden; Auslassungen oder Fehlzuordnungen können Annahmen der Anwendung stillschweigend verletzen
    • Der Traffic-Wechsel vom LoadBalancer des Ingress Controllers zum LoadBalancer des neuen Gateway-Proxys muss sorgfältig geplant werden und muss kein Big Bang sein
      • Der Ingress Controller kann vorübergehend als öffentlicher Einstiegspunkt bestehen bleiben, während nur ein Teil des Traffics an die Gateway-API-Data-Plane geleitet wird, um echten Traffic zu testen und anschließend schrittweise umzuschalten

Welches Gateway sollte man wählen?

  • Nach der Entscheidung zur Migration ist die erste große Frage, welche Gateway-API-Implementierung verwendet werden soll

  • Die Definition eines generischen API-Gateway-Anwendungsfalls in diesem Artikel: ein skalierbares Gateway für öffentlichen North-South-Traffic, das in einer vollständig kontrollierten Umgebung bereitgestellt wird und gängige Authentifizierungsmuster sowie flexibles Rate Limiting standardmäßig bietet

  • Neben API Gateways gibt es auch LLM Gateways und Agent Gateways, doch dieser Abschnitt konzentriert sich auf klassische API Gateways

  • Gateway API Conformance

    • Das Kubernetes-Team stellt standardisierte Conformance-Tests bereit, die die Korrektheit der Kernprotokollverarbeitung einer Implementierung prüfen; der Fokus liegt überwiegend auf funktionalem Verhalten, nichtfunktionale Aspekte wie Zuverlässigkeit, Performance, Skalierbarkeit oder operative Komplexität sind nicht enthalten
    • Konforme Implementierungen sollten bevorzugt werden; wenn auf der offiziellen Website keine Ergebnisse vorhanden sind, sollte man die Maintainer nach einem Conformance-Bericht fragen

  • Öffentliche Benchmarks

    • Neben offiziellen Tests gibt es öffentliche Benchmarks zu Zuverlässigkeit und Performance; John Howard, Istio-Contributor und Mitarbeiter von Solo.io, hat Benchmarks für wichtige Implementierungen erstellt; Solo.io ist die Muttergesellschaft von kgateway
    • Enthalten sind nützliche Testfälle wie Route-Attachment, Propagation, Skalierung und allgemeine Traffic-Verarbeitungsleistung; da sie auf seinen eigenen Erfahrungen basieren, können sie zu bestimmten Anwendungsfällen tendieren, sind aber als eine Perspektive für die Bewertung nutzbar

  • OSS vs. Proprietär

    • Heute gibt es viele leistungsfähige produktionsreife OSS-Gateway-API-Implementierungen, die bei einer Bewertung ernsthaft berücksichtigt werden sollten; für viele Organisationen ist OSS der Standardausgangspunkt
    • Funktionen wie OAuth2 und OIDC, die früher den Kauf kommerzieller Produkte rechtfertigten, sind zu Commodity geworden; auch OSS-Controller bieten sie standardmäßig
    • Bei OSS kann die Qualität vor einer Festlegung direkt bewertet werden, während man bei kommerziellen Angeboten dem Anbieter früh vertrauen muss

  • Empfehlungen

    • Gruppierung nach Data Plane

      • Auf Envoy Proxy basierend: Envoy Gateway, Istio, Cilium, kgateway usw.
      • Auf NGINX basierend: NGINX Gateway Fabric, Kong
      • Andere Proxys: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Ein Open-Source-Gateway-API-Controller auf Basis von Envoy Proxy, entwickelt vom Envoy-Proxy-Team; er bildet Envoy-Funktionen möglichst direkt auf die Gateway API ab und enthält dadurch weniger produktspezifische Abstraktionen als Istio, was das Verständnis erleichtert
      • Die Ingress API wird nicht unterstützt; mit Envoy AI Gateway kann er um Funktionen für LLMs, MCP-Gateways und Inference Pools erweitert werden
      • Leichtgewichtig und einfach zu deployen und zu betreiben, mit Fokus auf API Gateway (North-South); unterstützte Funktionen
        • Sicherheitsmuster wie externe Authentifizierung, JWT-Validierung, Autorisierung auf Basis von JWT-Claims, OIDC, IP-Allowlisting, statische API-Key-Authentifizierung und Credential Injection
        • Flexible globale Rate-Limit-Policies mit globalen und routebezogenen Einstellungen, Shadow Mode, Konfiguration von Request Costs usw.
        • Connection-, Bandwidth- und Dateigrößen-Limits, Availability-Zone-bewusstes Routing, grundlegendes Multi-Cluster auf Basis von ServiceImport, Antwortkomprimierung mit Brotli, gzip und zstd sowie Direct Response und Response Override
        Anzeige
      • Auch hoch erweiterbar: Es lassen sich gRPC-Services zum Anpassen von Request-, Response- und xDS-Konfiguration schreiben; Plugins können in Lua oder in zu WASM kompilierbaren Sprachen wie Go und Rust erstellt werden
      • Enthält benutzerdefinierte Backend-Ressourcen für externe FQDN- und IP-Ressourcen sowie für UNIX-Sockets für Sidecars
      • Derzeit mit einigen übersprungenen Tests als partially conformant gelistet, erfüllt funktional aber nahezu alle Punkte und integriert sich mit CNCF-Projekten wie KEDA und KNative
      • Wenn man nur ein funktionsreiches API Gateway braucht, ist es eine gute Wahl

    • Istio

      • Ein auf Envoy Proxy basierendes Service Mesh und zugleich ein CNCF-Graduated-Projekt, das in Gateway-API-Tests als conformant gelistet ist
      • Ein Paket, das Ingress Controller, Gateway-API-Controller und Service Mesh umfasst; über die Integration mit agentgateway können Funktionen für LLM-, MCP- und A2A-Gateways bereitgestellt werden
      • Unterstützt fortgeschrittenes Multi-Cluster mit Admiral usw., bietet breite Deployment-Profile, eine große Community und reichlich Material wie O'Reilly-Bücher; pod-zu-pod-Verschlüsselung auf Basis von mTLS ist in Regierungs- und FedRAMP-Umgebungen nützlich
      • Als Nachteil gelten der hohe Ressourcenverbrauch im Sidecar-Modus und die vielen eigenen Konzepte, was zu einer steilen Lernkurve führt
      • Mit Ambient Mode gibt es ein leichtgewichtiges Setup, das in fortgeschrittenen L7-Anwendungsfällen aber möglicherweise nicht so funktionsreich ist wie Sidecars; wenn stärkere Policies und mehr L7-Kontrolle nötig sind, kann man Envoy Gateway zusätzlich als Ingress Gateway und Waypoint Proxy in Betracht ziehen
      • Am besten geeignet, wenn das Service Mesh im Vordergrund steht und Gateway API zweitrangig ist; wenn nur ein API Gateway benötigt wird, kann es etwas unzureichend wirken

    • kgateway

      • Ein Open-Source-Gateway im CNCF-Sandbox-Status auf Basis des Gloo-Projekts; unterstützt Envoy Proxy und agentgateway (für AI-Gateway-Funktionen) als Data Plane und kann eigene extern verwaltete Data-Plane-Instanzen verwenden
      • Mit vollständiger Gateway-API-Conformance nahezu die einzige Implementierung, die fast alle Punkte erfüllt
      • Auf der Envoy-Data-Plane werden JWT-Validierung, OAuth2/OIDC, externe Authentifizierung, IP-Zugriffskontrolle, Envoy Global Rate Limiting und ext_proc-basierte Request-/Response-Verarbeitung bereitgestellt; Lua-/WASM-Plugins oder direkte Rohänderungen an xDS scheinen jedoch nicht offengelegt zu sein
      • Mit der auf MiniJinja-Templates basierenden leistungsfähigen Transformation Engine lassen sich in TrafficPolicy-Ressourcen Header, Response Body und Status deklarativ transformieren
      • Kann mit Istio als Edge Proxy integriert werden, fungiert aber nicht selbst als Service Mesh; unterstützt hierarchische Routes, bei denen eine Route die Traffic-Verarbeitung an eine andere Route delegiert, und besitzt eine benutzerdefinierte AwsLambda-CRD zum direkten Aufruf von AWS Lambda
      • Trotz der Behauptung des Anbieters über breite Deployments gibt es wenig unabhängiges Feedback, daher wirkt das Projekt aus Sicht der öffentlichen Community noch im Wachstum

  • Traefik

    • Ein beliebter Open-Source-Reverse-Proxy, in Go geschrieben, unterstützt sowohl die Ingress API als auch die Gateway API und ist dank hervorragender Dokumentation, aufgeräumter Codebasis, einfacher Konfiguration und leichtem Deployment besonders in der Homelab-Community beliebt

    • Unterstützt die Kernfunktionen der Gateway API sowie einige Zusatzfunktionen, aber ListenerSet und Traffic Mirroring über die Gateway API werden noch nicht unterstützt (Mirroring ist mit einem benutzerdefinierten TraefikService-Backend möglich)

    • Das Erweiterungsmodell basiert auf Middleware; über den ExtensionRef-Filter werden Routes mit Middleware-CRDs verbunden. Zu den integrierten Middleware-Funktionen gehören ForwardAuth (Auslagerung externer Authentifizierung, ähnlich zu Envoy ext_authz), IP-Allowlisting und CORS, Verbindungsbegrenzung, Retry und Circuit Breaker sowie Komprimierung und benutzerdefinierte Fehlerseiten

    • Über Plugin-Middleware lassen sich benutzerdefinierte YAEGI- und WASM-Plugins anbinden (hauptsächlich zur Änderung von Requests und Responses); JWT-Validierung, OIDC und OAuth2 Client Credentials werden nur als kostenpflichtige Plugins angeboten

    • Über die Middleware-CRD wird grundlegendes verteiltes Rate Limiting unterstützt (Buckets nach IP, Host und Header), die Konfiguration ist jedoch nicht sehr flexibel, und da die Anbindung nicht über Policy Attachment, sondern über ExtensionRef erfolgt, sind Hierarchien wie globale Anwendung mit route-spezifischen Overrides schwer umzusetzen

    • Es gibt keine klare Trennung von Control Plane und Data Plane, wodurch die Architektur eher NGINX Ingress ähnelt: Derselbe Pod überwacht Ressourcen und verarbeitet Traffic, pro Gateway werden keine Proxys dynamisch bereitgestellt, und ein einzelnes Deployment verwaltet alle Gateways im überwachten Namespace. Das kann zu einem Single Point of Failure, geringerer Isolation und damit zu Resilienzproblemen im großen Maßstab führen

    • Bei einer Auswahl wird ein Load-Test mit dem zu erwartenden Traffic empfohlen; insbesondere wegen Berichten über Unzufriedenheit mit der Performance von Traefik ist zusätzliche Vorsicht angebracht

    • NGINX Gateway Fabric

      • Die offizielle Gateway-API-Implementierung von F5 auf Basis von NGINX (NGF) bietet solide Conformance und hat in neueren Versionen Unterstützung für Gateway API 1.5 sowie CORS und Änderungen an Request-/Response-Headern über standardisierte HTTPRoute-Filter ergänzt
      • Einige Funktionen wie JWT- und OIDC-Authentifizierung, cookie-basierte Session-Persistenz und Upstream-Updates ohne NGINX-Reload sind weiterhin an NGINX Plus gebunden; dabei handelt es sich jedoch um häufige Anforderungen an API Gateways
      • Über benutzerdefinierte SnippetsPolicy und SnippetsFilter kann auf mehreren Ebenen benutzerdefinierte NGINX-Konfiguration in die erzeugte Config eingefügt werden, was Migrationen erleichtert, ohne umfangreiche Custom-Konfigurationen aus bestehendem NGINX Ingress neu schreiben zu müssen
      • Über eine benutzerdefinierte RateLimitPolicy wird Rate Limiting unterstützt, allerdings als lokales Rate Limiting, sodass der Zustand in der NGINX-Data-Plane liegt. Bei mehreren NGF-Replikaten ändert sich dadurch das effektive Limit je nach Anzahl der Instanzen, was strikte Limits pro Benutzer erschwert
      • NGINX selbst bietet als Erweiterungs-Escape-Hatch leichtgewichtiges JavaScript- und Lua-Scripting, auth_request zur Delegation externer Authentifizierung (ähnlich zu Envoy ext_authz und Traefik ForwardAuth) sowie benutzerdefinierte C-Module; eine ext_proc-artige, externe servicebasierte Änderung von Requests und Responses wird jedoch nicht unterstützt
      • Mit NGF 2.0 wurde die Architektur überarbeitet und eine Trennung von Control Plane und Data Plane sowie Unterstützung für mehrere Gateway-Ressourcen eingeführt; zuvor war die Architektur ein wesentlicher Kritikpunkt

    • Cilium Service Mesh

      • Viele Cluster verwenden Cilium als CNI; das eBPF-basierte, sidecar-lose Service Mesh enthält auch eine Gateway-API-Implementierung auf Basis von Envoy Proxy, wodurch sich Komponenten reduzieren und der Technologie-Stack schlanker halten lässt
      • Der Fokus liegt jedoch hauptsächlich auf Gateway-API-Conformance, und nützliche Envoy-Funktionen außerhalb der Gateway API werden nicht als erstklassige Konfigurationsoptionen bereitgestellt; es fehlt etwa an erstklassiger Unterstützung für Envoy-Erweiterungen und -Plugins, IP-Allowlisting, JWT-Validierung, claim-basierte Autorisierung und OIDC
      • Sofern nicht sicher ist, dass die aktuellen Gateway-API-Funktionen von Cilium ausreichen, wird es nicht als allgemeines API Gateway gegenüber funktionsreicheren Optionen wie Envoy Gateway, kgateway oder Istio empfohlen

    • Kong

      • Ein beliebtes API Gateway auf Basis von NGINX; der Kong Operator unterstützt sowohl Ingress als auch Gateway API
      • Die Hauptsorge betrifft die OSS-Strategie: Offenbar wurde die Veröffentlichung vorkompilierter Docker-Images für neue Open-Source-Gateway-Versionen eingestellt, und die OSS-Images scheinen etwa bei der Release-Linie 3.10 stehen geblieben zu sein, sodass eigenes Bauen, Patchen, Härten und Warten erforderlich werden könnte
      • Es gibt öffentliche Spekulationen, dass diese Maßnahme mit dem Ziel zusammenhängt, die Abwanderung von Enterprise-Kunden zu verringern; das ist jedoch nicht als gesicherte Tatsache zu verstehen, lässt die OSS-Ausrichtung aber weniger vorhersehbar erscheinen
      • Daher wird es nicht empfohlen, sofern man nicht eine Enterprise-Lizenz erwerben oder OSS-Paketierung und -Wartung selbst übernehmen will

Summary

  • Verfolgt die Entwicklung der Kubernetes-Ingress-Muster von den Anfängen bis in das Zeitalter der Gateway API und behandelt das Gateway-API-Protokoll selbst im Detail
  • GAMMA (Erweiterung der Gateway-API-Ideen auf Service Mesh) und Inference Extension (Definition und Optimierung von Kubernetes-Inferenz-Workloads) sind bewusst aus dem Umfang ausgenommen und Themen für eine separate vertiefte Betrachtung
  • Betrachtet außerdem verfügbare Gateway-API-Implementierungen und Kriterien für ihre Auswahl

Verwandte Beiträge

2 Kommentare

 
click 1 시간 전

Ich erinnere mich, dass ich letztes Jahr versucht habe, NGF zu nutzen, dann aber zu envoy gewechselt bin, weil es keine Möglichkeit gab, eine auf dem Authorization-Header basierende Authentifizierung zu bauen.
Ich bevorzuge nginx gegenüber envoy, daher denke ich, dass ich beim nächsten Mal NGF ausprobieren werde, wenn die vollständige Unterstützung der Gateway API da ist.
 
hmmhmmhm 2 시간 전

Dann wird Envoy wohl noch gefragter werden.