Ankündigung von NGINX Plus R14

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 14 (R14) jetzt für unsere NGINX Plus-Abonnenten verfügbar ist. NGINX Plus ist der einzige All-in-One-Load Balancer, Inhaltscache und Webserver. Es basiert auf NGINX Open Source und bietet exklusive Funktionen sowie preisgekrönten 24-Stunden-Support . NGINX Plus R14 enthält neue Sicherheits- und Clustering-Verbesserungen.

Mit NGINX Plus können Sie Zugriffskontrollen mithilfe von JSON Web Tokens (JWTs) erzwingen. NGINX Plus R14 fügt Unterstützung für verschachtelte JWT-Ansprüche hinzu, sodass Sie den Zugriff basierend auf den in einem JWT verschachtelten Gruppenmitgliedschaftsinformationen gewähren oder verweigern können. Die native JWT-Authentifizierungsunterstützung, die erstmals in NGINX Plus R10 eingeführt wurde, ermöglicht die Verwendung von NGINX Plus als Authentifizierungs-Gateway für Ihre APIs und Anwendungen.

Zu den zusätzlichen Funktionen von NGINX Plus R14 gehören:

• Erweiterte Cluster-Unterstützung (Technologievorschau) – Wir laden Sie ein, eine Vorschau der neuen Funktion zum Teilen von Statusinformationen zwischen den NGINX Plus-Instanzen in einem Cluster zu testen. In der Vorschau wird der Status für die Sticky-Learn- Sitzungspersistenzmethode freigegeben. In zukünftigen Versionen werden wir die Cluster-Unterstützung auf andere NGINX Plus-Funktionen ausweiten.
• Längere JWT-Schlüsselgrößen – Zusätzlich zur Unterstützung für verschachtelte JWT-Ansprüche und Array-Daten werden jetzt längere Schlüsselgrößen (bis zu 512 Bit) für JWT-Signaturalgorithmen unterstützt. Dies bietet mehr Sicherheit und Flexibilität bei der Validierung von JWTs.
• Stream-Schlüsselwertspeicher und API – Der leistungsstarke Schlüsselwertspeicher und die API, die in Release 13 für HTTP-Anwendungen eingeführt wurden, werden auf TCP- und UDP-Anwendungen im Stream -Kontext erweitert.
• Verbesserungen am NGINX JavaScript-Modul – Das Modul, mit dem Sie JavaScript-Code auf NGINX Plus ausführen können, bietet jetzt zusätzliche Sprachunterstützung für das JSON-Objekt. [Das Modul hieß früher nginScript.] Damit können Sie Informationen aus JSON-Antworten analysieren und extrahieren, die Sie nativ von Backend-APIs erhalten haben, und Methoden im Node.js-Stil verwenden, um auf Ihr Dateisystem zuzugreifen. Das Modul bietet jetzt auch Backtraces für eine breite Palette von Ausnahme- und Fehlerobjekten, wenn diese auftreten, um das Debuggen und die Fehlerbehebung zu erleichtern.
• Weitere Funktionen – NGINX Plus bietet außerdem ein aktualisiertes Dashboard zur Live-Aktivitätsüberwachung, eine neue SSL-Variable und Upstream-Server-Draining.

Verhaltensänderungen

• Die NGINX Plus API wurde auf Version 2 aktualisiert. Überprüfen Sie die API-Kompatibilitätsdokumentation , wenn Sie die Verwendung neuer NGINX Plus-API-Funktionen in Erwägung ziehen.
• Die APIs in den Modulen Upstream-Conf und erweiterter Status (aktiviert mit den Anweisungen upstream_conf und status ) sind ab NGINX Plus R13 veraltet. Sie wurden durch die neue NGINX Plus API ersetzt, die vom aktualisierten Dashboard zur Live-Aktivitätsüberwachung verwendet wird, das in R14 enthalten ist.
• NGINX Plus ist jetzt für Ubuntu 17.10 (Artful Aardvark) verfügbar.
• NGINX Plus wird unter Debian 7 (Wheezy) nicht mehr unterstützt.

NGINX Plus R14 Funktionen im Detail

JWT-Erweiterungen

Anbieter von APIs und Microservices greifen aufgrund seiner Einfachheit und Flexibilität auf den JSON Web Token-Standard (JWT, ausgesprochen „jot“) zurück. Ein JWT ist ein kompaktes und äußerst portables Mittel zum Austausch von Identitätsinformationen. Sie können JWTs von einer Reihe von Herausgebern beziehen, darunter Okta, OneLogin und selbst entwickelte Lösungen. NGINX Plus kann dann den Zugriff gewähren oder verweigern, je nachdem, ob der Benutzer oder API-Client ein gültiges JWT vorgelegt hat oder nicht.

NGINX Plus R14 fügt Unterstützung für verschachtelte JWT-Ansprüche und Array-Daten sowie längere Schlüsselgrößen für JWT-Signaturalgorithmen hinzu. Dies bietet mehr Flexibilität und höhere Sicherheit bei der Validierung von JWTs.

Unterstützung für verschachtelte JWT-Ansprüche und Array-Daten

Eine JWT-Nutzlast kann zusätzliche „verschachtelte“ Informationen über den Benutzer enthalten, z. B. die Gruppenmitgliedschaft, die zum Autorisieren des Zugriffs auf eine Ressource verwendet werden kann. Dadurch wird vermieden, dass zur Autorisierung von Benutzeranforderungen mehrere Datenbankabfragen erforderlich sind.

Betrachten Sie die folgende JWT-Nutzlast:

{ "exp": 1513429677,
"sub": "xample@example.com",
"aud": "nginx",
"attributes": {
"name": "Xavier Ample",
"Zimmer": "A123",
"Abteilung": "Demonstrationen"
},
"Gruppen": [
"Administrator",
"Foobar",
"Bazpub"
]
}

Im obigen JWT sind Attribute ein „verschachteltes Anspruchs“-Objekt und Gruppen ein Array. Mit dem folgenden Konfigurationsausschnitt können Sie den Namenswert vom Attributobjekt an das Backend übergeben und Benutzern, die nicht zur Administratorgruppe gehören, den Zugriff verweigern.

auth_jwt_claim_set $jwt_groups groups; # Array-Wert wird als Komma-getrennte Werte verbundenauth_jwt_claim_set $jwt_real_name attribute name; # Dieser Wert ist zwei Ebenen tief

map $jwt_groups $isAdmin {
"~\bAdministrator\b" 1; # Erscheint innerhalb der Wortgrenzen (\b) der CSV-Liste
default 0;
}

server {
listen 443 ssl;
#ssl_*; # Konfiguration für SSL/TLS-Beendigung

auth_jwt "closed site";
auth_jwt_key_file jwk.json;

location / {
proxy_set_header X-RealName $jwt_real_name; # Realnamen als Header übergeben
proxy_set_header X-Subject $jwt_claim_sub; # L1-Ansprüche automatisch gesetzt
proxy_pass http://my_backend;
}

location /admin {
if ( $isAdmin = 0 ) {
return 403; # Verboten
}
proxy_pass http://my_backend;
}
}

Hier finden Sie weitere Einzelheiten zur Funktionsweise dieser Konfiguration:

• Mithilfe der Direktive „auth_jwt_claim_set“ setzen wir die NGINX-Variable „$jwt_groups“ auf das im JWT definierte Gruppen- Array. Die Werte im Array werden durch Kommas getrennt und $jwt_groups zugewiesen.
• Mithilfe der Map- Direktive durchsuchen wir die Gruppenliste nach dem Schlüsselwort „Administrator“ . Wenn es vorhanden ist, wird der Benutzer als Administrator betrachtet und $isAdmin wird auf 1 gesetzt. Andernfalls wird $isAdmin auf 0 gesetzt.
• Der Standortblock für die /admin- URI überprüft die Variable $isAdmin . Wenn 0, gibt NGINX den Statuscode zurück 403 Verboten zurück zum Kunden.

Mit NGINX Plus R14 können Sie auch Variablen aus verschachtelten JWT-Ansprüchen erstellen. Die Variablen können dann in HTTP-Header eingefügt werden, bevor sie per Proxy an Backend-Server weitergeleitet werden.

Im obigen Beispiel verwenden wir die Direktive auth_jwt_claim_set , um die NGINX-Variable $jwt_real_name auf den Wert des Namensobjekts innerhalb des Attributanspruchs zu setzen. Die Direktive proxy_set_header setzt den X-RealName -HTTP-Header auf den Wert des Namensobjekts und leitet die Anforderung an my_backend weiter.

Weitere Informationen zu allen Konfigurationsdirektiven, die zur Authentifizierung von JWTs mit NGINX Plus verfügbar sind, finden Sie in der Referenzdokumentation .

Längere Schlüsselgrößen für JWT-Signaturalgorithmen

NGINX Plus R14 unterstützt jetzt 256-Bit-, 384-Bit- und 512-Bit-Signaturschlüssel für eine stärkere Signaturvalidierung und einfachere Integration mit Identitäts- und Zugriffsverwaltungsprodukten (IAM), die standardmäßig längere Signaturschlüssel verwenden. Die längeren Signaturschlüssel sind für alle unterstützten Signaturalgorithmen verfügbar:

• HMAC mit SHA‑2 („HS“)
• RSA PKCS #1 mit SHA‑2 („RS“)
• Algorithmus für digitale Signaturen mit elliptischen Kurven („ES“)

Sie können beispielsweise NGINX Plus R14 so konfigurieren, dass nur JSON-Web-Token akzeptiert werden, die mit dem RS512-Algorithmus signiert sind:

server { listen 443 ssl;
#ssl_*; # Konfiguration für SSL/TLS-Beendigung

auth_jwt „geschlossene Site“;
auth_jwt_key_file jwk.json;

location / {
if ( $jwt_header_alg != RS512 ) {
return 401;
}
proxy_pass http://my_backend;
}
}

In diesem Fall leitet NGINX Plus keine Anfragen weiter, wenn das JWT nicht mit dem RS512-Algorithmus signiert wurde, und gibt den Statuscode 401 Nicht autorisiert an den Client, der die Anfrage gestellt hat.

Notiz : JWT-Unterstützung ist exklusiv für NGINX Plus.

Key-Value-Store und API für das Stream-Modul

NGINX Plus R13 hat das Key-Value Store-Modul für HTTP eingeführt, mit dem Sie Schlüssel-Wert-Paare in einer oder mehreren gemeinsam genutzten Speicherzonen im laufenden Betrieb erstellen, ändern und löschen können. Ein großartiger Anwendungsfall für die Key‑Value‑Store‑API ist die Verwendung mit fail2ban zum Erstellen einer dynamischen IP‑Sperrliste .

NGINX Plus R14 fügt das Key-Value Store-Modul für Stream hinzu, wodurch für TCP- und UDP-Anwendungen dieselben Schlüssel-Wert-Paar-Funktionen verfügbar werden wie für HTTP-Apps.

Die dynamische Neukonfiguration des Schlüssel-Wert-Speichers im Stream -Kontext ist in NGINX Plus R14 als Teil der NGINX Plus-API implementiert.

Notiz : Der Schlüssel-Wert-Speicher und die API sind exklusiv für NGINX Plus.

Verbesserungen am NGINX JavaScript-Modul

Das NGINX JavaScript-Modul (früher nginScript genannt) ist eine JavaScript-basierte Skriptsprache für NGINX Plus. In NGINX Plus R14 wurden die Funktionen von NGINX JavaScript erweitert, um die Programmierbarkeit weiter zu verbessern. Das aktualisierte dynamische NGINX JavaScript-Modulpaket bietet die folgenden neuen Verbesserungen.

JSON-Objekt-Unterstützung

Das JavaScript-JSON-Objekt ist jetzt als natives Objekt in NGINX JavaScript verfügbar. Dies bietet eine bequemere Möglichkeit, komplexe Datenstrukturen zu verwalten, und ermöglicht NGINX-JavaScript außerdem, von Back-End-APIs empfangene JSON-Antworten zu analysieren und zu bearbeiten.

Das folgende NJS- Shell-Beispiel zeigt, wie JSON-Daten mithilfe der integrierten Objektsyntax analysiert und extrahiert werden.

$ njsinteraktives njscript

v.<Tab> -> die Eigenschaften und Prototypmethoden von v.
Geben Sie console.help() ein, um weitere Informationen zu erhalten

>> var my_data = '{"colors":[{"name":"rot","fancy":"Ziegelstaub"}, {"name":"blau","fancy":"Gischt"}]}';
>> var mein_Objekt = JSON.parse(meine_Daten);
>> mein_Objekt.Farben[1].fancy;
Gischt
>>

Dateisystemzugriff

Node.js, die beliebteste serverseitige JavaScript-Implementierung, bietet integrierte Methoden für den Zugriff auf das Dateisystem des Betriebssystems (clientseitiges JavaScript erlaubt keinen Dateisystemzugriff). Mit NGINX Plus R14 können Sie jetzt Node.js-Dateisystemmethoden in NGINX JavaScript zum Lesen und Schreiben von Dateien verwenden und so Ihren Anwendungsbereitstellungs-Workflow anpassen. Folgende Operationen sind zulässig:

• Lesen – fs.readFile , fs.readFileSync
• Schreiben – fs.writeFile , fs.writeFileSync
• Anhängen – fs.appendFile , fs.appendFileSync

Dieses Beispiel einer NGINX-JavaScript-Shell zeigt, wie NGINX-JavaScript verwendet werden kann, um Dateiinhalte in eine Variable zu lesen.

$ njsinteraktives njscript

v.<Tab> -> die Eigenschaften und Prototypmethoden von v.
Geben Sie console.help() ein, um weitere Informationen zu erhalten

>> var fs = erfordern('fs');
>> var tz = fs.readFileSync('/etc/timezone');
>> tz
Europa/London
>>

Fehlerobjekte und Backtraces

Um Entwicklern bei der Fehlersuche und Problembehandlung weiter zu helfen, steht jetzt eine breite Palette von Fehlerobjekten zur Verfügung:

• Fehler
• Fehlerauswertung
• Interner Fehler
• Bereichsfehler
• ReferenzFehler
• Syntaxfehler
• TypFehler
• URIError

Darüber hinaus bietet NGINX JavaScript jetzt Backtraces für Fehler und Ausnahmen. Der folgende Eintrag aus dem Fehlerprotokoll zeigt einen einfachen Backtrace für einen fehlgeschlagenen Systemvorgang.

12.12.2017 01:52:08 [Fehler] 43441#43441: *10 js-Ausnahme: Fehler: Keine solche Datei oder kein solches Verzeichnis bei native (native)
bei my_function (:1)
bei main (native)
, Client: 127.0.0.1, Server:, Anfrage: "GET / HTTP/1.1", Host: "localhost:80"

Erfahren Sie in unserem Blog, wie Sie mit NGINX JavaScript<.htmla> beginnen.

NGINX Plus-Dashboard mit der NGINX Plus-API

NGINX Plus R13 führte die NGINX Plus API ein, die Zugriff auf Echtzeitüberwachung und Metriken in einem JSON-Format bietet. In NGINX Plus R14 verwendet das integrierte Dashboard zur Live-Aktivitätsüberwachung jetzt die NGINX Plus-API und stellt dem Benutzer mehr als 80 Überwachungsmetriken in Echtzeit zur Verfügung.

Die vom Dashboard in früheren Versionen von NGINX Plus verwendeten APIs zur dynamischen Neukonfiguration und zum erweiterten Status sind veraltet. Die APIs sind in dieser Version weiterhin verfügbar und werden in NGINX Plus R15 enthalten sein. Sie werden mit NGINX Plus R16 vollständig entfernt, daher empfehlen wir Ihnen, Ihre Konfigurationen jetzt zu aktualisieren.

Die Konfiguration für das veraltete Dashboard sieht folgendermaßen aus:

location /status { # VERALTET status; # VERALTET
# Anweisungen zur Zugriffskontrolle, wie „allow“ und „deny“
}

location = /status.html { # VERALTET
root /usr/share/nginx/html; # VERALTET
}

Um Ihre vorhandenen NGINX Plus-Instanzen auf das neue NGINX Plus-Dashboard zu migrieren, ersetzen Sie den vorherigen Snippet durch Folgendes:

location /api { api write=on;
# Anweisungen zur Zugriffssteuerung, wie „allow“ und „deny“
}

location = /dashboard.html {
root /usr/share/nginx/html;
}

# Anfragen an das alte Dashboard umleiten
location = /status.html {
return 301 /dashboard.html;
}

Wie in den Snippets gezeigt, empfehlen wir dringend, den Zugriff auf die API einzuschränken, beispielsweise mit Allow- und Deny -Direktiven. Denken Sie daran, vorhandene Zugriffskontrollen vom Speicherort „/status“ zum Speicherort „/api“ zu migrieren.

Weitere Informationen zur neuen NGINX Plus API finden Sie in der NGINX Plus R13 -Ankündigung .

Notiz : Das integrierte Dashboard ist exklusiv für NGINX Plus.

Upstream-Server in der Konfigurationsdatei entleeren

Wenn Sie einen Server offline schalten, können Sie die Benutzererfahrung verbessern, indem Sie das Abschließen bestehender Sitzungen zulassen und gleichzeitig das Einrichten neuer Sitzungen verhindern. Der Server geht erst offline, wenn keine aktiven Sitzungen mehr vorhanden sind. Dies wird als Entleeren des Servers bezeichnet. Sie können dies dynamisch mit der NGINX Plus-API tun, indem Sie eine PATCH -Anfrage, die {"drain":true} enthält, an die API-Ressource für den entsprechenden Server senden.

NGINX Plus R14 erweitert diese Funktionalität auf die dateibasierte Konfiguration, indem es der Upstream- Serverdirektive einen Drain -Parameter bereitstellt.

upstream my_backend { Server 10.0.0.1;
Server 10.0.0.2;
Server 10.0.0.3 drain;
}

Wenn Sie die NGINX Plus-Konfiguration neu laden, wechselt der Upstream-Server mit der IP 10.0.0.3 in den Draining-Modus. Sie können den Server später vollständig außer Betrieb nehmen, indem Sie die entsprechende Serverdirektive entfernen oder den Draining- Parameter durch down ersetzen.

Clustering-Unterstützung für Sticky Learn (Technologievorschau)

Wir freuen uns, mit NGINX Plus R14 eine Technologievorschau einer kommenden Funktion zum Teilen von Zuständen über einen Cluster von NGINX Plus-Instanzen hinweg ankündigen zu können. Die Technologievorschau implementiert die Sticky-Learn -Methode der Sitzungspersistenz, um die Vorteile der gemeinsamen Nutzung von Sitzungsdaten zu demonstrieren, die andernfalls von jeder Instanz einzeln verwaltet werden müssten.

Die Technologievorschau wird als separates installierbares Paket bereitgestellt und ist auf Anfrage erhältlich. Für den Zugriff wenden Sie sich bitte an Ihren NGINX-Vertriebsmitarbeiter.

Hinweise:

1. Die Sticky-Learn-Clustering-Funktionalität befindet sich im Vorschaustatus und ist daher nicht für den Einsatz in der Produktion geeignet. Wenn die Statusfreigabe über einen Cluster hinweg eine wichtige Anforderung für Ihre Umgebung ist, empfehlen wir Ihnen, die Technologievorschau zu testen und NGINX Feedback dazu zu geben, inwieweit sie Ihren Anforderungen entspricht.
2. Technologievorschau-Pakete sind für CentOS/RHEL/Oracle Linux 7, Debian 8 und 9 sowie Ubuntu 16.04, 16.10 und 17.10 verfügbar.

Notiz : Clustering-Unterstützung und Sticky-Learn-Sitzungspersistenz sind beide exklusiv für NGINX Plus.

Zusätzliche Merkmale

NGINX Plus R14 enthält außerdem die folgenden Verbesserungen:

• Persistenz des Resolver-Status über Neuladungen hinweg – Eine Möglichkeit, den Serversatz in einer Upstream-Gruppe dynamisch neu zu konfigurieren, besteht darin, einen Hostnamen oder eine Domäne als Parameter für die Serverdirektive zu verwenden. DNS löst den Namen regelmäßig auf und NGINX Plus verwendet automatisch den überarbeiteten Serversatz (siehe NGINX Plus-Administratorhandbuch ). NGINX Plus behält jetzt die DNS-Einträge für den Hostnamen oder Domänennamen über einen Neuladevorgang von NGINX Plus hinweg bei. Bisher musste der Name nach einem Neuladen erneut aufgelöst werden, was bedeutete, dass Anfragen, die vor Abschluss der Auflösung eingingen, nicht bearbeitet werden konnten.
• Neue SSL-Client-Zertifikatvariable – Die Variable $ssl_client_escaped_cert ist eine neue eingebettete NGINX-Variable, die Ihnen eine sichere und bequeme Möglichkeit bietet, Ihre Client-Zertifikate in einem HTTP-Header zu kodieren, damit Sie sie an Ihre Backend-Anwendungen senden können. Die Variable ist URL-codiert.

Upgrade oder Testen von NGINX Plus

NGINX Plus R14 enthält verbesserte Authentifizierungsfunktionen für Ihre Clientanwendungen, zusätzliche Clustering-Funktionen, NGINX JavaScript-Erweiterungen und wichtige Fehlerbehebungen . Insbesondere wurde mit NGINX Plus R13 ein Fehler bei aktiven Integritätsprüfungen eingeführt, bei dem ein alter Arbeitsprozess Integritätsprüfungen auf unbestimmte Zeit durchführen konnte. Dies wurde mit NGINX Plus R14 behoben.

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 14 zu aktualisieren. Sie erhalten eine Reihe von Fehlerbehebungen und Verbesserungen und durch das Upgrade kann NGINX Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen. Installations- und Upgrade-Anweisungen sind im Kundenportal verfügbar.

Bitte überprüfen Sie die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – zur Webbeschleunigung, zum Lastenausgleich und zur Anwendungsbereitstellung oder als vollständig unterstützter Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute kostenlos mit einer 30-tägigen Testversion beginnen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.