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 stehen sowohl für die NGINX Open Source- als auch für die NGINX Plus-basierten Versionen des NGINX Ingress Controllers zur Verfügung. Sie bieten einen nativen, typsicheren und klar strukturierten Konfigurationsstil, der Ihnen die Umsetzung von Ingress-Lastausgleich deutlich erleichtert. In diesem Blog stellen wir zwei Funktionen vor, die mit NGINX Ingress Controller 1.11.0 eingeführt wurden und Ihnen die Konfiguration von WAF- und Lastausgleichsrichtlinien vereinfachen:

• TransportServer-Ressource – Die TransportServer-Ressource legt die Systemkonfiguration für das Load Balancing von TCP-, UDP- und TLS-Passthrough fest. Wir haben Gesundheitsprüfungen, Statusmeldungen und Konfigurationsausschnitte hinzugefügt, um den TCP/UDP-Lastenausgleich wirkungsvoller zu gestalten.
• NGINX Ingress WAF-Richtlinie – Wenn Sie NGINX App Protect 3.0 zusammen mit dem NGINX Ingress Controller einsetzen, können Sie NGINX Ingress-Ressourcen nutzen, um WAF-Richtlinien gezielt auf bestimmte Kubernetes-Services anzuwenden.

Verbesserungen bei der TransportServer-Ressource

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

• Ausschnitte
• Gesundheitschecks
• Unterstützt mehrere TS-Ressourcen

Hinweis: Die Ergänzungen der TransportServer-Ressource in Version 1.11.0 befinden sich als Technologievorschau in aktiver Entwicklung. Wir werden sie in einer zukünftigen Version auf einen stabilen und produktionsreifen Qualitätsstandard bringen.

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 für HTTP-basierte Clients flexibel erweitern können. Mit Version 1.11.0 erweitern wir dieses Angebot um Snippets für TS-Ressourcen, sodass Sie die umfassenden Funktionen von NGINX und NGINX Plus nutzen, um TCP/UDP-basierte Dienste effizient bereitzustellen. Sie können beispielsweise Snippets einsetzen, um über IP-Adressen und Bereiche zu definieren, welche Clients über deny- und allow-Anweisungen Zugriff auf einen Dienst erhalten

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 sind sehr nützlich, um Stromkreise zu unterbrechen und Anwendungsausfälle zu steuern. Sie können die Integritätsprüfung über Parameter im healthCheck-Feld der TS-Ressource anpassen, die das Prüfintervall, das Zeitlimit, Verzögerungen zwischen den Prüfungen und weitere Einstellungen 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.

Mehrere TransportServer-Ressourcen mit ingressClassName unterstützen

Wenn Sie eine TS-Ressource aktualisieren und anwenden, sollten Sie prüfen, ob die Konfiguration gültig ist und erfolgreich bei der jeweiligen Ingress Controller-Bereitstellung aktiviert wurde. Release 1.11.0 führt das ingressClassName-Feld sowie eine Statusberichterstattung für die TS-Ressource ein. Das ingressClassName-Feld sorgt dafür, dass die TS-Ressource in Umgebungen mit mehreren Bereitstellungen von einer spezifischen 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 zeigt den Zustand (Valid oder Invalid), den Grund für die letzte Aktualisierung und bei einem einzelnen TS eine individuelle 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 oder Listener konkurrieren, wählt der NGINX Ingress Controller die TS-Ressource mit dem ältesten Zeitstempel aus und stellt so ein verlässliches Ergebnis sicher.

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

NGINX Ingress-Ressourcen erleichtern die Konfiguration und machen sie flexibler. Sie ermöglichen es Ihnen außerdem, die Verkehrssteuerung an verschiedene Teams zu delegieren und strengere privilegierte Einschränkungen für Benutzer durchzusetzen, die Anwendungsubrouten besitzen, wie in VirtualServerRoute (VSR)-Ressourcen definiert. Indem Sie den passenden Teams Zugriff auf die entsprechenden Kubernetes-Ressourcen geben, schaffen Sie mit NGINX Ingress-Ressourcen eine granulare Kontrolle über Netzwerkressourcen und begrenzen potenzielle Schäden an Anwendungen, wenn Benutzer kompromittiert oder gehackt werden.

Version 1.11.0 führt ein natives Web Application Firewall (WAF) Policy-Objekt ein, mit dem Sie die Vorteile der Konfiguration von NGINX App Protect in Ihren Kubernetes-Bereitstellungen erweitern. Die Policy nutzt die APLogConf- und APPolicy-Objekte, die in Version 1.8.0 eingeführt wurden, und Sie können sie sowohl VirtualServer- (VS) als auch VSR-Ressourcen zuweisen. So können Sie als Sicherheitsadministrator die vollständige Kontrolle über die Ingress-Konfiguration mit VS-Ressourcen behalten und gleichzeitig Sicherheitsaufgaben durch Verweise auf VSR-Ressourcen anderen Teams übertragen.

Im folgenden Beispiel wenden wir die waf-prod-Richtlinie auf Benutzer an, die zum Upstream webapp-prod weitergeleitet werden. Um die Sicherheitsverantwortung für die /v2-Route über Namespaces, die von verschiedenen Teams verwaltet werden, zu übertragen, verweist die hervorgehobene Route-Anweisung 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 mit VSR-Ressourcen in diesem Namespace ihre eigenen Parameter und WAF-Richtlinien bestimmen.

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 Namespace test an. Es zeigt, wie Sie durch die Zuordnung von Ressourcen an verschiedene Teams und deren Kapselung in Objekten neue Funktionen testen können, ohne produktive Anwendungen 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 :

Ist der Wert der Annotation ungültig, wenn Sie die Ingress-Ressource anwenden, lehnt der Ingress-Controller die Ressource ab und entfernt die dazugehörige 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?“ .