Verbesserter TCP/UDP-Lastenausgleich und optimierte WAF-Konfiguration mit dem NGINX Ingress Controller

Amir RawdatLösungsingenieur

Die standardmäßige Kubernetes-Ingress-Ressource eignet sich zwar hervorragend für die Bereitstellung und Konfiguration eines grundlegenden Ingress-Lastausgleichs, bietet jedoch nicht die Anpassungsfunktionen, die erforderlich sind, um Kubernetes produktionsreif zu machen. Benutzer, die NGINX nicht verwenden, müssen daher auf Annotationen, ConfigMaps und benutzerdefinierte Vorlagen zurückgreifen. Diese sind fehleranfällig, schwierig zu verwenden und unsicher und bieten keine fein abgestufte Bereichsabgrenzung. NGINX-Ingress-Ressourcen sind unsere Lösung für dieses Problem.

NGINX Ingress-Ressourcen sind sowohl für die auf NGINX Open Source als auch für die auf NGINX Plus basierenden Versionen des NGINX Ingress Controllers verfügbar. Sie bieten einen nativen, typsicheren und eingerückten Konfigurationsstil, der die Implementierung des Ingress-Load-Balancings vereinfacht. In diesem Blog konzentrieren wir uns auf zwei mit NGINX Ingress Controller 1.11.0 eingeführte Funktionen, die die Konfiguration von WAF- und Load-Balancing-Richtlinien 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 Konfigurations-Snippets hinzugefügt, um den TCP/UDP-Lastenausgleich zu verbessern.
• NGINX Ingress-WAF-Richtlinie – Wenn Sie NGINX App Protect 3.0 mit dem 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 Ressource „TransportServer“ (TS) in den folgenden Bereichen:

• Snippets
• Integritätsprüfungen
• Unterstützung für mehrere TS-Ressourcen

Hinweis: Die Erweiterungen der TransportServer-Ressource in Version 1.11.0 sind eine aktiv weiterentwickelte Technologievorschau. In einer zukünftigen Version werden sie einen stabilen, produktionsreifen Qualitätsstandard erreichen.

TransportServer-Snippets

Im NGINX Ingress Controller haben wir Konfigurations-Snippets für die Ressourcen VirtualServer und VirtualServerRoute (VS und VSR) eingeführt, mit denen Sie NGINX-Ingress-Konfigurationen für HTTP-basierte Clients nativ erweitern können. Mit Version 1.11.0 werden Snippets für TS-Ressourcen eingeführt, sodass Sie den gesamten Funktionsumfang von NGINX und NGINX Plus problemlos für die Bereitstellung TCP/UDP-basierter Dienste nutzen können. Beispielsweise können Sie mithilfe von Snippets die Direktiven deny und allow hinzufügen, die anhand von IP-Adressen und Adressbereichen festlegen, welche Clients auf einen Dienst zugreifen dürfen.

apiVersion: k8s.nginx.org/v1alpha1kind: TransportServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  serverSnippets: |
    deny  192.168.1.1;
    allow 192.168.1.0/24;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80

Integritätsprüfungen

Zur Überwachung des Zustands eines Kubernetes-Clusters berücksichtigt der NGINX Ingress Controller nicht nur Kubernetes-Probes in den jeweiligen Anwendungs-Pods, sondern überwacht auch den Netzwerkstatus zwischen TCP/UDP-basierten Upstream-Diensten. Dabei beurteilen passive Zustandsprüfungen den Zustand laufender Transaktionen, während aktive Zustandsprüfungen (exklusiv in NGINX Plus) Endpunkte regelmäßig mit synthetischen Verbindungsanfragen testen.

Integritätsprüfungen können sehr nützlich für Circuit Breaking und die Behandlung von Anwendungsfehlern sein. Sie können die Integritätsprüfung mithilfe der Parameter im Feld „healthCheck“ der TS-Ressource anpassen. Damit lassen sich unter anderem das Intervall zwischen den Prüfungen, das Zeitlimit einer Prüfung und die Verzögerungszeiten zwischen den Prüfungen festlegen.

Darüber hinaus können Sie den Upstream-Dienst und den Zielport für Zustandsprüfungen des NGINX Ingress Controllers festlegen. Dies ist hilfreich, wenn der Zustand der Upstream-Anwendung über einen anderen Listener durch einen anderen Prozess oder ein anderes Subsystem bereitgestellt wird, der bzw. das mehrere nachgelagerte Komponenten der Anwendung überwacht.

Unterstützung mehrerer TransportServer-Ressourcen mit ingressClassName

Wenn Sie eine TS-Ressource aktualisieren und anwenden, sollten Sie ü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“ sowie 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 enthält den Status („Valid“ oder „Invalid“), den Grund für die letzte Aktualisierung und (bei einer einzelnen TS-Ressource) eine benutzerdefinierte Meldung.

$ kubectl get transportserver  NAME      STATE   REASON           AGE
  dns-tcp   Valid   AddedOrUpdated   47m

$ kubectl describe transportserver dns-tcp
. . .
Status:
  Message:  Configuration for default/dns-tcp was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

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

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

NGINX-Ingress-Ressourcen vereinfachen und flexibilisieren nicht nur die Konfiguration, sondern ermöglichen es Ihnen auch, die Datenverkehrssteuerung an verschiedene Teams zu delegieren und strengere Berechtigungsbeschränkungen für Benutzer durchzusetzen, die für Anwendungsunterrouten verantwortlich sind, wie sie in VirtualServerRoute-Ressourcen (VSR) definiert sind. Indem Sie den richtigen Teams Zugriff auf die entsprechenden Kubernetes-Ressourcen gewähren, ermöglichen Ihnen NGINX-Ingress-Ressourcen eine präzise Kontrolle über Netzwerkressourcen und verringern potenzielle Schäden an Anwendungen, falls Benutzerkonten kompromittiert oder gehackt werden.

Version 1.11.0 führt eine native Web Application Firewall (WAF) ein, deren Policy-Objekt diese Vorteile auf die Konfiguration von NGINX App Protect in Ihren Kubernetes-Bereitstellungen ausweitet. Die Richtlinie nutzt die Objekte APLogConf und APPolicy, die mit Version 1.8.0 eingeführt wurden, und kann sowohl VirtualServer- (VS) als auch VSR-Ressourcen zugeordnet werden. Das bedeutet, dass Sicherheitsadministratoren mit VS-Ressourcen die Verantwortung für die gesamte Ingress-Konfiguration übernehmen und gleichzeitig Sicherheitsaufgaben durch Verweise auf VSR-Ressourcen an andere Teams delegieren können.

Im folgenden Beispiel wird die Richtlinie „waf-prod“ auf Benutzer angewendet, die an den Upstream „webapp-prod“ weitergeleitet werden. Um die Sicherheitsverantwortung für die Route „/v2“ über Namespaces hinweg zu delegieren, die verschiedenen Teams gehören, verweist die hervorgehobene Direktive „route“ auf eine VSR-Ressource.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: waf-prod 
  tls:
    secret: app-secret
  upstreams:
  - name: webapp-prod
    service: webapp-svc
    port: 80
  routes:
  - path: /v2
    route: test/test
  - path: /v1
    action:
      pass: webapp-prod

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

apiVersion: k8s.nginx.org/v1kind: VirtualServerRoute
metadata:
  name: test 
  namespace: test
spec:
  host: webapp.example.com
  upstreams:
  - name: webapp 
    service: webapp-test-svc
    port: 80
  subroutes:
  - path: /v2
    policies:
    - name: waf-test
    action:
      pass: webapp

In diesem Beispiel werden Mandanten nach Namespace getrennt und eine andere WAF-Richtlinie auf den Dienst „webapp-test-svc“ im Namespace „test“ angewendet. Es veranschaulicht, wie die Delegierung von Ressourcen an verschiedene Teams und deren Kapselung mithilfe von Objekten das Testen neuer Funktionen vereinfacht, ohne Anwendungen in der Produktionsumgebung zu beeinträchtigen.

Was ist sonst noch neu in Version 1.11.0?

Mit NGINX Ingress Controller 1.11.0 setzen wir unser Engagement für die Bereitstellung eines produktionsreifen Ingress-Controllers fort, der flexibel, leistungsstark und benutzerfreundlich ist. Neben Verbesserungen an WAF und TS umfasst Version 1.11.0 die folgenden Neuerungen:

• Validierung weiterer Annotationen – Vermeidung weiterer Konfigurationsfehler
• Richtlinienstatusinformationen – Zeigt den Status von Policy-Objekten 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 – Upstream-Endpunkte in der Konfiguration des NGINX Ingress Controllers mit Service-/Cluster-IP-Adressen befüllen

Validierung weiterer Annotationen

Aufbauend auf den in Version 1.10.0 eingeführten Verbesserungen bei der Validierung von Annotationen validieren wir nun die folgenden zusätzlichen Annotationen:

Validierung der Annotationennginx.org/client-max-body-size Muss ein gültiger Offset seinnginx.org/fail-timeout Muss eine gültige Zeitangabe seinnginx.org/max-conns Muss eine gültige nicht negative Ganzzahl seinnginx.org/max-fails Muss eine gültige nicht negative Ganzzahl seinnginx.org/proxy-buffer-size Muss eine gültige Größenangabe seinnginx.org/proxy-buffers Muss eine gültige Proxy-Pufferspezifikation seinnginx.org/proxy-connect-timeout Muss eine gültige Zeitangabe seinnginx.org/proxy-max-temp-file-size Muss eine gültige Größenangabe seinnginx.org/proxy-read-timeout Muss eine gültige Zeitangabe seinnginx.org/proxy-send-timeout Muss eine gültige Zeitangabe seinnginx.org/upstream-zone-size Muss eine gültige Größenangabe sein

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“ gibt jetzt den Status der Richtlinie (Valid oder Invalid) sowie (für einen einzelnen TS) eine benutzerdefinierte Meldung und den Grund für die letzte Aktualisierung aus.

$ kubectl get policy  NAME              STATE   AGE
  webapp-policy     Valid   30s

$ kubectl describe policy webapp-policy
. . .
Status:
  Message:  Configuration for default/webapp-policy was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

Kompatibilität mit Istio

NGINX Ingress Controller kann jetzt als Ingress-Controller für Anwendungen verwendet werden, die innerhalb eines Istio-Service-Mesh ausgeführt werden. Dadurch können Benutzer die erweiterten Funktionen von NGINX Ingress Controller auch in Istio-basierten Umgebungen weiterhin nutzen, ohne auf Behelfslösungen zurückgreifen zu müssen. Für diese Integration gelten zwei Voraussetzungen:

• Die Einbindung eines Istio-Sidecars in die Bereitstellung des NGINX Ingress Controllers
• Es wird nur ein HTTP-Host-Header an das Backend gesendet

Um die erste Anforderung zu erfüllen, fügen Sie die folgenden Einträge in das Feld „annotations“ Ihrer NGINX-Ingress-Deployment-Datei ein.

annotations:   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: 'true'

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

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: foo 
spec:
  host: foo.example.com
  upstreams:
  - name: foo
    port: 8080
    service: backend-svc
    use-cluster-ip: true
  routes:
  - path: "/"
    action:
      proxy:
        upstream: foo
        requestHeaders: set: - name: Host value: 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 Konfiguration des NGINX Ingress Controllers können jetzt anstelle der einzelnen IP-Adressen von Pod-Endpunkten mit Service-/Cluster-IP-Adressen befüllt werden. Damit der NGINX Ingress Controller Datenverkehr an Cluster-IP-Services weiterleiten kann, fügen Sie das Feld use-cluster-ip: true im Abschnitt upstreams Ihrer VS- oder VSR-Konfiguration hinzu:

upstreams:  - name: tea
    service: tea-svc
    port: 80
    use-cluster-ip: true
  - name: coffee
    service: coffee-svc
    port: 80
    use-cluster-ip: true

Ressourcen

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

Wenn Sie den NGINX Ingress Controller für Kubernetes mit NGINX Plus und NGINX App Protect testen möchten, 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 beziehen oder ein vorgefertigtes Container-Image von DockerHub herunterladen.

Eine Erläuterung der Unterschiede zwischen Ingress-Controllern finden Sie in unserem Blogbeitrag „Moment mal, welchen NGINX Ingress Controller für Kubernetes verwende ich?“.

Über den Autor

Amir RawdatLösungsingenieur

Weitere Blogbeiträge von Amir Rawdat