Verbesserter TCP/UDP-Load-Balancing und WAF-Konfiguration mit NGINX Ingress Controller

Während die standardmäßige Kubernetes-Ingress-Ressource sich hervorragend für die Bereitstellung und Konfiguration eines grundlegenden Ingress-Lastausgleichs eignet, enthält sie nicht die Art von Anpassungsfunktionen, die erforderlich sind, um Kubernetes produktionsreif zu machen. Stattdessen müssen Nicht-NGINX-Benutzer Anmerkungen, ConfigMaps und benutzerdefinierte Vorlagen verwenden, die fehleranfällig, schwierig zu verwenden und nicht sicher sind und denen eine feinkörnige Bereichsabgrenzung fehlt. NGINX-Ingress-Ressourcen sind unsere Antwort auf dieses Problem.

NGINX Ingress-Ressourcen sind sowohl für die NGINX Open Source- als auch für die NGINX Plus-basierte Version von NGINX Ingress Controller verfügbar. Sie bieten einen nativen, typsicheren und eingerückten Konfigurationsstil, der die Implementierung des Ingress-Lastausgleichs vereinfacht. In diesem Blog konzentrieren wir uns auf zwei in NGINX Ingress Controller 1.11.0 eingeführte Funktionen, die die Konfiguration von WAF- und Lastausgleichsrichtlinien erleichtern:

• TransportServer-Ressource – Die TransportServer-Ressource definiert die Konfiguration für den Lastenausgleich von TCP, UDP und TLS-Passthrough. Wir haben Integritätsprüfungen, Statusberichte und Konfigurationsausschnitte hinzugefügt, um den TCP/UDP-Lastausgleich zu verbessern.
• NGINX Ingress WAF-Richtlinie – Wenn Sie NGINX App Protect 3.0 mit NGINX Ingress Controller bereitstellen, können Sie NGINX Ingress-Ressourcen nutzen, um WAF-Richtlinien auf bestimmte Kubernetes-Dienste anzuwenden.

Verbesserungen an der TransportServer-Ressource

NGINX Ingress Controller 1.11.0 erweitert die TransportServer (TS)-Ressource in den folgenden Bereichen:

• Ausschnitte
• Gesundheitschecks
• Unterstützung für mehrere TS-Ressourcen

Notiz: Die Ergänzungen zur TransportServer-Ressource in Version 1.11.0 sind eine Technologievorschau, die aktiv entwickelt wird. Sie werden in einer zukünftigen Version auf einen stabilen, produktionsreifen Qualitätsstandard gebracht.

TransportServer-Ausschnitte

Im NGINX Ingress Controller haben wir Konfigurationsausschnitte für die Ressourcen VirtualServer und VirtualServerRoute (VS und VSR) eingeführt, mit denen Sie NGINX Ingress-Konfigurationen nativ für HTTP-basierte Clients erweitern können. Version 1.11.0 führt Snippets für TS-Ressourcen ein, sodass Sie problemlos die gesamte Palette der NGINX- und NGINX Plus-Funktionen nutzen können, um TCP/UDP-basierte Dienste bereitzustellen. Sie können beispielsweise Snippets verwenden, um Deny- und Allow -Anweisungen hinzuzufügen, die IP-Adressen und Bereiche verwenden, um zu definieren, welche Clients auf einen Dienst zugreifen können.

API-Version: k8s.nginx.org/v1alpha1kind: TransportServer
Metadaten:
Name: Café
Spezifikation:
Host: Café.Beispiel.com
Server-Snippets: |
192.168.1.1 verweigern;
192.168.1.0/24 zulassen;
Upstreams:
- Name: Tea
Dienst: Tea-SVC
Port: 80

Gesundheitschecks

Um die Integrität eines Kubernetes-Clusters zu überwachen, berücksichtigt der NGINX Ingress Controller nicht nur Kubernetes-Sonden , die sich lokal in Anwendungs-Pods befinden, sondern überwacht auch den Status des Netzwerks zwischen TCP/UDP-basierten Upstream-Diensten, mit passiven Integritätsprüfungen zur Bewertung der Integrität laufender Transaktionen und aktiven Integritätsprüfungen (exklusiv für NGINX Plus), um Endpunkte regelmäßig mit synthetischen Verbindungsanforderungen zu prüfen.

Integritätsprüfungen können zum Unterbrechen von Stromkreisen und Behandeln von Anwendungsfehlern sehr nützlich sein. Sie können die Integritätsprüfung mithilfe von Parametern im Feld „ healthCheck “ der TS-Ressource anpassen, die das Intervall zwischen den Prüfungen, das Prüfungstimeout, die Verzögerungszeiten zwischen den Prüfungen und mehr festlegen.

Darüber hinaus können Sie den Upstream-Dienst und das Portziel von Integritätsprüfungen vom NGINX Ingress Controller festlegen. Dies ist in Situationen nützlich, in denen der Zustand der Upstream-Anwendung durch einen anderen Prozess oder ein anderes Subsystem, das mehrere Downstream-Komponenten der Anwendung überwacht, auf einem anderen Listener angezeigt wird.

Unterstützung mehrerer TransportServer-Ressourcen mit ingressClassName

Wenn Sie eine TS-Ressource aktualisieren und anwenden, ist es hilfreich zu überprüfen, ob die Konfiguration gültig ist und erfolgreich auf die entsprechende Ingress Controller-Bereitstellung angewendet wurde. Version 1.11.0 führt das Feld „ingressClassName“ und die Statusberichterstattung für die TS-Ressource ein. Das Feld „ingressClassName“ stellt sicher, dass die TS-Ressource in Umgebungen mit mehreren Bereitstellungen von einer bestimmten Ingress Controller-Bereitstellung verarbeitet wird.

Um den Status einer oder aller TS-Ressourcen anzuzeigen, führen Sie den Befehl „kubectl get transportserver“ aus. Die Ausgabe umfasst den Status („ Gültig“ oder „Ungültig“ ), den Grund für die letzte Aktualisierung und (für einen einzelnen TS) eine benutzerdefinierte Nachricht.

$ kubectl get transportserver NAME STATUS GRUND ALTER dns-tcp Gültig HinzugefügtOderAktualisiert 47m $ kubectl describe transportserver dns-tcp . . .
Status:
  Nachricht:  Konfiguration für Standard/DNS-TCP wurde hinzugefügt oder aktualisiert. Grund:   Hinzugefügter oder aktualisierter Status:    Gültig

Wenn mehrere TS-Ressourcen um denselben Host/Listener konkurrieren, wählt der NGINX Ingress Controller die TS-Ressource mit den ältesten Zeitstempeln aus und gewährleistet in dieser Situation ein deterministisches Ergebnis.

Definieren einer WAF-Richtlinie mit nativer NGINX App Protect-Unterstützung

NGINX-Ingress-Ressourcen machen die Konfiguration nicht nur einfacher und flexibler, sie ermöglichen Ihnen auch, die Verkehrskontrolle an verschiedene Teams zu delegieren und strengere Berechtigungsbeschränkungen für Benutzer aufzuerlegen, die Eigentümer von Anwendungsunterrouten sind, wie in den VirtualServerRoute-Ressourcen (VSR) definiert. Indem Sie den richtigen Teams Zugriff auf die richtigen Kubernetes-Ressourcen gewähren, ermöglichen Ihnen NGINX Ingress-Ressourcen eine detaillierte Kontrolle über Netzwerkressourcen und reduzieren potenzielle Schäden an Anwendungen, wenn Benutzer kompromittiert oder gehackt werden.

Version 1.11.0 führt ein natives WAF- Richtlinienobjekt (Web Application Firewall) ein, um diese Vorteile auf die Konfiguration von NGINX App Protect in Ihren Kubernetes-Bereitstellungen auszuweiten. Die Richtlinie nutzt die in Version 1.8.0 eingeführten APLogConf- und APPolicy- Objekte und kann sowohl an VirtualServer- (VS) als auch an VSR-Ressourcen angehängt werden. Dies bedeutet, dass Sicherheitsadministratoren die volle Kontrolle über die Ingress-Konfiguration mit VS-Ressourcen haben und gleichzeitig durch Verweisen auf VSR-Ressourcen Sicherheitsverantwortungen an andere Teams delegieren können.

Im folgenden Beispiel wird die waf-prod -Richtlinie auf Benutzer angewendet, die zum Upstream webapp-prod weitergeleitet werden. Um die Sicherheitsverantwortung für die /v2 -Route zwischen Namespaces zu delegieren, die verschiedenen Teams gehören, verweist die hervorgehobene Routendirektive auf eine VSR-Ressource.

API-Version: k8s.nginx.org/v1kind: VirtualServer-Metadaten: Name: Webapp-Spezifikation: Host: webapp.example.com Richtlinien: - Name: waf-prod TLS: Geheimnis: App-Geheimnis Upstreams: - Name: webapp-prod Dienst: webapp-svc Port: 80 Routen: - Pfad: /v2 Route: Test/Test - Pfad: /v1 Aktion: Pass: Webapp-Prod

Die Teams, die den Test -Namespace verwalten, können mithilfe der VSR-Ressourcen in diesem Namespace ihre eigenen Parameter und WAF-Richtlinien festlegen.

API-Version: k8s.nginx.org/v1kind: VirtualServerRoute
Metadaten:
Name: Test
Namespace: Test
Spezifikation:
Host: webapp.example.com
Upstreams:
-Name: Webapp
Dienst: webapp-test-svc
Port: 80
Unterrouten:
- Pfad: /v2
Richtlinien:
- Name: waf-test
Aktion:
Pass: Webapp

Dieses Beispiel trennt Mandanten nach Namespace und wendet eine andere WAF-Richtlinie für den Dienst „webapp-test-svc“ im Test -Namespace an. Es veranschaulicht, wie das Delegieren von Ressourcen an verschiedene Teams und deren Kapselung mit Objekten das Testen neuer Funktionen vereinfacht, ohne die Anwendungen in der Produktion zu stören.

Was ist sonst noch neu in Version 1.11.0?

Mit NGINX Ingress Controller 1.11.0 setzen wir unser Engagement fort, einen produktionstauglichen Ingress-Controller bereitzustellen, der flexibel, leistungsstark und benutzerfreundlich ist. Zusätzlich zu den WAF- und TS-Verbesserungen enthält Version 1.11.0 die folgenden Erweiterungen:

• Validierung weiterer Annotationen – Vermeidung weiterer Konfigurationsfehler
• Informationen zum Richtlinienstatus – Zeigt den Status von Richtlinienobjekten an, bevor sie auf die Ingress-Konfiguration angewendet werden
• Istio-Kompatibilität – Nutzen Sie die erweiterten Funktionen des NGINX Ingress Controllers in einer Istio-Umgebung
• Cluster‑IP‑Adressen für Upstream‑Endpunkte – Füllen Sie Upstream‑Endpunkte in der NGINX Ingress Controller‑Konfiguration mit Service‑/Cluster‑IP‑Adressen auf.

Validierung weiterer Anmerkungen

Aufbauend auf den Verbesserungen der Annotation-Validierung, die in Version 1.10.0 eingeführt wurden, validieren wir jetzt die folgenden zusätzlichen Annotationen :

Wenn der Wert der Annotation beim Anwenden der Ingress-Ressource ungültig ist, lehnt der Ingress Controller die Ressource ab und entfernt die entsprechende Konfiguration aus NGINX.

Statusinformationen zu Richtlinien

Der Befehl „kubectl get policy“ meldet jetzt den Status der Richtlinie ( Gültig oder Ungültig ) und (für einen einzelnen TS) eine benutzerdefinierte Nachricht und den Grund für die letzte Aktualisierung.

$ kubectl get policy NAME STATE AGE webapp-policy Gültig 30 s $ kubectl describe policy webapp-policy . . .
Status:
  Nachricht:  Konfiguration für Standard-/Webanwendungsrichtlinie wurde hinzugefügt oder aktualisiert. Grund:   Hinzugefügter oder aktualisierter Status:    Gültig

Kompatibilität mit Istio

NGINX Ingress Controller kann jetzt als Ingress-Controller für Apps verwendet werden, die innerhalb eines Istio-Service-Mesh ausgeführt werden. Dadurch können Benutzer die erweiterten Funktionen des NGINX Ingress Controllers in Istio-basierten Umgebungen weiterhin nutzen, ohne auf Workarounds zurückgreifen zu müssen. Diese Integration bringt zwei Anforderungen mit sich:

• Die Einfügung eines Istio-Sidecars in die NGINX Ingress Controller-Bereitstellung
• Es wird nur ein HTTP-Host-Header an das Backend gesendet

Um die erste Anforderung zu erfüllen, fügen Sie die folgenden Elemente in das Anmerkungsfeld Ihrer NGINX Ingress-Bereitstellungsdatei ein.

Anmerkungen: traffic.sidecar.istio.io/includeInboundPorts: "" 
traffic.sidecar.istio.io/excludeInboundPorts: „80.443“ Traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: "wahr"

Die zweite Anforderung wird durch eine Änderung des Verhaltens des Felds requestHeaders erreicht. In früheren Versionen wurden mit der folgenden Konfiguration zwei Host- Header an das Backend gesendet: $host und der angegebene Wert bar.example.com .

API-Version: k8s.nginx.org/v1kind: VirtualServer-Metadaten: Name: foo Spezifikation: Host: foo.example.com Upstreams: - Name: foo Port: 8080 Dienst: Backend-SVC Use-Cluster-IP: True Routen: - Pfad: "/" Aktion: Proxy: Upstream: foo RequestHeaders: Set: - Name: Hostwert: bar.example.com

Ab Version 1.11.0 wird nur der angegebene Wert gesendet. Um $host zu senden, lassen Sie das Feld „requestHeaders“ vollständig weg.

Cluster-IP-Adressen für Upstream-Endpunkte

Die Upstream-Endpunkte in der NGINX Ingress Controller-Konfiguration können jetzt mit Service-/Cluster-IP-Adressen statt mit den einzelnen IP-Adressen von Pod-Endpunkten gefüllt werden. Um NGINX Ingress Controller zu aktivieren, den Datenverkehr an Cluster‑IP‑Dienste weiterzuleiten, fügen Sie das Feld use-cluster-ip: true in den Upstreams- Abschnitt Ihrer VS‑ oder VSR‑Konfiguration ein:

Upstreams: - Name: TEA-Dienst: TEA-SVC-Port: 80 use-cluster-ip: true - Name: Kaffeedienst: Kaffee-SVC-Port: 80 use-cluster-ip: wahr

Ressourcen

Das vollständige Änderungsprotokoll für Version 1.11.0 finden Sie in den Versionshinweisen .

Um NGINX Ingress Controller für Kubernetes mit NGINX Plus und NGINX App Protect auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .

Um NGINX Ingress Controller mit NGINX Open Source auszuprobieren, können Sie den Quellcode der Version erhalten oder einen vorgefertigten Container von DockerHub herunterladen.

Eine Erörterung der Unterschiede zwischen Ingress-Controllern finden Sie in unserem Blog unter „Moment, welchen NGINX-Ingress-Controller für Kubernetes verwende ich?“ .