Ankündigung von NGINX Plus R15

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass die fünfzehnte Version von NGINX Plus, unserem Flaggschiffprodukt, ab sofort verfügbar ist. Seit unserer Erstveröffentlichung im Jahr 2013 ist NGINX Plus sowohl hinsichtlich seines Funktionsumfangs als auch seiner kommerziellen Attraktivität enorm gewachsen. Mittlerweile gibt es mehr als [ngx_snippet name=’nginx-plus-customers’] Kunden von NGINX Plus und [ngx_snippet name=’number-sites’] Nutzer von NGINX Open Source.

NGINX Plus basiert auf NGINX Open Source und ist die einzige Komplettlösung, die Load Balancer, Content-Cache, Webserver und API-Gateway in einem Produkt vereint. NGINX Plus bietet exklusive erweiterte Funktionen, die die Architektur moderner Anwendungen vereinfachen, sowie einen preisgekrönten Support.

NGINX Plus R15 bietet neue Unterstützung für gRPC, HTTP/2 Server Push, verbesserte Cluster-Unterstützung, erweiterte API-Gateway-Funktionen und vieles mehr:

• Native gRPC-Unterstützung – gRPC ist der neue, von Google entwickelte Standard für Remote Procedure Calls (RPC). Er ermöglicht eine schlanke und effiziente Kommunikation zwischen Clients und Servern. Mit dieser neuen Funktion kann NGINX Plus SSL für gRPC-Datenverkehr terminieren und diesen an Ihre Backend-Server weiterleiten und per Lastenausgleich verteilen.
• HTTP/2-Server-Push – Mit HTTP/2-Server-Push kann NGINX Plus Ressourcen senden, noch bevor Clients sie tatsächlich anfordern. Dies verbessert die Leistung und reduziert die Anzahl der Roundtrips.
• Statusfreigabe innerhalb eines Clusters – Mit dieser Version können die für die Sticky-Learn-Sitzungspersistenz verwendeten Daten im gemeinsamen Speicher von allen NGINX Plus-Instanzen in einem Cluster gemeinsam genutzt werden. In den nächsten Versionen von NGINX Plus werden wir unsere Clustering-Funktionen weiter ausbauen und neue clusterfähige Funktionen einführen.
• OpenID-Connect-Integration – Mit NGINX Plus können Sie jetzt Single Sign-on (SSO) für jede Webanwendung bereitstellen. Dabei wird der OpenID Connect Authorization Code Flow verwendet und es werden JSON Web Tokens (JWTs) für Clients ausgestellt. NGINX Plus lässt sich in CA Single Sign-On (ehemals SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity und andere gängige Identitätsanbieter integrieren.
• Verbesserungen an den NGINX-JavaScript-Modulen (njs) – Mit den njs-Modulen (früher nginScript) können Sie während der Verarbeitung von Anfragen durch NGINX Plus JavaScript-Code ausführen. Das njs-Modul für HTTP unterstützt jetzt das Senden von HTTP-Unteranfragen, die unabhängig von der Client-Anfrage und asynchron zu ihr ausgeführt werden. Dies ist bei API-Gateway-Anwendungsfällen hilfreich und bietet Ihnen die Flexibilität, API-Aufrufe mithilfe von JavaScript anzupassen und zusammenzuführen. Die njs-Module für HTTP und TCP/UDP enthalten jetzt außerdem Kryptobibliotheken, mit denen sich gängige Hashfunktionen implementieren lassen.

Abgerundet wird das Release durch weitere neue Funktionen, darunter eine neue ALPN-Variable, Aktualisierungen für mehrere dynamische Module und vieles mehr.

Verhaltensänderungen

• Mit NGINX Plus R13 wurde die völlig neue NGINX Plus API eingeführt, die Funktionen bereitstellt, die zuvor in separaten APIs implementiert waren, darunter die dynamische Konfiguration von Upstream-Gruppen und erweiterte Metriken. Die bisherigen APIs, die mit den Direktiven upstream_conf und status konfiguriert werden, sind veraltet. Wir empfehlen Ihnen, Ihre Konfiguration auf diese Direktiven zu überprüfen und so bald wie möglich auf die neue Direktive api umzustellen (weitere Informationen finden Sie im Beitrag Ankündigung von NGINX Plus R13 in unserem Blog). Ab der nächsten Version, NGINX Plus R16, werden die veralteten APIs nicht mehr ausgeliefert.
• Die NGINX Plus API wird mit diesem Release auf Version 3 aktualisiert. Frühere Versionen werden weiterhin unterstützt. Wenn Sie eine Aktualisierung Ihrer API-Clients in Erwägung ziehen, lesen Sie die Dokumentation zur API-Kompatibilität.
• Für die im offiziellen Repository verfügbaren NGINX Plus-Pakete gilt jetzt ein neues Nummerierungsschema. Das NGINX Plus-Paket und alle dynamischen Module weisen nun die NGINX Plus-Releasenummer aus. Jede Paketversion entspricht jetzt der NGINX Plus-Version. Dadurch ist leichter erkennbar, welche Version installiert ist, und Modulabhängigkeiten werden vereinfacht. Diese Änderung hat keine Auswirkungen, es sei denn, Sie verwenden automatisierte Systeme, die anhand der Versionsnummer auf Pakete verweisen. Testen Sie in diesem Fall den Upgradeprozess bitte zunächst in einer Nicht-Produktionsumgebung.

NGINX Plus R15 – Funktionen im Detail

gRPC-Unterstützung

Mit dieser Version kann NGINX Plus gRPC-Datenverkehr als Proxy weiterleiten und per Lastverteilung verteilen. Viele Unternehmen nutzen gRPC bereits für die Kommunikation mit Microservices. gRPC ist ein von Google entwickeltes, quelloffenes und leistungsstarkes Framework für Remote Procedure Calls (RPC), das eine hocheffiziente Service-zu-Service-Kommunikation mit geringer Latenz ermöglicht. gRPC schreibt HTTP/2 anstelle von HTTP 1.1 als Transportmechanismus vor, da sich die Funktionen von HTTP/2 – Flusssteuerung, Multiplexing und bidirektionales Datenstreaming mit geringer Latenz – ideal für die skalierbare Vernetzung von Microservices eignen.

NGINX leitet gRPC-Datenverkehr weiter und terminiert SSL

Die Unterstützung für gRPC wurde mit NGINX Open Source 1.13.10 eingeführt und ist jetzt in NGINX Plus R15 enthalten. Sie können nun gRPC-Methodenaufrufe prüfen und weiterleiten. Dadurch haben Sie folgende Möglichkeiten:

• Wenden Sie NGINX Plus-Funktionen – darunter HTTP/2-TLS-Verschlüsselung, Ratenbegrenzung, IP-adressbasierte Zugriffssteuerungslisten und Protokollierung – auf veröffentlichte gRPC-Dienste an.
• Veröffentlichen Sie mehrere gRPC-Dienste über einen einzigen Endpunkt, indem Sie gRPC-Verbindungen prüfen und an interne Dienste weiterleiten.
• Skalieren Sie Ihre gRPC-Dienste bei zusätzlichem Kapazitätsbedarf, indem Sie gRPC-Verbindungen per Lastenausgleich auf vorgelagerte Backend-Pools verteilen.
• Verwenden Sie NGINX Plus als API-Gateway für gRPC- und RESTful-Endpunkte.

Weitere Informationen finden Sie unter „Einführung der gRPC-Unterstützung mit NGINX 1.13.10“ in unserem Blog.

HTTP/2-Server-Push

Der erste Eindruck zählt, und die Ladezeit einer Seite ist ein entscheidender Faktor dafür, ob Nutzer Ihre Website erneut besuchen. Eine Möglichkeit, Nutzern schnellere Antworten bereitzustellen, ist HTTP/2 Server Push. Dadurch verringert sich die Anzahl der RTTs (Round-Trip Times, also die für eine Anfrage und Antwort benötigte Zeit), die der Nutzer abwarten muss.

NGINX kann Ressourcen proaktiv an Clients übertragen, um die Leistung zu verbessern

HTTP/2 Server Push war eine von der NGINX-Open-Source-Community häufig gewünschte und mit Spannung erwartete Funktion, die mit NGINX Open Source 1.13.9 eingeführt wurde. Die nun in NGINX Plus R15 enthaltene Funktion ermöglicht es einem Server, proaktiv Daten zu senden, die voraussichtlich benötigt werden, um eine zuvor vom Client initiierte Anfrage abzuschließen. Ein Browser benötigt beispielsweise eine ganze Reihe von Ressourcen – Stylesheets, Bilder und Ähnliches –, um eine Webseite darzustellen. Daher kann es sinnvoll sein, diese Ressourcen sofort zu senden, wenn ein Client zum ersten Mal auf die Seite zugreift, anstatt darauf zu warten, dass der Browser sie ausdrücklich anfordert.

Im folgenden Konfigurationsbeispiel verwenden wir die Direktive „http2_push“, um einem Client vorab die Stylesheets und Bilder bereitzustellen, die er zum Rendern der Webseite „demo“ benötigt:

Codebeispiel wird geladen…

In einigen Fällen ist es jedoch nicht möglich, genau zu bestimmen, welche Ressourcen von den Clients benötigt werden. Daher ist es unpraktikabel, bestimmte Dateien in der NGINX-Konfigurationsdatei aufzulisten. In diesen Fällen kann NGINX HTTP-Link-Header abfangen und die darin mit preload gekennzeichneten Ressourcen per Push übertragen. Um das Abfangen von Link-Headern zu aktivieren, setzen Sie die Direktive http2_push_preload auf on.

Codebeispiel wird geladen…

Weitere Informationen finden Sie im Beitrag „Einführung in HTTP/2 Server Push mit NGINX 1.13.9“ in unserem Blog.

Statusfreigabe innerhalb eines Clusters

Wenn Sie mehrere NGINX Plus-Server zu einem Hochverfügbarkeitscluster zusammenfassen, werden Ihre Anwendungen ausfallsicherer und einzelne Ausfallpunkte in Ihrem Anwendungs-Stack beseitigt. Das Clustering mit NGINX Plus ist für geschäftskritische Produktionsumgebungen konzipiert, in denen Ausfallsicherheit und Hochverfügbarkeit von größter Bedeutung sind. Es gibt zahlreiche Lösungen für die Implementierung von Hochverfügbarkeitsclustern mit NGINX Plus.

Die Unterstützung für Clustering wurde bereits in früheren Versionen von NGINX Plus eingeführt und bietet zwei Clustering-Stufen:

• Netzwerkresilienz mit dem keepalived-Paket – Übernimmt das Failover, wenn ein NGINX Plus-Server ausfällt.
• Konfigurationssynchronisierung mit dem Paket nginx-sync package – Stellt sicher, dass die Konfiguration auf allen NGINX Plus-Servern synchron ist.

NGINX Plus R15 führt eine dritte Clustering-Ebene ein – die gemeinsame Nutzung von Zustandsinformationen während der Laufzeit. Dadurch können Daten in Shared-Memory-Zonen zwischen den Clusterknoten synchronisiert werden. Insbesondere lassen sich die in Shared-Memory-Zonen gespeicherten Daten für die Sticky-Learn-Sitzungspersistenz nun mithilfe des neuen zone_sync-Moduls für TCP/UDP-Datenverkehr auf allen Knoten im Cluster synchronisieren.

Neues zone_sync-Modul

Bei der gemeinsamen Zustandsnutzung gibt es keinen primären Knoten – alle Knoten sind gleichberechtigt und tauschen Daten in einer vollständig vermaschten Topologie aus. Darüber hinaus ist die Clusterlösung für die gemeinsame Zustandsnutzung unabhängig von der Hochverfügbarkeitslösung für die Ausfallsicherheit des Netzwerks. Daher kann sich ein Cluster mit gemeinsamer Zustandsnutzung über mehrere physische Standorte erstrecken.

Ein NGINX Plus-Cluster mit Statusfreigabe muss drei Anforderungen erfüllen:

• Netzwerkverbindung zwischen allen Clusterknoten
• Synchronisierte Uhren
• Die Konfiguration auf jedem Knoten aktiviert das Modul zone_sync, wie im Folgenden gezeigt:

  Codebeispiel wird geladen…

Die Direktive „zone_sync“ ermöglicht die Synchronisierung gemeinsam genutzter Speicherzonen in einem Cluster. Die Direktive „zone_sync_server“ identifiziert die anderen NGINX Plus-Instanzen im Cluster. NGINX Plus unterstützt die DNS-Diensterkennung, sodass Cluster-Mitglieder anhand ihres Hostnamens identifiziert werden können und die Konfiguration für jedes Cluster-Mitglied identisch ist.

Der oben gezeigten Minimalkonfiguration fehlen die erforderlichen Sicherheitsmaßnahmen zum Schutz der Synchronisierungsdaten in einer Produktionsumgebung. Das folgende Konfigurationsfragment verwendet mehrere solcher Schutzmaßnahmen:

• SSL/TLS-Verschlüsselung der Synchronisierungsdaten
• Client-Zertifikatsauthentifizierung, damit sich jeder Cluster-Knoten gegenüber den anderen identifiziert (gegenseitiges TLS)
• Zugriffssteuerungslisten (ACLs) auf Basis von IP-Adressen, sodass nur NGINX Plus-Knoten im selben physischen Netzwerk eine Verbindung zur Synchronisierung herstellen können

Codebeispiel wird geladen…

Statusfreigabe für die Sitzungspersistenz mit Sticky Learn

Die erste unterstützte NGINX Plus-Funktion, die gemeinsam genutzte Zustandsdaten in einem Cluster verwendet, ist die Sticky-Learn-Sitzungspersistenz. Sitzungspersistenz bedeutet, dass Anfragen eines Clients immer an den Server weitergeleitet werden, der die erste Anfrage des Clients bearbeitet hat. Dies ist nützlich, wenn der Sitzungsstatus im Backend gespeichert wird.

In der folgenden Konfiguration definiert die Direktive „sticky learn“ eine Shared-Memory-Zone namens „sessions“. Der Parameter „sync“ ermöglicht die clusterweite gemeinsame Nutzung von Zustandsdaten, indem er NGINX Plus anweist, Nachrichten über den Inhalt seiner Shared-Memory-Zone an die anderen Knoten im Cluster zu senden.

Beachten Sie, dass für eine ordnungsgemäße Synchronisierung der Zustandsdaten die Konfiguration auf jedem NGINX Plus-Knoten im Cluster denselben upstream-Block mit der Direktive sticky learn sowie die Direktiven enthalten muss, die das Modul zone_sync aktivieren (weiter oben beschrieben).

Codebeispiel wird geladen…

Hinweis: Unterstützung für Clustering und Sitzungspersistenz mit Sticky Learn sind ausschließlich in NGINX Plus verfügbar.

OpenID-Connect-Integration

Viele Unternehmen nutzen Lösungen für das Identitäts- und Zugriffsmanagement (IAM), um Benutzerkonten zu verwalten und eine Single-Sign-on-Umgebung (SSO) für mehrere Anwendungen bereitzustellen. Häufig möchten sie SSO auf neue und bestehende Anwendungen ausweiten, um Komplexität und Kosten zu minimieren.

„Durch den Einsatz von OpenID Connect mit NGINX Plus konnten wir unseren Identitätsanbieter schnell und einfach integrieren und gleichzeitig unsere Anwendungsarchitektur vereinfachen.“ – Scott Macleod, Softwareentwickler, NHS Digital

Mit NGINX Plus R10 wurde die Unterstützung für die Validierung von OpenID-Connect-Token eingeführt. In dieser Version erweitern wir diese Funktion, sodass NGINX Plus auch den Autorisierungscode-Flow für die Authentifizierung mit OpenID Connect 1.0 steuern, mit dem Identitätsanbieter kommunizieren und das Zugriffstoken an den Client ausgeben kann. Dies ermöglicht die Integration mit den meisten großen Identitätsanbietern, darunter CA Single Sign-On (ehemals SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin und Ping Identity. Mit der neu erweiterten Funktion können Sie außerdem:

• SSO auf Legacy-Anwendungen ausweiten, ohne diese Anwendungen zu ändern oder zu modernisieren
• SSO in neue Anwendungen integrieren, ohne SSO oder Authentifizierung im Anwendungscode zu implementieren
• Vermeiden Sie die Abhängigkeit von einem bestimmten Anbieter: Sie erhalten standardbasiertes SSO, ohne proprietäre Agentensoftware eines IAM-Anbieters zusammen mit der Anwendung bereitstellen zu müssen.

Die OpenID-Connect-Integration mit NGINX Plus ist als Referenzimplementierung auf GitHub verfügbar. Das GitHub-Repository enthält eine Beispielkonfiguration mit Anweisungen zur Installation, Konfiguration und Feinabstimmung für bestimmte Anwendungsfälle.

Verbesserungen am NGINX-JavaScript-Modul

[Redaktion – Die folgenden Beispiele zeigen nur einige der zahlreichen Anwendungsfälle für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter „Anwendungsfälle für das NGINX JavaScript-Modul“.

Der Code in diesem Abschnitt wurde wie folgt aktualisiert, um Änderungen an der Implementierung von NGINX JavaScript seit der ursprünglichen Veröffentlichung des Blogbeitrags zu berücksichtigen:

• Zur Verwendung des überarbeiteten Sitzungsobjekts (s) für das Stream-Modul, das mit NGINX JavaScript 0.2.4 eingeführt wurde.
• Zur Verwendung der js_import-Direktive, die ab js_include durch die NGINX Plus R23-Direktive ersetzt wird. Weitere Informationen finden Sie in der Referenzdokumentation zum NGINX-JavaScript-Modul – im Abschnitt Beispielkonfiguration wird die korrekte Syntax für NGINX-Konfigurations- und JavaScript-Dateien gezeigt.

]

Mit dem NGINX-JavaScript-Modul njs (früher nginScript) können Sie JavaScript-Code in Ihre NGINX-Konfiguration einbinden, sodass er zur Laufzeit bei der Verarbeitung von HTTP- oder TCP/UDP-Anfragen ausgewertet wird. Dies eröffnet zahlreiche potenzielle Anwendungsfälle, beispielsweise eine präzisere Steuerung des Datenverkehrs, die anwendungsübergreifende Konsolidierung von JavaScript-Funktionen und die Abwehr von Sicherheitsbedrohungen.

NGINX Plus R15 enthält zwei bedeutende Neuerungen für njs: Unteranfragen und Hashfunktionen.

Unteranfragen

Sie können jetzt mehrere HTTP-Anfragen gleichzeitig senden, die unabhängig von der Client-Anfrage und asynchron zu dieser ausgeführt werden. Dies ermöglicht eine Vielzahl fortgeschrittener Anwendungsfälle.

Der folgende JavaScript-Beispielcode sendet gleichzeitig eine HTTP-Anfrage an zwei verschiedene Backends. Die erste Antwort wird zur Weiterleitung an den Client an NGINX Plus gesendet, während die zweite Antwort ignoriert wird.

Codebeispiel wird geladen…

Die js_import-Direktive in der entsprechenden NGINX Plus-Konfiguration liest den JavaScript-Code aus fastest_wins.js ein. Alle Anfragen, die mit der Root-Location (/) übereinstimmen, werden an die Funktion sendFastest() übergeben, die Unteranfragen an die Locations /server_one und /server_two erzeugt. Der ursprüngliche URI wird zusammen mit den Abfrageparametern an die entsprechenden Backend-Server übergeben. Beide Unteranfragen führen die Callback-Funktion done aus. Da diese Funktion jedoch r.return() enthält, sendet nur die zuerst abgeschlossene Unteranfrage ihre Antwort an den Client.

Codebeispiel wird geladen…

Hashfunktionen

Die njs-Module für HTTP- und TCP/UDP-Datenverkehr enthalten jetzt eine Kryptobibliothek mit Implementierungen für:

• Hashfunktionen: MD5, SHA‑1, SHA‑256
• HMAC mit: MD5, SHA‑1, SHA‑256
• Digestformate: Base64, Base64URL, Hexadezimal

Ein beispielhafter Anwendungsfall für Hashfunktionen besteht darin, die Datenintegrität von Anwendungscookies sicherzustellen. Das folgende njs-Codebeispiel enthält eine Funktion signCookie() zum Hinzufügen einer digitalen Signatur zu einem Cookie sowie eine Funktion validateCookieSignature() zum Validieren signierter Cookies.

Codebeispiel wird geladen…

Die folgende NGINX Plus-Konfiguration verwendet den njs-Code, um Cookie-Signaturen in eingehenden HTTP-Anfragen zu validieren und bei fehlgeschlagener Validierung eine Fehlermeldung an den Client zurückzugeben. Wenn die Validierung erfolgreich ist oder kein Cookie vorhanden ist, leitet NGINX Plus die Anfrage per Proxy weiter.

Codebeispiel wird geladen…

Weitere neue Funktionen in NGINX Plus R15

ALPN-Variable für die Stream-Module

Application-Layer Protocol Negotiation (ALPN) ist eine TLS-Erweiterung, die es Client und Server ermöglicht, während des TLS-Handshakes auszuhandeln, welches Protokoll für die herzustellende Verbindung verwendet wird. Dadurch werden zusätzliche Roundtrips vermieden, die zu Latenzen führen und die Benutzererfahrung beeinträchtigen könnten. Der häufigste Anwendungsfall für ALPN ist das automatische Upgrade von Verbindungen von HTTP auf HTTP/2, wenn sowohl der Client als auch der Server HTTP/2 unterstützen.

Die neue NGINX-Variable $ssl_preread_alpn_protocols, die erstmals in NGINX Open Source 1.13.10 eingeführt wurde, erfasst die Liste der Protokolle, die der Client in seiner ClientHello-Nachricht während der ALPN-Preread-Phase ankündigt. Mit der folgenden Konfiguration kann sich ein XMPP-Client über ALPN identifizieren, sodass NGINX Plus den XMPP-Datenverkehr an die Upstream-Gruppe xmpp_backend, den gRPC-Datenverkehr an grpc_backend und den gesamten übrigen Datenverkehr an http_backend weiterleitet – alles über einen einzigen Endpunkt.

Damit NGINX Plus Informationen aus der ClientHello-Nachricht extrahieren und die Variable $ssl_preread_alpn_protocols befüllen kann, müssen Sie außerdem die Direktive ssl_preread on einfügen.

Codebeispiel wird geladen…

Weitere Informationen finden Sie in der Dokumentation zum Modul ngx_stream_ssl_preread.

Variable für die Warteschlangenzeit

NGINX Plus unterstützt Upstream-Warteschlangen und verhindert so, dass Clientanfragen sofort abgelehnt werden müssen, wenn kein Server in der Upstream-Gruppe neue Anfragen annehmen kann.

Ein typischer Anwendungsfall für das Einreihen von Upstream-Anfragen in eine Warteschlange besteht darin, Backend-Server vor Überlastung zu schützen, ohne Anfragen sofort ablehnen zu müssen, wenn alle Server ausgelastet sind. Mit dem Parameter max_conns der Direktive server können Sie die maximale Anzahl gleichzeitiger Verbindungen für jeden Upstream-Server festlegen. Die Direktive queue reiht Anfragen in eine Warteschlange ein, wenn keine Backends verfügbar sind, weil sie entweder ihr Verbindungslimit erreicht oder eine Integritätsprüfung nicht bestanden haben.

In dieser Version erfasst die neue NGINX-Variable $upstream_queue_time, die erstmals in NGINX Open Source 1.13.9 eingeführt wurde, wie lange sich eine Anfrage in der Warteschlange befindet. Die folgende Konfiguration enthält ein benutzerdefiniertes Protokollformat, das verschiedene Zeitmesswerte für jede Anfrage erfasst. Diese Messwerte können anschließend im Rahmen der Leistungsoptimierung offline analysiert werden. Wir begrenzen die Anzahl der Anfragen in der Warteschlange für die Upstream-Gruppe my_backend auf 20. Der Parameter timeout legt fest, wie lange Anfragen in der Warteschlange verbleiben, bevor eine Fehlermeldung an den Client zurückgegeben wird (standardmäßig 503). Hier legen wir den Wert auf 5 Sekunden fest (der Standardwert beträgt 60 Sekunden).

Codebeispiel wird geladen…

Weitere Informationen finden Sie in der Dokumentation zur queue-Direktive.

Zugriffsprotokolle ohne Maskierung

Sie können nun das Escaping im Zugriffsprotokoll von NGINX Plus deaktivieren. Der neue Parameter „escape=none“ für die Direktive „log_format“, der erstmals in NGINX Open Source 1.13.10 eingeführt wurde, legt fest, dass Sonderzeichen in Variablen nicht maskiert werden.

Aktualisierung der LDAP-Authentifizierungsreferenzimplementierung

Unsere Referenzimplementierung für die Authentifizierung von Benutzern über ein LDAP-Authentifizierungssystem wurde aktualisiert, um Probleme zu beheben und Fehler zu korrigieren. Sehen Sie sie sich auf GitHub an.

Transparentes Proxying ohne root-Berechtigung

Sie können NGINX Plus als transparenten Proxy verwenden, indem Sie den Parameter „transparent“ in die Direktive „proxy_bind“ aufnehmen. Worker-Prozesse können nun die Linux-Capability „CAP_NET_RAW“ vom Master-Prozess übernehmen, sodass NGINX Plus für transparentes Proxying keine besonderen Berechtigungen mehr benötigt.

Hinweis: Diese Funktion gilt nur für Linux-Plattformen.

JWT-Toleranzzeitraum

Wenn ein JWT einen zeitbasierten Anspruch enthält – nbf (frühester Gültigkeitszeitpunkt), exp (Ablaufzeitpunkt) oder beides –, prüft NGINX Plus bei der Validierung des JWT, ob die aktuelle Uhrzeit innerhalb des angegebenen Zeitintervalls liegt. Wenn die Uhr des Identitätsanbieters jedoch nicht mit der Uhr der NGINX Plus-Instanz synchronisiert ist, können Token unerwartet ablaufen oder den Anschein erwecken, erst in der Zukunft gültig zu werden. Um die maximal zulässige Abweichung zwischen den beiden Uhren festzulegen, verwenden Sie die Direktive auth_jwt_leeway.

Dynamisches Modul für Cookie-Flags

Das Drittanbietermodul zum Festlegen von Cookie-Flags ist jetzt als dynamisches Modul Cookie-Flag im NGINX-Repository verfügbar und durch Ihren NGINX Plus-Supportvertrag abgedeckt. Sie können es mit Ihrem Paketverwaltungstool installieren:

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

Aktualisierung des NGINX ModSecurity WAF-Moduls

NGINX ModSecurity WAF, ein auf ModSecurity 3.0 basierendes dynamisches Modul für NGINX Plus, wurde um die folgenden Verbesserungen erweitert:

• Leistungsverbesserungen in libmodsecurity
• Behebung von Speicherlecks in ModSecurity-nginx

[Redaktion – Der Verkauf von NGINX ModSecurity WAF wurde zum 1. April 2022 offiziell eingestellt. Das Produkt erreicht mit Wirkung zum 31. März 2024 sein Lebenszyklusende. Weitere Informationen finden Sie im Beitrag F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> in unserem Blog.]

Upgraden oder NGINX Plus testen

NGINX Plus R15 bietet verbesserte Authentifizierungsfunktionen für Ihre Clientanwendungen, zusätzliche Clustering-Funktionen, njs-Verbesserungen und wichtige Fehlerbehebungen.

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf Release 15 durchzuführen. Dadurch erhalten Sie eine Reihe von Fehlerbehebungen und Verbesserungen. Außerdem können wir Sie nach dem Upgrade besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen. Anweisungen zur Installation und zum Upgrade von NGINX Plus R15 finden Sie im Kundenportal.

Bitte lesen Sie sich die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig durch, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plus noch nicht verwendet haben, empfehlen wir Ihnen, es auszuprobieren – zur Webbeschleunigung, zum Load Balancing und zur Anwendungsbereitstellung oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute kostenlos 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