Ankündigung von NGINX Plus R23

Liam CrillySenior Director, Produktmanagement

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 softwarebasierte 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 an ihn gesendet werden, lässt sich die Zuverlässigkeit erheblich steigern.
• Unterstützung für die Installation ohne Administratorrechte – NGINX Plus kann jetzt von einem Benutzer ohne Administratorrechte (nicht als root) installiert und aktualisiert werden. Diese vollständig unterstützte Lösung entspricht dem zunehmenden Trend zu Zero-Trust-Sicherheitsmodellen.
• OpenID-Connect-PKCE-Unterstützung – NGINX Plus R23 implementiert die Erweiterung Proof Key for Code Exchange (PKCE) für den OpenID-Connect-Autorisierungscode-Flow. PKCE verhindert verschiedene Arten von Angriffen und ermöglicht einen sicheren OAuth-Austausch mit öffentlichen Clients.

Abgerundet wird diese Version durch eine feiner abgestufte Steuerung von SSL/TLS, eine native Methode zum Setzen von Cookie-Flags und das Setzen von Variablen im Stream-Modul. Zu den Neuerungen im NGINX Plus-Ökosystem gehören die neuen Module Buffer und Query String für das NGINX JavaScript-Modul, das neue dynamische Modul SPNEGO for Kerberos sowie Verbesserungen am dynamischen Modul Prometheus‑njs.

Wichtige Verhaltensänderungen

• Veraltetes Modul – Das Drittanbietermodul Cookie-Flag ist veraltet und wird durch die neue Direktive proxy_cookie_flags ersetzt. Das Modul wird in NGINX Plus R26 entfernt. Weitere Informationen 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, deren Unterstützung eingestellt wurde oder wird:
  • 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 Funktionen im Detail

gRPC-Zustandsprüfungen

Beim Einsatz als Load Balancer kann NGINX Plus den Zustand der Backend-Server (Upstream-Server) mithilfe von aktiven Zustandsprüfungen überwachen. NGINX Plus R23 unterstützt das gRPC-Protokoll für Zustandsprüfungen und kann damit zuverlässig prüfen, ob Backend-gRPC-Server neue Anfragen verarbeiten können. Dies ist besonders in dynamischen und containerisierten Umgebungen von Vorteil. Beim Starten neuer Instanzen eines gRPC-Dienstes ist es wichtig, Anfragen erst dann zu senden, wenn der Dienst „vollständig betriebsbereit“ ist. Dafür ist eine Zustandsprüfung erforderlich, die über die bloße Prüfung des TCP-Ports oder der Verfügbarkeit eines HTTP-URI hinausgeht – eine Prüfung, bei der der Dienst selbst angibt, ob er bereit ist, Anfragen zu empfangen.

Für gRPC-Dienste, die das gRPC-Protokoll für Zustandsprüfungen implementieren, ist die Konfiguration unkompliziert.

Codebeispiel wird geladen…

Diese Konfiguration verteilt alle Anfragen auf die Upstream-Gruppe grpc_backend. Die Direktive health_check enthält den Parameter type=grpc, um die Methode Check des Dienstes Health jedes Upstream-Servers aufzurufen. Dienste, die mit SERVING antworten, gelten als fehlerfrei. Der Parameter mandatory stellt sicher, dass beim Start von NGINX Plus oder beim Hinzufügen eines neuen Servers zur Upstream-Gruppe erst dann Datenverkehr weitergeleitet wird, wenn eine Integritätsprüfung erfolgreich war (andernfalls werden neue Dienste standardmäßig als fehlerfrei eingestuft).

Wenn auf jedem Upstream-Server mehrere gRPC-Dienste bereitgestellt werden, kann der wichtigste Dienst (von dem andere Dienste abhängen oder dem sie untergeordnet sind) überwacht werden, indem sein Name wie in diesem Beispiel als Wert für den Parameter „grpc_service“ angegeben wird:

Codebeispiel wird geladen…

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

Wir können auch überprüfen, ob ein gRPC-Dienst auf eingehende Anfragen antworten kann, ohne den Backend-Code ändern zu müssen. Mit diesem Ansatz können wir jeden beliebigen gRPC-Dienst überwachen:

Codebeispiel wird geladen…

Installation für Benutzer ohne Administratorrechte

In früheren Versionen wurde NGINX Plus mit einer minimalen Anzahl von Prozessen betrieben, die unter dem privilegierten Benutzer root ausgeführt wurden. Beispielsweise werden durch die Installationsanweisungen im NGINX Plus-Administratorhandbuch diese Prozesse erstellt:

$ ps auxf | grep nginxroot  ...  9068  888 ?  Ss 21:44  0:00 nginx: master process nginx
nginx ...  9712 3572 ?  S  21:44  0:00  \_ nginx: worker process

Wie dargestellt, wird der Masterprozess mit root-Rechten ausgeführt. Alle anderen Prozesse (Worker- und Cache-Verwaltungsprozesse) verwenden das unprivilegierte Benutzerkonto nginx.

Bei kritischen Systemen, die sensible Daten verarbeiten, sollte möglicherweise nicht der Benutzer root verwendet werden. In diesem Fall kann NGINX Plus R23 unter einem nicht privilegierten Benutzer installiert und ausgeführt werden. In unserem GitHub-Repository stellen wir das Installationsskript ngxunprivinst.sh für die folgenden Betriebssysteme bereit:

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

Hinweis: Wenn NGINX Plus-Listener für Ports unter 1024 konfiguriert sind (z. B. 80 oder 443), muss der Masterprozess über root-Berechtigungen verfügen (NGINX Plus kann jedoch weiterhin unter einem Benutzerkonto ohne besondere Berechtigungen installiert werden).

Führen Sie die folgenden Befehle aus, um das Installationsskript zu verwenden. (Um alle verfügbaren Befehle für ngxunprivinst.sh anzuzeigen, führen Sie das Skript ohne Angabe eines Befehlsnamens aus oder sehen Sie sich den Quellcode des Skripts im GitHub-Repository an.)

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

$ chmod +x ngxunprivinst.sh

1. Kopieren Sie Ihr NGINX Plus-Zertifikat und den zugehörigen 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 diese Dateien anzugeben.
2. Listen Sie die im NGINX Plus-Repository verfügbaren Versionen von NGINX Plus auf.

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

1. Rufen Sie das gewünschte Paket ab (hier rufen wir NGINX Plus R23-1 ab). Die Option „‑p“ gibt das Installationsverzeichnis an:

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

1. Installieren Sie die benötigten Pakete (hier installieren wir NGINX Plus und das NGINX-JavaScript-Modul njs).

$ ./ngxunprivinst.sh install -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

1. Starten Sie NGINX und verwenden Sie dabei die Option „‑p“, um den Pfad anzugeben, „‑c“, um die Konfigurationsdatei zu benennen, und „‑e“, um die Fehlerprotokolldatei zu benennen.

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

1. Wir verwenden die Option ‑e, um die andernfalls angezeigte Warnmeldung zu unterdrücken. Bevor NGINX Plus beim Start seine Konfiguration eingelesen hat, schreibt es in das standardmäßige Fehlerprotokoll /var/log/nginx/error.log. Benutzer ohne erhöhte Berechtigungen dürfen diese Datei weder erstellen noch darin schreiben, wodurch eine Warnung ausgegeben wird. Sobald die Konfiguration eingelesen wurde, legt die Direktive error_log für das Fehlerprotokoll einen Speicherort fest, in den der Benutzer ohne erhöhte Berechtigungen schreiben kann.
2. (Optional) Um zu überprüfen, ob NGINX Plus als Benutzer ohne root-Rechte ausgeführt wird, führen Sie diesen Befehl aus:

$ ps auxf | grep nginx
nginxrun ...  9068  888 ?  Ss 21:55 0:00 nginx: master process
nginxrun ...  9712 3572 ?  S  21:55 0:00  \_ nginx: worker process

OpenID Connect PKCE-Unterstützung

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

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

• code_challenge
• code_verifier

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

1. NGINX Plus generiert (und speichert) einen code_verifier.
2. NGINX Plus leitet den Endbenutzer zur Anmeldeseite des OIDC-Identitätsanbieters (IdP) weiter. Die Anfrage enthält eine gehashte Version des code_verifier mit der Bezeichnung code_challenge.
3. Der IdP sendet einen auth_code für den Benutzer an NGINX Plus.
4. Anhand des gemeinsamen Zustands kann NGINX Plus den generierten code_verifier ermitteln und die Anfrage senden, um den Autorisierungscode am Token-Endpunkt des IdP gegen einen Tokensatz auszutauschen.

Vor der Einführung von PKCE genügte es, dass NGINX Plus ein statisches Client-Geheimnis mit dem IdP teilte.
In der aktualisierten OIDC-Referenzimplementierung kann NGINX Plus Autorisierungscode-Flows sowohl mit PKCE als auch mit der Client-Geheimnis-Methode verarbeiten.

Hier ist eine Beispielkonfiguration, die den erweiterten Authorization-Code-Flow mit PKCE aktiviert:

Codebeispiel wird geladen…

Die neue Variable „$oidc_pkce_enable“ dient als Schalter für den PKCE-Flow. Ist sie für eine bestimmte Domain auf „1“ gesetzt, wird der PKCE-Flow verwendet. Ist sie auf „0“ (Standardwert) gesetzt, wird der Autorisierungscode-Flow ohne PKCE verwendet.

Weitere Verbesserungen in NGINX Plus R23

Feingranulare Steuerung von SSL/TLS-Verbindungen

TLS v1.3 bietet eine höhere Sicherheit als frühere TLS-Versionen und ermöglicht eine Ende-zu-Ende-Verschlüsselung sowohl zwischen Servern als auch zwischen Servern und ihren Clients. NGINX Plus R23 bietet direkten Zugriff auf die OpenSSL-Konfiguration und ermöglicht so eine präzise Steuerung von TLS v1.3.

Erstellen eines standardmäßigen HTTPS-Servers ohne Zertifikat und Schlüssel

In früheren Versionen musste der standardmäßige server-Block für TLS-geschützten HTTPS-Datenverkehr die Direktiven 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:

Codebeispiel wird geladen…

Direkte OpenSSL-Konfiguration

NGINX Plus R23 bietet Ihnen eine präzisere Kontrolle darüber, wie NGINX Plus SSL/TLS mit OpenSSL 1.0.2 und höher verarbeitet.

Die folgenden Anwendungsfälle profitieren von der neuen Steuerungsebene:

• ChaCha-Chiffren – NGINX Plus verwendet ChaCha20, wenn ein Client (in der Regel ein Mobilgerät) diese Chiffre an die erste Stelle seiner Präferenzliste setzt. ChaCha20 verbessert die Leistung für Clients, die diese Chiffre unterstützen, deutlich.
• Konfiguration von Verschlüsselungsverfahren für TLS v1.3 – In früheren Versionen wurde die Direktive „ssl_ciphers“ verwendet, um die Liste der bevorzugten SSL/TLS-Verschlüsselungsverfahren von NGINX Plus festzulegen, wie in diesem Beispiel:

  Codebeispiel wird geladen…

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

  Codebeispiel wird geladen…

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

  Codebeispiel wird geladen…

• Upgrade von Proxy-Verbindungen – Aufbauend auf dem durch die ssl_conf_command-Direktive implementierten Mechanismus zur Verschlüsselungskonfiguration bietet Ihnen NGINX Plus R23 dieselbe Kontrolle über Cipher Suites für Verbindungen, die über folgende Protokolle weitergeleitet werden:
  • HTTP und TCP – proxy_ssl_conf_command
  • gRPC – grpc_ssl_conf_command
  • uwsgi – uwsgi_ssl_conf_command

Das folgende Beispiel zeigt, wie Sie NGINX Plus so konfigurieren, dass Anfragen von Clients, die ältere TLS-Versionen verwenden, auf Backend-Server aktualisiert werden, die bekanntermaßen TLS v1.3 unterstützen.

Codebeispiel wird geladen…

Der Cache-Manager kann den verfügbaren Speicherplatz überwachen

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

Mit NGINX Plus R23 kann der Cache-Manager auch den verfügbaren Speicherplatz im Dateisystem überwachen, in dem sich der Cache befindet, und Inhalte entfernen, wenn der verfügbare Speicherplatz den Wert des neuen Parameters „min_free“ der Direktive „proxy_cache_path“ unterschreitet.

Das bedeutet, dass NGINX Plus selbst dann, wenn der Cache dasselbe Dateisystem wie andere Prozesse nutzt, sicherstellt, dass das Befüllen des Caches nicht versehentlich den gesamten Speicherplatz belegt.

Codebeispiel wird geladen…

Native Methode zum Setzen von Cookie-Flags

Ungesicherte Cookies stellen weiterhin einen Angriffsvektor mit hohem Risiko dar. Wie im Mozilla Developer Network (MDN) erläutert, lässt sich der Zugriff unbefugter Dritter oder unerwünschter Skripte auf Cookies unter anderem verhindern, indem Flags wie HttpOnly und Secure im Set-Cookie-Header gesetzt werden.

In früheren Versionen stellten wir zu diesem Zweck die Direktive „set_cookie_flag“ bereit, die im Drittanbietermodul „Cookie‑Flag module“ implementiert und in unserem Repository für dynamische Module verfügbar war. NGINX Plus R23 führt die Direktive „proxy_cookie_flags“ ein, die diese Direktive und dieses Modul ersetzt.

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

Hier ist eine Beispielkonfiguration für die Weiterleitung an eine einfache Backend-Anwendung, die selbst keine Cookie-Schutzflags setzt:

Codebeispiel wird geladen…

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

Mit dem Befehl „curl“ oder den Entwicklertools 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
< Date: Thu, 08 Dec 2020 14:46:12 GMT
< Content-Type: application/octet-stream
< Content-Length: 9
< Connection: keep-alive
< Set-Cookie: appcookie=appserver1; Secure; HttpOnly; SameSite=Strict
< Content-Type: text/html

Mit NGINX Plus R23 können Sie Cookies außerdem mit dem Flag SameSite versehen, indem Sie die Direktive sticky verwenden, wie in diesem Beispiel (die Parameter httponly und secure werden bereits seit NGINX Plus R6 unterstützt):

Codebeispiel wird geladen…

Festlegen von Variablen im Stream-Modul

Mit NGINX Plus R23 wird die set-Direktive zum Festlegen von Variablen in TCP/UDP-Konfigurationen eingeführt. Damit wird die Funktion erweitert, die üblicherweise für die Verarbeitung von HTTP-Datenverkehr verwendet wird.

Das folgende Beispiel erstellt komplexe, zusammengesetzte Werte aus mehreren Variablen.

Codebeispiel wird geladen…

Ein komplexerer Anwendungsfall verwendet die set-Direktive, um den Schlüssel-Wert-Speicher zu aktualisieren. In dieser Konfiguration für den DNS-Lastenausgleich zeichnet der Schlüssel-Wert-Speicher den Zeitpunkt auf, zu dem die einzelnen Client-IP-Adressen eine DNS-Anfrage stellen, und bewahrt jeden Eintrag 24 Stunden lang auf.

Codebeispiel wird geladen…

Anschließend können Sie mithilfe der NGINX Plus API ermitteln, wann die einzelnen Clients innerhalb der letzten 24 Stunden ihre jeweils letzte DNS-Anfrage gestellt haben.

$ 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"
}

Aktualisierungen im NGINX Plus-Ökosystem

Verbesserungen am NGINX-JavaScript-Modul

Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.5.0 aktualisiert. Diese Version führt das Buffer-Modul ein, das dem Buffer-Modul von Node.js entspricht. Buffer-Objekte erleichtern die Arbeit mit Binärdaten, sodass nicht mehr auf Zeichenfolgen zurückgegriffen werden muss.

Weitere erwähnenswerte Verbesserungen des Moduls sind das Query-String-Modul für den einfachen Zugriff auf in der URL übergebene Schlüssel-Wert-Paare sowie die Unterstützung von Backtraces auf Zeilenebene für die Fehlersuche.

Änderungen an dynamischen Modulen

Neues SPNEGO für das 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 weiterführende Informationen finden Sie im Administratorhandbuch für NGINX Plus.

Veraltetes Cookie-Flags-Modul

Wie oben unter „Native Methode zum Setzen von Cookie-Flags“ beschrieben, ersetzt die neue Direktive „proxy_cookie_flags“ die Direktive „set_cookie_flag“ aus dem Drittanbietermodul Cookie-Flag. Dieses Modul ist inzwischen veraltet und soll mit NGINX Plus R26 entfernt werden. Wenn Ihre Konfiguration die Direktive „set_cookie_flag“ enthält, ersetzen Sie sie bitte so bald wie möglich durch „proxy_cookie_flags“.

Aktualisierungen am Prometheus-njs-Modul

Das Prometheus‑njs-Modul stellt nun zusätzliche Metriken bereit. Außerdem wurde es aktualisiert, um Bereitstellungen zu unterstützen, die das NGINX-JavaScript-Modul (njs) verwenden. Beim Upgrade von Prometheus‑njs auf Version 1.3.1 oder höher muss die NGINX-Konfigurationsdatei aktualisiert werden, um Verweise auf veraltete njs-Konfigurationen zu vermeiden:

• Die js_include-Direktive ist veraltet und wurde durch die js_import-Direktive ersetzt
• Die Direktiven „js_content“ und „js_set“ können auf eine Modulfunktion verweisen

Wichtige Fehlerbehebung

Systemdiagnosen, die die require-Direktive in einem match-Block verwendeten, um zu prüfen, ob Variablen nicht leer waren, haben möglicherweise fehlerhafte Upstream-Server nicht erkannt, wenn die Antwort größer als der Wert der proxy_buffer_size-Direktive war.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R23 durchzuführen. Dadurch erhalten Sie außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

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

Über den Autor

Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly