Ankündigung von NGINX Plus R23

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 23 (R23) bekannt zu geben. NGINX Plus basiert auf NGINX Open Source und ist der einzige Software-Load Balancer, Reverse Proxy und API-Gateway.

Zu den neuen Funktionen in NGINX Plus R23 gehören:

• gRPC-Integritätsprüfungen – Durch aktives Testen, ob ein gRPC-Dienst Anfragen verarbeiten kann, bevor diese gesendet werden, wird die Zuverlässigkeit erheblich gesteigert.
• Unterstützung für nicht privilegierte Installationen – NGINX Plus kann jetzt von einem nicht privilegierten (Nicht- Root- )Benutzer installiert und aktualisiert werden. Diese vollständig unterstützte Lösung entspricht dem wachsenden Trend zu Zero-Trust-Sicherheitsmodellen.
• OpenID Connect PKCE-Unterstützung – NGINX Plus R23 implementiert die Proof Key for Code Exchange (PKCE)-Erweiterung für den OpenID Connect-Autorisierungscode-Flow. PKCE verhindert verschiedene Arten von Angriffen und ermöglicht sicheren OAuth-Austausch mit öffentlichen Clients.

Abgerundet wird diese Version durch eine feinere Kontrolle über SSL/TLS, eine native Methode zum Setzen von Cookie-Flags und Variableneinstellungen im Stream-Modul. Zu den Updates des NGINX Plus-Ökosystems gehören die neuen Buffer- und Query String-Module für das NGINX JavaScript-Modul, das neue dynamische SPNEGO-Modul für Kerberos und Verbesserungen am dynamischen Prometheus-njs-Modul.

Wichtige Verhaltensänderungen

• Veraltetes Modul – Das Cookie-Flag-Modul von Drittanbietern ist veraltet und wird durch die neue Direktive proxy_cookie_flags ersetzt. Das Modul wird in NGINX Plus R26 entfernt. Einzelheiten finden Sie unter Native Methode zum Setzen von Cookie-Flags .
• Neue unterstützte Betriebssysteme :
  • Alpine 3.12 (x86_64, aarch64)
  • Debian 10 (aarch64; x86_64 wird seit NGINX Plus R17 unterstützt)
• Ältere Betriebssysteme wurden entfernt oder sollen entfernt werden:
  • Alpine 3.9 wird nicht mehr unterstützt; die älteste unterstützte Version ist 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ wird nicht mehr unterstützt; die älteste unterstützte Version ist 7.4
  • Ubuntu 19.10 wird nicht mehr unterstützt
  • Debian 9 wird in NGINX Plus R24 entfernt

Neue Features im Detail

gRPC-Integritätsprüfungen

Beim Einsatz als Lastenausgleich kann NGINX Plus den Zustand von Backend-Servern (Upstream-Servern) durch aktive Integritätsprüfungen überwachen. NGINX Plus R23 unterstützt das gRPC-Integritätsprüfungsprotokoll und ermöglicht damit genaue Tests, ob die gRPC-Backend-Server in der Lage sind, neue Anfragen zu verarbeiten. Dies ist besonders in dynamischen und containerisierten Umgebungen wertvoll. Beim Hochfahren neuer Instanzen eines gRPC-Dienstes ist es wichtig, Anfragen erst zu senden, wenn der Dienst „vollständig aktiv“ ist. Dazu ist eine Integritätsprüfung erforderlich, die tiefer geht als die Betrachtung des TCP-Ports oder die Überprüfung der HTTP-URI-Verfügbarkeit – eine Prüfung, bei der der Dienst selbst anzeigt, ob er zum Empfangen von Anfragen bereit ist.

Für gRPC-Dienste, die das gRPC-Integritätsprüfungsprotokoll implementieren, ist die Konfiguration unkompliziert.

Diese Konfiguration gleicht die Last aller Anforderungen an die Upstream-Gruppe grpc_backend aus. Die Direktive health_check enthält den Parameter type=grpc, um die Check- Methode des Health- Dienstes jedes Upstream-Servers aufzurufen. Dienste, die mit SERVING antworten, gelten als fehlerfrei. Der obligatorische Parameter stellt sicher, dass beim Start von NGINX Plus oder beim Einführen eines neuen Servers in die Upstream-Gruppe der Datenverkehr erst weitergeleitet wird, wenn eine Integritätsprüfung erfolgreich war (andernfalls wird standardmäßig davon ausgegangen, dass neue Dienste fehlerfrei sind).

Wenn auf jedem Upstream-Server mehrere gRPC-Dienste verfügbar sind, kann der wichtigste Dienst (einer mit abhängigen oder untergeordneten Diensten) überwacht werden, indem sein Name als Wert für den Parameter grpc_service angegeben wird, wie in diesem Beispiel:

Bei gRPC-Diensten, die das gRPC-Integritätsprüfungsprotokoll nicht implementieren, können wir testen, ob der Upstream-Server zumindest auf gRPC-Anfragen antwortet, da er in diesem Fall als Antwort auf die Check -Methode einen Fehlerstatuscode sendet. Mit der Konfiguration in grpc_health.conf erwarten wir, dass ein Dienst, der das gRPC-Protokoll nicht implementiert, mit dem Statuscode antwortet 12(NICHT IMPLEMENTIERT) .

Wir können auch überprüfen, ob ein gRPC-Dienst auf eingehende Anfragen reagieren kann, ohne dass der Backend-Code geändert werden muss. Mit diesem Ansatz können wir jeden gRPC-Dienst überwachen:

Installation durch nicht privilegierte Benutzer

In früheren Versionen lief NGINX Plus mit einem Minimum an Prozessen, die als privilegierter Benutzer root ausgeführt wurden. Die Installationsanweisungen im NGINX Plus Admin Guide erstellen beispielsweise diese Prozesse:

grep nginx root ...  9068 888 ?  Ss 21:44 0:00 nginx: Masterprozess nginx nginx ...  9712 3572 ?  S 21:44 0:00 \_ nginx: Arbeitsprozess

Wie gezeigt wird der Masterprozess mit Root -Rechten ausgeführt. Alle anderen Prozesse (Worker und Cache-Verwaltung) verwenden das nicht privilegierte Benutzerkonto nginx .

Kritische Systeme, die mit sensiblen Daten umgehen, möchten möglicherweise nicht den Benutzer root verwenden. In diesem Fall kann NGINX Plus R23 als nicht privilegierter Benutzer installiert und ausgeführt werden. Wir stellen in unserem GitHub-Repository ein Installationsskript, ngxunprivinst.sh , zur Verwendung auf den folgenden Betriebssystemen bereit:

• Alpine Linux
• Amazon Linux, Amazon Linux 2
• CentOS, Red Hat Enterprise Linux
• Debian, Ubuntu

Notiz: Wenn NGINX Plus- Listener auf Ports unter 1024 (z. B. 80 oder 443) konfiguriert sind, muss der Masterprozess über Root -Berechtigungen verfügen (Sie können NGINX Plus jedoch trotzdem unter einem nicht privilegierten Benutzerkonto installieren).

Um das Installationsskript zu verwenden, führen Sie die folgenden Befehle aus. (Um alle verfügbaren ngxunprivinst.sh- Befehle anzuzeigen, führen Sie das Skript ohne Befehlsnamenparameter aus oder sehen Sie sich den Code für das Skript im GitHub-Repository an.)

1. Laden Sie das Skript herunter und stellen Sie sicher, dass es ausführbar ist:

   $ chmod +x ngxunprivinst.sh

2. Kopieren Sie Ihr NGINX Plus-Zertifikat und Ihren Schlüssel ( nginx-repo.crt und nginx-repo.key ) in das lokale Verzeichnis. Die Optionen -c und -k sind in allen ngxunprivinst.sh- Befehlen enthalten, um sie zu identifizieren.

3. Listen Sie die im NGINX Plus-Repo verfügbaren Versionen von NGINX Plus auf.

   $ ./ngxunprivinst.sh Liste -c nginx-repo.crt -k nginx-repo.key
   18-1
   18-2
   19-1
   20-1
   21-1
   22-1
   23-1

4. Holen Sie sich das gewünschte Paket (hier holen wir NGINX Plus R23-1 ). Die Option -p gibt das Installationsverzeichnis an:

   $ ./ngxunprivinst.sh fetch -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23-1

5. Installieren Sie die Pakete, die Sie benötigen (hier installieren wir NGINX Plus und das NGINX JavaScript Module, njs).

   $ ./ngxunprivinst.sh installiere -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23.1 nginx-plus-23-1.el8.ngx.x86_64.rpm nginx-plus-module-njs-23%2B0.4.6-1.el8.ngx.x86_64.rpm

6. Starten Sie NGINX, und geben Sie mit der Option „-p“ den Pfad an, mit „-c“ die Konfigurationsdatei benennen und mit „-e“ das Fehlerprotokoll benennen.

   $ /home/nginxrun/usr/sbin/nginx -p /home/nginxrun/etc/nginx -c nginx.conf -e /home/nginxrun/var/log/error.log

   Wir schließen die Option -e ein , um die Warnmeldung zu unterdrücken, die andernfalls erscheint. Bevor NGINX Plus beim Start seine Konfiguration gelesen hat, schreibt es in das Standardfehlerprotokoll /var/log/nginx/error.log . Nicht privilegierte Benutzer haben keine Berechtigung zum Erstellen oder Schreiben in diese Datei, was zu einer Warnung führt. Sobald die Konfiguration gelesen wurde, legt die Direktive error_log das Fehlerprotokoll an einem Speicherort fest, in den der nicht privilegierte Benutzer schreiben kann.

7. (Optional) Um zu überprüfen, ob NGINX Plus als Nicht- Root- Benutzer ausgeführt wird, führen Sie diesen Befehl aus:

   $ ps auxf | grep nginx nginxrun …  9068 888 ?  Ss 21:55 0:00 nginx: Masterprozess nginxrun ...  9712 3572 ?  S 21:55 0:00 \_ nginx: Arbeitsprozess

OpenID Connect PKCE-Unterstützung

Proof Key for Code Exchange ( PKCE ) ist eine Erweiterung, die kürzlich zum Autorisierungscode-Flow von OpenID Connect (OIDC) hinzugefügt wurde, um verschiedene Arten von Angriffen zu verhindern und den OAuth-Austausch mit öffentlichen Clients zu sichern. Für NGINX Plus R23 haben wir unsere OpenID Connect-Referenzimplementierung aktualisiert, um die Erweiterung zu unterstützen. PKCE wird mit OAuth 2.1 obligatorisch.

Die konkrete Änderung besteht darin, client_secret in der Code-Challenge durch zwei neue Werte zu ersetzen:

• Code-Herausforderung
• Code-Verifizierer

Um verschiedenen Angriffen, insbesondere auf Mobilgeräten, entgegenzuwirken, wurde die Anforderung für ein Token (egal, ob es sich um ein Access-, ID- oder Refresh-Token handelt) wie folgt angepasst:

1. NGINX Plus generiert (und merkt sich) einen Code_Verifier .
2. NGINX Plus leitet den Endbenutzer zur Anmeldung auf der Anmeldeseite des OIDC-Identitätsanbieters (IdP) weiter. Die Anfrage enthält eine gehashte Version des Code-Verifiers, die als Code-Challenge bezeichnet wird.
3. Der IdP sendet einen Authentifizierungscode für den Benutzer an NGINX Plus.
4. Basierend auf dem freigegebenen Status kann NGINX Plus den generierten Code-Verifier finden und die Anforderung zum Austausch des Autorisierungscodes gegen einen Token-Satz vom Token-Endpunkt des IdP senden.

Vor dem Hinzufügen von PKCE war es für NGINX Plus ausreichend, ein statisches Client-Geheimnis mit dem IdP zu teilen.
In der aktualisierten OIDC-Referenzimplementierung kann NGINX Plus Autorisierungscode-Flows sowohl für PKCE als auch für die Client-Secret-Methode verarbeiten.

Hier ist eine Beispielkonfiguration, die den erweiterten Autorisierungscode-Flow mit PKCE ermöglicht:

Die neue Variable $oidc_pkce_enable fungiert als Schalter für den PKCE-Flow. Wenn eingestellt auf1 für eine bestimmte Domäne wird der PKCE-Flow verwendet. Wenn eingestellt auf0 (Standard) wird der Nicht-PKCE-Autorisierungscode-Flow verwendet.

Weitere Verbesserungen in NGINX Plus R23

Feinkörnige Kontrolle über SSL/TLS-Verbindungen

TLS v1.3 ermöglicht eine stärkere Sicherheit als frühere TLS-Versionen mit End-to-End -Verschlüsselung zwischen Servern und zwischen Servern und ihren Clients. NGINX Plus R23 bietet direkten Zugriff auf die OpenSSL-Konfiguration für eine detaillierte Kontrolle über TLS v1.3.

Erstellen eines Standard-HTTPS-Servers ohne Zertifikat und Schlüssel

In früheren Versionen musste der Standardserverblock für TLS-geschützten HTTPS-Datenverkehr die Anweisungen ssl_certificate und ssl_certificate_key enthalten, sodass Sie ein selbstsigniertes „Dummy“-Zertifikat und einen entsprechenden Schlüssel erstellen mussten.

Die Direktive ssl_reject_handshake macht ein Zertifikat und einen Schlüssel überflüssig, wie in dieser Beispielkonfiguration:

Direkte OpenSSL-Konfiguration

NGINX Plus R23 gibt Ihnen eine feinere Kontrolle darüber, wie NGINX Plus SSL/TLS mit OpenSSL 1.0.2 und höher handhabt.

Die folgenden Anwendungsfälle profitieren von der neuen Kontrollebene:

• ChaCha-Chiffren – NGINX Plus verwendet ChaCha20, wenn ein Client (normalerweise mobil) diese Chiffre oben in seiner Präferenzliste angibt. ChaCha20 verbessert die Leistung für Clients, die es unterstützen, deutlich.

• TLS v1.3-Chiffre-Konfiguration – In früheren Versionen wurde die Direktive ssl_ciphers verwendet, um die Liste der bevorzugten SSL/TLS-Chiffren von NGINX Plus festzulegen, wie in diesem Beispiel:

  Diese Anweisung gilt jedoch nicht für TLS v1.3, da die OpenSSL-Implementierung von Chiffren für TLS v1.3 nicht mit den älteren Schnittstellen kompatibel ist. Um die Liste der Chiffren für TLS v1.3 festzulegen, verwenden Sie die neue Direktive ssl_conf_command wie in diesem Beispiel:

  Um Chiffren sowohl für TLS v1.2 als auch für v1.3 festzulegen, nehmen Sie beide Anweisungen in die Konfiguration auf:

• Upgrade von Proxy-Verbindungen – Aufbauend auf dem durch die Direktive ssl_conf_command implementierten Verschlüsselungskonfigurationsmechanismus bietet Ihnen NGINX Plus R23 die gleiche Kontrolle über Verschlüsselungssammlungen für Verbindungen, die mit diesen Protokollen geproxied werden:

  • HTTP und TCP – proxy_ssl_conf_command
  • gRPC – grpc_ssl_conf_command
  • uwsgi – uwsgi_ssl_conf_command

Das folgende Beispiel zeigt, wie NGINX Plus konfiguriert wird, um Anforderungen von Clients, die ältere TLS-Versionen verwenden, auf die Verwendung von Back-End-Servern zu aktualisieren, die nachweislich TLS v1.3 unterstützen.

Cache-Manager kann verfügbaren Speicherplatz überwachen

Wenn NGINX Plus als Caching-Proxy konfiguriert ist, garantiert der Cache-Manager -Prozess, dass die Cache-Größe den durch den Parameter max_size der Direktive proxy_cache_path festgelegten Grenzwert nicht überschreitet, indem er Inhalte entfernt, auf die am längsten nicht zugegriffen wurde.

Mit NGINX Plus R23 kann der Cache-Manager auch die Menge des verfügbaren Speicherplatzes auf dem Dateisystem überwachen, auf dem sich der Cache befindet, und Inhalte entfernen, wenn der verfügbare Speicherplatz kleiner ist als der neue min_free -Parameter der Direktive proxy_cache_path .

Dies bedeutet, dass NGINX Plus auch dann dafür sorgt, dass durch das Auffüllen des Caches nicht versehentlich die Festplatte gefüllt wird, wenn der Cache dasselbe Dateisystem wie andere Prozesse nutzt.

Native Methode zum Setzen von Cookie-Flags

Ungesicherte Cookies bleiben weiterhin ein Angriffsvektor mit hohem Risiko. Wie im Mozilla Developer Network (MDN) angemerkt, besteht eine Möglichkeit, sicherzustellen, dass Cookies nicht von unbefugten Dritten oder Skripten abgerufen werden, darin, Flags wie „HttpOnly“ und „Secure“ im Set-Cookie -Header zu setzen.

In früheren Versionen haben wir zu diesem Zweck die Direktive set_cookie_flag bereitgestellt, wie sie im Drittanbietermodul Cookie-Flag implementiert ist, das in unserem Repository für dynamische Module verfügbar ist. NGINX Plus R23 führt die Direktive proxy_cookie_flags ein, um diese Direktive und dieses Modul zu ersetzen.

Das veraltete Cookie-Flag-Modul wird in NGINX Plus R26 entfernt. Wir empfehlen Ihnen daher, alle set_cookie_flag -Direktiven in Ihrer Konfiguration zu suchen und sie so schnell wie möglich durch die Direktive proxy_cookie_flags zu ersetzen.

Hier ist eine Beispielkonfiguration für das Proxying zu einer einfachen Backend-Anwendung, die selbst keine Cookie-Schutz-Flags setzt:

In diesem Beispiel fügen wir die Flags HttpOnly , Secure und SameSite hinzu, um das vom Upstream-Server erstellte Sitzungscookie „appcookie“ zu sichern, das NGINX Plus für die Sitzungspersistenz verwendet, wie im NGINX Plus Admin Guide beschrieben.

Mit dem Curl -Befehl oder dem Entwicklertool Ihres Browsers können Sie sehen, dass die Flags HttpOnly , Secure und SameSite jetzt für appcookie gesetzt sind.

< HTTP/1.1 200 OK< Server: nginx/1.19.4
< Datum: Do, 08. Dez. 2020 14:46:12 GMT
< Inhaltstyp: Anwendung/Oktett-Stream
< Inhaltslänge: 9
< Verbindung: Keep-Alive
< Cookie setzen: appcookie=appserver1; Sicher; HttpOnly; SameSite=Strict
< Inhaltstyp: text/html

Mit NGINX Plus R23 können Sie Cookies mit der Direktive „Sticky“ auch das Flag „SameSite“ hinzufügen, wie in diesem Beispiel (die Parameter „httponly“ und „secure“ werden seit NGINX Plus R6 unterstützt):

Festlegen von Variablen im Stream-Modul

NGINX Plus R23 führt die Set- Direktive zum Festlegen von Variablen in TCP/UDP-Konfigurationen ein und erweitert damit die üblicherweise für die Verarbeitung von HTTP-Verkehr verwendete Funktion.

Hier ist ein Beispiel, das komplexe, zusammengesetzte Werte aus mehreren Variablen konstruiert.

In einem anspruchsvolleren Anwendungsfall wird die Set -Direktive zum Aktualisieren des Schlüssel-Wert-Speichers verwendet. In dieser Konfiguration für den DNS-Lastausgleich zeichnet der Schlüssel-Wert-Speicher den Zeitpunkt auf, zu dem jede Client-IP-Adresse eine DNS-Anforderung stellt, und speichert jeden Datensatz 24 Stunden lang.

Sie können dann die NGINX Plus-API verwenden, um herauszufinden, wann jeder Client in den letzten 24 Stunden seine letzte DNS-Anfrage gestellt hat.

$ curl http://localhost:8080/api/6/stream/keyvals/dns_timestamp { "172.17.0.1": "2020-12-08T15:51:28+00:00", "172.17.0.2": "2020-12-08T12:36:08+00:00", "172.17.0.7": "2020-12-08T15:15:42+00:00" }

Updates für das NGINX Plus-Ökosystem

Verbesserungen am NGINX JavaScript-Modul

Das NGINX JavaScript-Modul (njs) wurde aktualisiert auf0.5.0 . Diese Version führt das Buffer-Modul ein, das dem Node.js-Buffer-Modul entspricht. Pufferobjekte erleichtern die Arbeit mit Binärdaten, anstatt sich auf Zeichenfolgen zu verlassen.

Weitere wichtige Verbesserungen des Moduls sind das Query String-Modul für den einfachen Zugriff auf in der URL übergebene Schlüssel-Wert-Paare und die zeilenbasierte Backtrace-Unterstützung zum Debuggen.

Änderungen an dynamischen Modulen

Neues SPNEGO für Kerberos-Modul

Unterstützung für die SPNEGO Kerberos-Authentifizierung ist jetzt im Repository für dynamische Module von NGINX Plus verfügbar. Installationsanweisungen und Hinweise zu weiteren Informationen finden Sie im NGINX Plus Admin Guide .

Veraltetes Cookie-Flags-Modul

Wie oben im Abschnitt „Native Methode zum Festlegen von Cookie-Flags“ ausführlich beschrieben, ersetzt die neue Direktive „proxy_cookie_flags“ die Direktive „ set_cookie_flag“ , die im Cookie-Flag-Modul eines Drittanbieters implementiert ist, das mittlerweile veraltet ist und in NGINX Plus R26 entfernt werden soll. Wenn Ihre Konfiguration die Direktive „set_cookie_flag“ enthält, ersetzen Sie sie bitte so bald wie möglich durch „proxy_cookie_flags“ .

Aktualisierungen des Prometheus-njs-Moduls

Das Prometheus-njs-Modul stellt jetzt zusätzliche Metriken bereit. Es wurde außerdem aktualisiert, um Bereitstellungen zu unterstützen, die das NGINX JavaScript-Modul (njs) verwenden. Beim Upgrade von Prometheus-njs auf Version 1.3.1 und höher ist es wichtig, die NGINX-Konfigurationsdatei zu aktualisieren, um Verweise auf veraltete njs-Konfigurationen zu vermeiden:

• Die Direktive js_include ist veraltet und wurde durch die Direktive js_import ersetzt.
• Die Anweisungen js_content und js_set können auf eine Modulfunktion verweisen.

Wichtige Fehlerbehebung

Integritätsprüfungen, bei denen die Direktive „require “ in einem Match -Block verwendet wurde, um zu testen, ob die Variablen nicht leer waren, haben möglicherweise fehlerhafte Upstream-Server nicht erkannt, wenn die Antwort größer als der Wert der Direktive „proxy_buffer_size“ war.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R23 zu aktualisieren. Sie erhalten außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.