Ankündigung von NGINX Plus R14

NGINX | 12. Dezember 2017

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 14 (R14) ab sofort für unsere Abonnenten von NGINX Plus verfügbar ist. NGINX Plus ist der einzige All-in-One-Load-Balancer, Content-Cache und Webserver. Es basiert auf NGINX Open Source und bietet zusätzlich exklusive Funktionen sowie einen preisgekrönten Rund-um-die-Uhr-Support. NGINX Plus R14 umfasst neue Verbesserungen in den Bereichen Sicherheit und Clustering.

Mit NGINX Plus können Sie Zugriffskontrollen mithilfe von JSON Web Tokens (JWTs) durchsetzen. NGINX Plus R14 bietet nun Unterstützung für verschachtelte JWT-Claims, sodass Sie den Zugriff anhand von Informationen zur Gruppenzugehörigkeit gewähren oder verweigern können, die in einem JWT verschachtelt sind. Die native Unterstützung für die JWT-Authentifizierung, die erstmals in NGINX Plus R10 eingeführt wurde, ermöglicht den Einsatz von NGINX Plus als Authentifizierungs-Gateway für Ihre APIs und Anwendungen.

Weitere Funktionen von NGINX Plus R14 sind:

Erweiterte Clustering-Unterstützung (Technologievorschau) – Wir laden Sie ein, eine Vorschau der neuen Funktionalität zur gemeinsamen Nutzung von Statusinformationen durch die NGINX Plus-Instanzen in einem Cluster zu testen. In dieser Vorschau wird der Status für die Sitzungspersistenzmethode „sticky learn“ gemeinsam genutzt. In zukünftigen Versionen werden wir die Clustering-Unterstützung auf weitere Funktionen von NGINX Plus ausweiten.
Längere JWT-Schlüssel – Neben verschachtelten JWT-Claims und Array-Daten unterstützen JWT-Signaturalgorithmen jetzt auch längere Schlüssel mit bis zu 512 Bit. Dies bietet mehr Sicherheit und Flexibilität bei der Validierung von JWTs.
Schlüssel-Wert-Speicher und API für Stream – Der leistungsstarke Schlüssel-Wert-Speicher samt API, der mit Release 13 für HTTP-Anwendungen eingeführt wurde, steht nun auch TCP- und UDP-Anwendungen im stream-Kontext zur Verfügung.
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 von Backend-APIs nativ parsen und extrahieren sowie mit Methoden im Node.js-Stil auf Ihr Dateisystem zugreifen. Das Modul stellt nun außerdem bei einer Vielzahl von Ausnahme- und Fehlerobjekten Backtraces bereit, um die Fehlersuche und Problembehebung zu erleichtern.
Weitere Funktionen – NGINX Plus bietet außerdem ein aktualisiertes Dashboard zur Überwachung der Live-Aktivitäten, eine neue SSL-Variable und die Möglichkeit, Upstream-Server kontrolliert aus dem Betrieb zu nehmen.

Verhaltensänderungen

Die NGINX Plus API wurde auf Version 2 aktualisiert. Lesen Sie die Dokumentation zur API-Kompatibilität, wenn Sie die Verwendung neuer Funktionen der NGINX Plus API in Betracht ziehen.
Die APIs in den Modulen Upstream-Conf und Extended Status (aktiviert mit den Direktiven „upstream_conf“ und „status“) gelten seit NGINX Plus R13 als veraltet. Sie wurden durch die neue NGINX Plus API ersetzt, die vom aktualisierten, in R14 enthaltenen Dashboard zur Überwachung der Live-Aktivität verwendet wird.
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-Verbesserungen

Betreiber von APIs und Microservices setzen aufgrund seiner Einfachheit und Flexibilität zunehmend auf den Standard JSON Web Token (JWT, ausgesprochen „Jot“). Ein JWT ist ein kompaktes und äußerst portables Mittel zum Austausch von Identitätsinformationen. JWTs können von verschiedenen Ausstellern bezogen werden, darunter Okta, OneLogin und selbst entwickelte Lösungen. NGINX Plus kann den Zugriff dann abhängig davon gewähren oder verweigern, ob der Benutzer oder API-Client ein gültiges JWT vorgelegt hat.

NGINX Plus R14 unterstützt nun verschachtelte JWT-Claims und Array-Daten sowie längere Schlüssel für JWT-Signaturalgorithmen. Dies bietet mehr Flexibilität und höhere Sicherheit bei der Validierung von JWTs.

Unterstützung für verschachtelte JWT-Claims und Array-Daten

Eine JWT-Nutzlast kann zusätzliche „verschachtelte“ Informationen über den Benutzer enthalten, beispielsweise Gruppenzugehörigkeiten, die zur Autorisierung des Zugriffs auf eine Ressource verwendet werden können. Dadurch muss eine Datenbank nicht mehrfach abgefragt werden, um Benutzeranfragen zu autorisieren.

Betrachten Sie die folgende JWT-Nutzlast:

{  "exp": 1513429677,
  "sub": "xample@example.com",
  "aud": "nginx",
  "attributes": {
    "name": "Xavier Ample",
    "room": "A123",
    "dept": "Demonstrations"
  },
  "groups": [
    "Administrator",
    "Foobar",
    "Bazpub"
  ]
}

Im obigen JWT ist attributes ein Objekt mit einem „verschachtelten Claim“ und groups ein Array. Mit dem folgenden Konfigurationsausschnitt können Sie den Wert name aus dem Objekt attributes an das Backend übergeben und Benutzern den Zugriff verweigern, die nicht der Gruppe Administrator angehören.

auth_jwt_claim_set $jwt_groups groups; # Array value will join as comma-separated valuesauth_jwt_claim_set $jwt_real_name attributes name; # This value is two levels deep

map $jwt_groups $isAdmin {
	"~\bAdministrator\b" 1; # Appears within word boundaries (\b) of CSV list
	default              0;
}

server {
    listen 443 ssl;
    #ssl_*; # Config for SSL/TLS termination

    auth_jwt "closed site";
    auth_jwt_key_file jwk.json;

    location / {
        proxy_set_header X-RealName $jwt_real_name; # Pass real name as header
        proxy_set_header X-Subject  $jwt_claim_sub; # L1 claims set automatically
        proxy_pass http://my_backend;
    }
 
    location /admin {
        if ( $isAdmin = 0 ) {
            return 403; # Forbidden
        }
        proxy_pass http://my_backend;
    }
}

Hier finden Sie weitere Details zur Funktionsweise dieser Konfiguration:

Mit der Direktive „auth_jwt_claim_set“ setzen wir die NGINX-Variable $jwt_groups auf das im JWT definierte Array groups. Die Werte im Array werden durch Kommas getrennt und $jwt_groups zugewiesen.
Mit der map-Direktive durchsuchen wir die Liste der Gruppen nach dem Schlüsselwort Administrator. Ist es vorhanden, wird der Benutzer als Administrator eingestuft und $isAdmin auf 1 gesetzt. Andernfalls wird $isAdmin auf 0 gesetzt.
Der location-Block für den /admin-URI überprüft die Variable $isAdmin. Ist ihr Wert 0, gibt NGINX den Statuscode 403 Forbidden an den Client zurück.

Mit NGINX Plus R14 können Sie auch Variablen aus verschachtelten JWT-Claims erstellen. Diese Variablen können anschließend in HTTP-Header eingefügt werden, bevor die Anfragen 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 Objekts name innerhalb des Claims attributes zu setzen. Die Direktive proxy_set_header setzt den HTTP-Header X-RealName auf den Wert des Objekts name und leitet die Anfrage per Proxy an my_backend weiter.

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

Längere Schlüssellängen für JWT-Signaturalgorithmen

NGINX Plus R14 unterstützt jetzt 256‑Bit-, 384‑Bit- und 512‑Bit-Signaturschlüssel für eine zuverlässigere Signaturvalidierung und eine einfachere Integration mit Identity-and-Access-Management-Produkten (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“)
Digitaler Signaturalgorithmus mit elliptischen Kurven („ES“)

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

server {    listen 443 ssl;
    #ssl_*; # Config for SSL/TLS termination

    auth_jwt "closed 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 Anfragen nicht über den Proxy weiter, wenn das JWT nicht mit dem RS512-Algorithmus signiert wurde, und gibt den Statuscode 401 Unauthorized an den Client zurück, der die Anfrage gesendet hat.

Hinweis: JWT-Unterstützung ist ausschließlich in NGINX Plus verfügbar.

Schlüssel-Wert-Speicher und API für das Stream-Modul

Mit NGINX Plus R13 wurde das Key-Value-Store-Modul für HTTP eingeführt, mit dem Sie Schlüssel-Wert-Paare in einer oder mehreren gemeinsam genutzten Speicherzonen dynamisch erstellen, ändern und löschen können. Ein hervorragender Anwendungsfall für die Key-Value-Store-API ist die Verwendung mit fail2ban, um eine dynamische IP-Sperrliste zu erstellen.

NGINX Plus R14 ergänzt das Key-Value-Store-Modul für Stream, sodass für TCP- und UDP-Anwendungen dieselben Schlüssel-Wert-Paar-Funktionen wie für HTTP-Anwendungen verfügbar sind.

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

Hinweis: Der Schlüssel-Wert-Speicher und die API sind ausschließlich in NGINX Plus verfügbar.

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 Paket des dynamischen NGINX JavaScript-Moduls bietet die folgenden neuen Verbesserungen.

Unterstützung für JSON-Objekte

Das JavaScript-JSON-Objekt ist jetzt als natives Objekt in NGINX JavaScript verfügbar. Dadurch lassen sich komplexe Datenstrukturen komfortabler verwalten. Außerdem kann NGINX JavaScript damit JSON-Antworten von Backend-APIs parsen und bearbeiten.

Das folgende njs-Shell-Beispiel zeigt, wie sich JSON-Daten mithilfe der integrierten Objektsyntax parsen und extrahieren lassen.

$ njsinteractive njscript

v.<Tab> -> the properties and prototype methods of v.
type console.help() for more information

>> var my_data = '{"colors":[{"name":"red","fancy":"brick dust"}, {"name":"blue","fancy":"sea spray"}]}';
>> var my_object = JSON.parse(my_data);
>> my_object.colors[1].fancy;
sea spray
>>

Dateisystemzugriff

Node.js, die beliebteste serverseitige JavaScript-Implementierung, bietet integrierte Methoden für den Zugriff auf das Dateisystem des Betriebssystems (clientseitiges JavaScript erlaubt keinen Zugriff auf das Dateisystem). Mit NGINX Plus R14 können Sie jetzt die Dateisystemmethoden von Node.js in NGINX JavaScript verwenden, um Dateien zu lesen und zu schreiben und so den Workflow für die Bereitstellung Ihrer Anwendung anzupassen. Die folgenden Vorgänge sind zulässig:

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

Dieses Beispiel für die NGINX-JavaScript-Shell zeigt, wie sich mit NGINX JavaScript der Inhalt einer Datei in eine Variable einlesen lässt.

$ njsinteractive njscript

v.<Tab> -> the properties and prototype methods of v.
type console.help() for more information

>> var fs = require('fs');
>> var tz = fs.readFileSync('/etc/timezone');
>> tz
Europe/London
>>

Fehlerobjekte und Stacktraces

Um Entwickler bei der Fehlersuche und -behebung noch besser zu unterstützen, steht nun eine Vielzahl von Fehlerobjekten zur Verfügung:

Fehler
EvalError
InternalError
RangeError
ReferenceError
SyntaxError
TypeError
URIError

Darüber hinaus stellt NGINX JavaScript jetzt Rückverfolgungen für Fehler und Ausnahmen bereit. Der folgende Eintrag aus dem Fehlerprotokoll zeigt eine einfache Rückverfolgung für einen fehlgeschlagenen Systemvorgang.

2017/12/12 01:52:08 [error] 43441#43441: *10 js exception: Error: No such file or directory    at native (native)
    at my_function (:1)
    at main (native)
, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "localhost:80"

Erfahren Sie, wie Sie mit NGINX JavaScript<.htmla> loslegen können – in unserem Blog.

NGINX Plus-Dashboard unter Verwendung der NGINX Plus-API

Mit NGINX Plus R13 wurde die NGINX Plus API eingeführt, die den Zugriff auf Echtzeitüberwachung und Metriken im JSON-Format ermöglicht. In NGINX Plus R14 verwendet das integrierte Dashboard zur Überwachung von Live-Aktivitäten nun die NGINX Plus API und stellt Benutzern mehr als 80 Überwachungsmetriken in Echtzeit zur Verfügung.

Die APIs für die dynamische Neukonfiguration und den erweiterten Status, die vom Dashboard in früheren Versionen von NGINX Plus verwendet wurden, sind veraltet. Die APIs sind in dieser Version weiterhin verfügbar und werden auch in NGINX Plus R15 enthalten sein. Mit NGINX Plus R16 werden sie vollständig entfernt. Daher empfehlen wir Ihnen, Ihre Konfigurationen jetzt zu aktualisieren.

Die Konfiguration für das veraltete Dashboard sieht wie folgt aus:

location /status { # DEPRECATED    status;        # DEPRECATED
    # directives controlling access, such as 'allow' and 'deny'
}

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

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

location /api {    api write=on;
    # directives controlling access, such as 'allow' and 'deny'
}

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

# Redirect requests made to the old dashboard
location = /status.html {
    return 301 /dashboard.html;
}

Wie in den Codeausschnitten gezeigt, empfehlen wir dringend, den Zugriff auf die API einzuschränken, beispielsweise mit den Direktiven „allow“ und „deny“. Stellen Sie sicher, dass Sie bestehende Zugriffskontrollen vom Speicherort „/status“ zum Speicherort „/api“ migrieren.

Weitere Informationen zur neuen NGINX Plus API finden Sie in der NGINX Plus R13 announcement.

Hinweis: Das integrierte Dashboard ist ausschließlich in NGINX Plus verfügbar.

Upstream-Server in der Konfigurationsdatei auslaufen lassen

Wenn Sie einen Server außer Betrieb nehmen, können Sie die Benutzerfreundlichkeit verbessern, indem Sie bestehende Sitzungen abschließen lassen und gleichzeitig verhindern, dass neue Sitzungen aufgebaut werden. Der Server wird erst außer Betrieb genommen, wenn keine aktiven Sitzungen mehr vorhanden sind. Dieser Vorgang wird als Draining des Servers bezeichnet. Sie können dies dynamisch über die NGINX Plus API durchführen, indem Sie eine PATCH-Anfrage mit {"drain":true} an die API-Ressource des betreffenden Servers senden.

NGINX Plus R14 erweitert diese Funktionalität auf die dateibasierte Konfiguration, indem ein Parameter namens „drain“ für die Upstream-Direktive „server“ bereitgestellt wird.

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-Adresse 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 server-Direktive entfernen oder den Parameter draining durch down ersetzen.

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

Mit NGINX Plus R14 freuen wir uns, eine Technologievorschau auf eine kommende Funktion zur gemeinsamen Nutzung von Zustandsinformationen in einem Cluster aus NGINX Plus-Instanzen ankündigen zu können. Die Technologievorschau implementiert die Session-Persistenzmethode „Sticky Learn“, um die Vorteile der gemeinsamen Nutzung von Sitzungsdaten zu veranschaulichen, die andernfalls von jeder Instanz separat verwaltet würden.

Die Technologievorschau wird als separates Installationspaket bereitgestellt und ist auf Anfrage erhältlich. Wenden Sie sich bitte an Ihren NGINX-Vertriebsmitarbeiter, um Zugriff zu erhalten.

Hinweise:

Die Clustering-Funktionalität von „sticky learn“ befindet sich in der Vorschauphase und ist daher nicht für den produktiven Einsatz geeignet. Wenn die gemeinsame Nutzung von Zustandsinformationen innerhalb eines Clusters eine wichtige Anforderung für Ihre Umgebung darstellt, empfehlen wir Ihnen, die Technologievorschau zu testen und NGINX Feedback dazu zu geben, wie gut sie Ihre Anforderungen erfüllt.
Technologievorschaupakete sind für CentOS/RHEL/Oracle Linux 7, Debian 8 und 9 sowie Ubuntu 16.04, 16.10 und 17.10 verfügbar.

Hinweis: Clustering-Unterstützung und Sitzungspersistenz mit sticky-learn sind ausschließlich in NGINX Plus verfügbar.

Zusätzliche Funktionen

NGINX Plus R14 umfasst außerdem die folgenden Verbesserungen:

Persistenz des Resolver-Status über Neuladungen hinweg – Eine Möglichkeit, die Gruppe von Servern in einer Upstream-Gruppe dynamisch neu zu konfigurieren, besteht darin, einen Hostnamen oder eine Domain als Parameter für die server-Direktive zu verwenden. DNS löst den Namen regelmäßig auf, und NGINX Plus verwendet automatisch die aktualisierte Gruppe von Servern (siehe NGINX Plus-Administratorhandbuch). NGINX Plus behält die DNS-Einträge für den Host- oder Domainnamen nun auch beim Neuladen von NGINX Plus bei. Zuvor musste der Name nach dem Neuladen erneut aufgelöst werden. Dadurch konnten Anfragen, die vor Abschluss der Namensauflösung eingingen, nicht verarbeitet werden.
Neue Variable für SSL-Clientzertifikate – Die Variable $ssl_client_escaped_cert ist eine neue integrierte NGINX-Variable, mit der Sie Ihre Clientzertifikate sicher und bequem für die Übertragung in einem HTTP-Header codieren und so an Ihre Backend-Anwendungen senden können. Die Variable ist URL-codiert.

NGINX Plus aktualisieren oder testen

NGINX Plus R14 bietet verbesserte Authentifizierungsfunktionen für Ihre Clientanwendungen, zusätzliche Clustering-Funktionen, Verbesserungen an NGINX JavaScript und wichtige Fehlerbehebungen. Insbesondere enthielt NGINX Plus R13 einen Fehler bei aktiven Zustandsprüfungen, durch den ein alter Worker-Prozess unter Umständen unbegrenzt Zustandsprüfungen durchführte. Dieser Fehler wurde mit NGINX Plus R14 behoben.

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf Release 14 durchzuführen. Dadurch erhalten Sie zahlreiche Fehlerbehebungen und Verbesserungen. Zudem erleichtert das Upgrade NGINX die Unterstützung, falls Sie ein Support-Ticket erstellen müssen. Anweisungen zur Installation und zum Upgrade 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 ausprobiert haben, empfehlen wir Ihnen, es zu testen – zur Webbeschleunigung, zum Lastenausgleich und zur Anwendungsbereitstellung oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute kostenlos mit einer 30‑Tage-Testversion beginnen. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.