Annonce de NGINX Plus R14

Nous sommes heureux d'annoncer que NGINX Plus Release 14 (R14) est désormais disponible pour nos abonnés NGINX Plus. NGINX Plus est le seul équilibreur de charge, cache de contenu et serveur Web tout-en-un. Il est basé sur NGINX Open Source et ajoute des fonctionnalités exclusives ainsi qu'un support primé 24 heures sur 24 . NGINX Plus R14 inclut de nouvelles améliorations en matière de sécurité et de clustering.

Avec NGINX Plus, vous pouvez appliquer des contrôles d'accès à l'aide de jetons Web JSON (JWT). NGINX Plus R14 ajoute la prise en charge des revendications JWT imbriquées , ce qui vous permet d'accorder ou de refuser l'accès en fonction des informations d'appartenance à un groupe imbriquées dans un JWT. La prise en charge de l’authentification JWT native, introduite pour la première fois dans NGINX Plus R10 , permet à NGINX Plus d’être utilisé comme passerelle d’authentification pour vos API et applications.

Les fonctionnalités supplémentaires de NGINX Plus R14 incluent :

• Prise en charge étendue du clustering (aperçu technologique) – Nous vous invitons à tester un aperçu de la nouvelle fonctionnalité de partage des informations d’état entre les instances NGINX Plus d’un cluster. Dans l’aperçu, l’état de la méthode de persistance de la session d’ apprentissage persistante est partagé. Dans les prochaines versions, nous étendrons la prise en charge du clustering à d'autres fonctionnalités NGINX Plus.
• Tailles de clé JWT plus longues – En plus de la prise en charge des revendications JWT imbriquées et des données de tableau, des tailles de clé plus longues (jusqu'à 512 bits) sont désormais prises en charge pour les algorithmes de signature JWT. Cela offre plus de sécurité et de flexibilité lors de la validation des JWT.
• Magasin de clés-valeurs et API de flux – Le puissant magasin de clés-valeurs et API introduit dans la version 13 pour les applications HTTP est étendu aux applications TCP et UDP dans le contexte de flux .
• Améliorations apportées au module JavaScript NGINX – Le module, qui vous permet d'exécuter du code JavaScript sur NGINX Plus, prend désormais en charge un langage supplémentaire pour l'objet JSON. [Le module s'appelait auparavant nginScript.] Cela vous permet d'analyser et d'extraire des informations à partir des réponses JSON reçues des API backend de manière native et d'utiliser des méthodes de style Node.js pour accéder à votre système de fichiers. Le module fournit désormais également des backtraces pour une large gamme d'objets d'exception et d'erreur lorsqu'ils se produisent, afin de faciliter le débogage et le dépannage.
• Plus de fonctionnalités – NGINX Plus propose également un tableau de bord de surveillance des activités en direct mis à jour, une nouvelle variable SSL et un drainage du serveur en amont.

Changements de comportement

• L'API NGINX Plus a été mise à niveau vers la version 2. Consultez la documentation de compatibilité API si vous envisagez d'utiliser les nouvelles fonctionnalités de l'API NGINX Plus.
• Les API des modules Upstream-Conf et Status étendus (activés avec les directives upstream_conf et status ) sont obsolètes à partir de NGINX Plus R13 . Ils ont été remplacés par la nouvelle API NGINX Plus , qui est utilisée par le tableau de bord de surveillance des activités en direct mis à jour inclus dans R14.
• NGINX Plus est désormais disponible pour Ubuntu 17.10 (Artful Aardvark).
• NGINX Plus n'est plus pris en charge sur Debian 7 (Wheezy).

Caractéristiques détaillées de NGINX Plus R14

Améliorations de JWT

Les déployeurs d’API et de microservices se tournent vers la norme JSON Web Token (JWT, prononcé « jot ») pour sa simplicité et sa flexibilité. Un JWT est un moyen compact et hautement portable d’échanger des informations d’identité. Vous pouvez obtenir des JWT auprès d'un certain nombre d'émetteurs, notamment Okta, OneLogin et des solutions internes. NGINX Plus peut ensuite accorder ou refuser l'accès selon que l'utilisateur ou le client API a présenté ou non un JWT valide.

NGINX Plus R14 ajoute la prise en charge des revendications JWT imbriquées et des données de tableau, ainsi que des tailles de clé plus longues pour les algorithmes de signature JWT. Cela offre plus de flexibilité et une plus grande sécurité lors de la validation des JWT.

Prise en charge des revendications JWT imbriquées et des données de tableau

Une charge utile JWT peut contenir des informations « imbriquées » supplémentaires sur l’utilisateur, telles que l’appartenance à un groupe, qui peuvent être utilisées pour autoriser l’accès à une ressource. Cela permet d’éviter d’avoir à interroger une base de données plusieurs fois pour autoriser les demandes des utilisateurs.

Considérez la charge utile JWT suivante :

{ "exp": 1513429677,
"sub": "xample@example.com",
"aud": "nginx",
"attributes": {
"name": "Xavier Ample",
"chambre": "A123",
"département": "Démonstrations"
},
"groupes": [
"Administrateur",
"Foobar",
"Bazpub"
]
}

Dans le JWT ci-dessus, les attributs sont un objet « revendication imbriquée » et les groupes sont un tableau. Vous pouvez utiliser l'extrait de configuration suivant pour transmettre la valeur du nom de l'objet d'attributs au backend et pour refuser l'accès aux utilisateurs qui ne font pas partie du groupe Administrateur .

auth_jwt_claim_set $jwt_groups groups; # La valeur du tableau sera jointe sous forme de valeurs séparées par des virgulesauth_jwt_claim_set $jwt_real_name attributs nom; # Cette valeur est à deux niveaux de profondeur

map $jwt_groups $isAdmin {
"~\bAdministrator\b" 1; # Apparaît dans les limites de mots (\b) de la liste CSV
par défaut 0;
}

serveur {
listen 443 ssl;
#ssl_*; # Configuration pour la terminaison SSL/TLS

auth_jwt "closed site";
auth_jwt_key_file jwk.json;

location / {
proxy_set_header X-RealName $jwt_real_name; # Passer le nom réel comme en-tête
proxy_set_header X-Subject $jwt_claim_sub; # Les revendications L1 sont définies automatiquement
proxy_pass http://my_backend;
}

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

Voici plus de détails sur le fonctionnement de cette configuration :

• En utilisant la directive auth_jwt_claim_set , nous définissons la variable NGINX $jwt_groups sur le tableau de groupes défini dans le JWT. Les valeurs du tableau sont séparées par des virgules et attribuées à $jwt_groups .
• En utilisant la directive map , nous recherchons dans la liste des groupes le mot-clé Administrator . S'il est présent, l'utilisateur est considéré comme administrateur et $isAdmin est défini sur 1. Sinon, $isAdmin est défini sur 0.
• Le bloc d'emplacement pour l'URI /admin vérifie la variable $isAdmin . Si 0, NGINX renvoie le code d'état 403 Interdit Retour au client.

Avec NGINX Plus R14 , vous pouvez également créer des variables à partir de revendications JWT imbriquées. Les variables peuvent ensuite être placées dans des en-têtes HTTP avant de les transmettre par proxy aux serveurs principaux.

Dans l'exemple ci-dessus, nous utilisons la directive auth_jwt_claim_set pour définir la variable NGINX $jwt_real_name sur la valeur de l'objet nom dans la revendication d'attributs . La directive proxy_set_header définit l'en-tête HTTP X-RealName sur la valeur de l'objet name et transmet la requête à my_backend .

Pour plus d'informations sur toutes les directives de configuration disponibles pour authentifier les JWT avec NGINX Plus, consultez la documentation de référence .

Tailles de clés plus longues pour les algorithmes de signature JWT

NGINX Plus R14 prend désormais en charge les clés de signature 256 bits, 384 bits et 512 bits pour une validation de signature plus forte et une intégration plus facile avec les produits de gestion des identités et des accès (IAM) qui utilisent des clés de signature plus longues par défaut. Les clés de signature plus longues sont disponibles pour tous les algorithmes de signature pris en charge :

• HMAC avec SHA‑2 (« HS »)
• RSA PKCS #1 avec SHA‑2 (« RS »)
• Algorithme de signature numérique à courbe elliptique (« ES »)

Par exemple, vous pouvez configurer NGINX Plus R14 pour accepter uniquement les jetons Web JSON signés avec l'algorithme RS512 :

serveur { écouter 443 ssl;
#ssl_*; # Configuration pour la terminaison SSL/TLS

auth_jwt "site fermé";
auth_jwt_key_file jwk.json;

emplacement / {
si ( $jwt_header_alg != RS512 ) {
retour 401;
}
proxy_pass http://my_backend;
}
}

Dans ce cas, NGINX Plus ne transmet pas de requêtes proxy si le JWT n'a pas été signé avec l'algorithme RS512 et renvoie le code d'état 401Non autorisé pour le client qui a émis la demande.

Note : La prise en charge JWT est exclusive à NGINX Plus.

Magasin de clés-valeurs et API pour le module Stream

NGINX Plus R13 a introduit le module Key-Value Store pour HTTP , vous permettant de créer, modifier et purger des paires clé-valeur dans une ou plusieurs zones de mémoire partagée à la volée. Un excellent cas d’utilisation de l’API de stockage clé-valeur consiste à l’utiliser avec fail2ban pour créer une liste de refus d’adresses IP dynamique .

NGINX Plus R14 ajoute le module Key-Value Store pour Stream , rendant les mêmes fonctionnalités de paires clé-valeur disponibles pour les applications TCP et UDP que pour les applications HTTP.

La reconfiguration dynamique du magasin clé-valeur dans le contexte du flux est implémentée dans NGINX Plus R14 dans le cadre de l' API NGINX Plus .

Note : Le magasin clé-valeur et l’API sont exclusifs à NGINX Plus.

Améliorations apportées au module JavaScript NGINX

Le module JavaScript NGINX (anciennement appelé nginScript) est un langage de script basé sur JavaScript pour NGINX Plus. Dans NGINX Plus R14 , les capacités de NGINX JavaScript ont été étendues pour améliorer encore la programmabilité. Le package de module dynamique JavaScript NGINX mis à jour fournit les nouvelles améliorations suivantes.

Prise en charge des objets JSON

L'objet JavaScript JSON est désormais disponible en tant qu'objet natif dans NGINX JavaScript. Cela offre un moyen plus pratique de gérer des structures de données complexes et permet également à NGINX JavaScript d'analyser et de manipuler les réponses JSON reçues des API backend.

L’exemple de shell njs suivant montre comment analyser et extraire des données JSON à l’aide de la syntaxe d’objet intégrée.

$ njsscript nj interactif

v.<Tab> -> les propriétés et les méthodes prototypes de v.
tapez console.help() pour plus d'informations

>> var my_data = '{"colors":[{"name":"rouge","fancy":"poussière de brique"}, {"name":"bleu","fancy":"embruns"}]}';
>> var mon_objet = JSON.parse(mes_données);
>> mon_objet.colors[1].fancy;
embruns
>>

Accès au système de fichiers

Node.js, l'implémentation JavaScript côté serveur la plus populaire, fournit des méthodes intégrées pour accéder au système de fichiers du système d'exploitation (JavaScript côté client n'autorise pas l'accès au système de fichiers). Avec NGINX Plus R14 , vous pouvez désormais utiliser les méthodes du système de fichiers Node.js dans NGINX JavaScript pour lire et écrire des fichiers, ce qui vous permet de personnaliser votre flux de travail de livraison d'applications. Les opérations suivantes sont autorisées :

• Lecture – fs.readFile , fs.readFileSync
• Écriture – fs.writeFile , fs.writeFileSync
• Ajouter – fs.appendFile , fs.appendFileSync

Cet exemple de shell NGINX JavaScript montre comment NGINX JavaScript peut être utilisé pour lire le contenu d'un fichier dans une variable.

$ njsscript nj interactif

v.<Tab> -> les propriétés et les méthodes prototypes de v.
tapez console.help() pour plus d'informations

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

Objets d'erreur et backtraces

Pour aider davantage les développeurs dans le débogage et le dépannage, une large gamme d'objets d'erreur est désormais disponible :

• Erreur
• Erreur d'évaluation
• Erreur interne
• Erreur de plage
• Erreur de référence
• Erreur de syntaxe
• Erreur de type
• Erreur URIErreur

De plus, NGINX JavaScript fournit désormais des backtraces pour les erreurs et les exceptions. L'entrée suivante du journal des erreurs montre une trace simple pour une opération système ayant échoué.

12/12/2017 01:52:08 [erreur] 43441#43441 : *10 exception js : Erreur: Aucun fichier ou répertoire de ce type n'est disponible dans le répertoire natif (natif)
dans ma_fonction (:1)
dans le répertoire principal (natif)
, client : 127.0.0.1, serveur : , requête : "GET / HTTP/1.1", hôte : "localhost:80"

Découvrez comment démarrer avec NGINX JavaScript<.htmla> sur notre blog.

Tableau de bord NGINX Plus utilisant l'API NGINX Plus

NGINX Plus R13 a introduit l' API NGINX Plus , offrant un accès à la surveillance et aux métriques en temps réel au format JSON. Dans NGINX Plus R14 , le tableau de bord de surveillance des activités en direct intégré utilise désormais l’ API NGINX Plus , fournissant plus de 80 mesures de surveillance à l’utilisateur en temps réel.

Les API de reconfiguration dynamique et d’état étendu utilisées par le tableau de bord dans les versions précédentes de NGINX Plus sont obsolètes. Les API sont toujours disponibles dans cette version et seront incluses dans NGINX Plus R15 . Ils seront entièrement supprimés avec NGINX Plus R16 , nous vous encourageons donc à mettre à jour vos configurations maintenant.

La configuration du tableau de bord obsolète ressemble à ceci :

location /status { # OBSOLÈTE status; # OBSOLÈTE
# directives contrôlant l'accès, telles que 'allow' et 'deny'
}

location = /status.html { # OBSOLÈTE
root /usr/share/nginx/html; # OBSOLÈTE
}

Pour migrer vos instances NGINX Plus existantes vers le nouveau tableau de bord NGINX Plus, remplacez l'extrait précédent par celui-ci :

location /api { api write=on;
# directives contrôlant l'accès, telles que 'allow' et 'deny'
}

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

# Redirection des requêtes effectuées vers l'ancien tableau de bord
location = /status.html {
return 301 /dashboard.html;
}

Comme indiqué dans les extraits, nous vous recommandons fortement de limiter l'accès à l'API, par exemple avec les directives allow et deny . Assurez-vous de migrer les contrôles d’accès existants de l’emplacement /status vers l’emplacement /api .

Pour plus d'informations sur la nouvelle API NGINX Plus , consultez l' annonce NGINX Plus R13 .

Note : Le tableau de bord intégré est exclusif à NGINX Plus.

Vidange des serveurs en amont dans le fichier de configuration

Lorsque vous mettez un serveur hors ligne, vous pouvez améliorer l'expérience utilisateur en autorisant les sessions existantes à se terminer tout en empêchant l'établissement de nouvelles sessions. Le serveur ne se déconnecte pas tant qu'il n'y a plus de sessions actives. C'est ce qu'on appelle vider le serveur. Vous pouvez le faire de manière dynamique avec l' API NGINX Plus en envoyant une requête PATCH qui inclut {"drain":true} à la ressource API du serveur concerné.

NGINX Plus R14 étend cette fonctionnalité à la configuration basée sur des fichiers en fournissant un paramètre de drainage à la directive du serveur en amont.

en amont mon_backend { serveur 10.0.0.1 ;
serveur 10.0.0.2 ;
serveur 10.0.0.3 drain ;
}

Lorsque vous rechargez la configuration NGINX Plus, le serveur en amont avec l'IP 10.0.0.3 passe en mode de drainage. Vous pouvez ensuite mettre complètement hors service le serveur en supprimant la directive serveur correspondante ou en remplaçant le paramètre draining par down .

Prise en charge du clustering pour Sticky Learn (aperçu technologique)

Avec NGINX Plus R14 , nous sommes heureux d'annoncer un aperçu technologique d'une future capacité de partage d'état sur un cluster d'instances NGINX Plus. L'aperçu technologique implémente la méthode d'apprentissage permanent de la persistance de session pour démontrer les avantages du partage des données de session qui seraient autrement gérées individuellement par chaque instance.

L'aperçu technologique est fourni sous la forme d'un package installable séparé et est disponible sur demande. Veuillez contacter votre représentant commercial NGINX pour y accéder.

Remarques :

1. La fonctionnalité de clustering d'apprentissage permanent est en version préliminaire et n'est donc pas adaptée à une utilisation en production. Si le partage d’état sur un cluster est une exigence importante pour votre environnement, nous vous encourageons à tester l’aperçu technologique et à fournir des commentaires à NGINX sur la manière dont il répond à vos besoins.
2. Des packages d'aperçu technologique sont disponibles pour CentOS/RHEL/Oracle Linux 7, Debian 8 et 9, et Ubuntu 16.04, 16.10 et 17.10.

Note : La prise en charge du clustering et la persistance des sessions sticky-learn sont toutes deux exclusives à NGINX Plus.

Fonctionnalités supplémentaires

NGINX Plus R14 inclut également les améliorations suivantes :

• Persistance de l'état du résolveur entre les rechargements – Une façon de reconfigurer dynamiquement l'ensemble de serveurs dans un groupe en amont consiste à utiliser un nom d'hôte ou un domaine comme paramètre de la directive serveur ; DNS résout le nom périodiquement et NGINX Plus utilise automatiquement l'ensemble de serveurs révisé (voir le Guide d'administration de NGINX Plus ). NGINX Plus conserve désormais les enregistrements DNS du nom d'hôte ou du nom de domaine lors d'un rechargement NGINX Plus. Auparavant, le nom devait être résolu à nouveau après un rechargement, ce qui signifie que les demandes qui arrivaient avant la fin de la résolution ne pouvaient pas être traitées.
• Nouvelle variable de certificat client SSL – La variable $ssl_client_escaped_cert est une nouvelle variable NGINX intégrée vous offrant un moyen sûr et pratique d'encoder vos certificats clients dans un en-tête HTTP afin que vous puissiez les envoyer à vos applications back-end. La variable est codée en URL.

Mettre à niveau ou essayer NGINX Plus

NGINX Plus R14 inclut des capacités d'authentification améliorées pour vos applications clientes, des capacités de clustering supplémentaires, des améliorations JavaScript NGINX et des corrections de bogues notables . En particulier, NGINX Plus R13 a introduit un bug pour les contrôles de santé actifs selon lequel un ancien processus de travail pouvait effectuer des contrôles de santé indéfiniment. Ce problème a été résolu avec NGINX Plus R14 .

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer la mise à niveau vers la version 14 dès que possible. Vous bénéficierez d'un certain nombre de correctifs et d'améliorations, et la mise à niveau aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance. Les instructions d'installation et de mise à niveau sont disponibles sur le portail client .

Veuillez examiner attentivement les nouvelles fonctionnalités et les changements de comportement décrits dans cet article de blog avant de procéder à la mise à niveau.

Si vous n'avez pas essayé NGINX Plus , nous vous encourageons à l'essayer - pour l'accélération Web, l'équilibrage de charge et la diffusion d'applications, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer gratuitement dès aujourd’hui avec une évaluation de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.