Annonce de NGINX Plus R14

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer que NGINX Plus Release 14 (R14) est désormais disponible pour nos abonnés NGINX Plus. NGINX Plus est la seule solution tout-en-un combinant équilibreur de charge, cache de contenu et serveur web. Basée sur NGINX Open Source, elle offre également des fonctionnalités exclusives ainsi qu’une assistance primée disponible 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 native de l’authentification JWT, introduite pour la première fois dans NGINX Plus R10, permet d’utiliser NGINX Plus comme passerelle d’authentification pour vos API et applications.

Parmi les autres fonctionnalités de NGINX Plus R14 figurent :

• Prise en charge étendue de la mise en cluster (aperçu technologique) – Nous vous invitons à tester un aperçu d’une nouvelle fonctionnalité permettant de partager les informations d’état entre les instances NGINX Plus d’un cluster. Dans cet aperçu, l’état de la méthode de persistance de session sticky learn est partagé. Dans les prochaines versions, nous étendrons la prise en charge de la mise en cluster à d’autres fonctionnalités de NGINX Plus.
• Tailles de clé JWT plus longues – Outre la prise en charge des revendications JWT imbriquées et des données sous forme de tableaux, les algorithmes de signature JWT prennent désormais en charge des clés plus longues (jusqu’à 512 bits). Cela offre davantage de sécurité et de flexibilité lors de la validation des JWT.
• Stockage clé-valeur et API pour les flux – Le puissant stockage clé-valeur et l’API introduits dans la version 13 pour les applications HTTP sont désormais étendus aux applications TCP et UDP dans le contexte stream.
• Améliorations apportées au module JavaScript de NGINX – Ce module, qui permet d’exécuter du code JavaScript sur NGINX Plus, offre désormais une prise en charge linguistique supplémentaire pour l’objet JSON. [Ce module s’appelait auparavant nginScript.] Vous pouvez ainsi analyser et extraire nativement des informations à partir des réponses JSON reçues des API backend, et utiliser des méthodes de type Node.js pour accéder à votre système de fichiers. Le module fournit également désormais des traces d’appels pour un large éventail d’objets d’exception et d’erreur lorsqu’ils surviennent, afin de faciliter le débogage et la résolution des problèmes.
• Fonctionnalités supplémentaires – NGINX Plus propose également un tableau de bord actualisé pour la surveillance de l’activité en temps réel, une nouvelle variable SSL et la mise hors service progressive des serveurs en amont.

Changements de comportement

• L’API NGINX Plus a été mise à niveau vers la version 2. Consultez la documentation sur la compatibilité de l’API si vous envisagez d’utiliser les nouvelles fonctionnalités de l’API NGINX Plus.
• Les API des modules Upstream-Conf et Status étendu (activées à l’aide des directives upstream_conf et status) sont obsolètes depuis NGINX Plus R13. Elles ont été remplacées par la nouvelle API NGINX Plus, utilisée par le tableau de bord de suivi de l’activité en temps réel mis à jour et 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).

Fonctionnalités de NGINX Plus R14 en détail

Améliorations de JWT

Les responsables du déploiement 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 très facilement transférable d’échanger des informations d’identité. Vous pouvez obtenir des JWT auprès de différents émetteurs, notamment Okta, OneLogin et des solutions développées en interne. NGINX Plus peut ensuite accorder ou refuser l’accès selon que l’utilisateur ou le client d’API a présenté ou non un JWT valide.

NGINX Plus R14 prend désormais en charge les revendications JWT imbriquées et les données sous forme de tableaux, ainsi que des clés plus longues pour les algorithmes de signature JWT. Cela offre davantage de flexibilité et une sécurité accrue lors de la validation des JWT.

Prise en charge des revendications JWT imbriquées et des données sous forme de tableaux

La charge utile d’un JWT peut contenir des informations supplémentaires « imbriquées » sur l’utilisateur, telles que son appartenance à des groupes, qui peuvent servir à autoriser l’accès à une ressource. Cela évite d’avoir à interroger plusieurs fois une base de données pour autoriser les requêtes des utilisateurs.

Considérez la charge utile JWT suivante :

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

Dans le JWT ci-dessus, attributes est un objet de « revendication imbriquée » et groups est un tableau. Vous pouvez utiliser l’extrait de configuration suivant pour transmettre la valeur name de l’objet attributes au backend et refuser l’accès aux utilisateurs qui ne font pas partie du groupe Administrator.

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;
    }
}

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

• À l’aide de la directive « auth_jwt_claim_set », nous définissons la variable NGINX $jwt_groups sur le tableau groups défini dans le JWT. Les valeurs du tableau sont séparées par des virgules et affectées à $jwt_groups.
• À l’aide de la directive map, nous recherchons le mot-clé Administrator dans la liste des groupes. 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 location associé à l’URI /admin vérifie la variable $isAdmin. Si sa valeur est 0, NGINX renvoie au client le code d’état 403 « Forbidden ».

Avec NGINX Plus R14, vous pouvez également créer des variables à partir de revendications JWT imbriquées. Ces variables peuvent ensuite être ajoutées aux en-têtes HTTP avant la transmission des requêtes aux serveurs backend.

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 name au sein de la revendication attributes. 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é plus longues pour les algorithmes de signature JWT

NGINX Plus R14 prend désormais en charge les clés de signature de 256, 384 et 512 bits, afin de renforcer la validation des signatures et de faciliter l’intégration avec les produits de gestion des identités et des accès (IAM) qui utilisent par défaut des clés de signature plus longues. Ces clés 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 sur courbe elliptique (« ES »)

Par exemple, vous pouvez configurer NGINX Plus R14 pour qu’il n’accepte que les jetons Web JSON signés avec l’algorithme RS512 :

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;
    }
}

Dans ce cas, NGINX Plus ne transmet pas les requêtes au serveur mandataire si le JWT n’a pas été signé avec l’algorithme RS512 et renvoie le code d’état 401 Non autorisé au client à l’origine de la requête.

Remarque : la prise en charge des JWT est réservée à NGINX Plus.

Stockage clé-valeur et API pour le module Stream

NGINX Plus R13 a introduit le module de stockage clé-valeur pour HTTP, qui permet de créer, de modifier et de supprimer à la volée des paires clé-valeur dans une ou plusieurs zones de mémoire partagée. Un excellent cas d’usage de l’API du stockage clé-valeur consiste à l’utiliser avec fail2ban pour créer une liste dynamique d’adresses IP interdites.

NGINX Plus R14 ajoute le module de stockage clé-valeur pour Stream, offrant ainsi aux applications TCP et UDP les mêmes fonctionnalités de gestion des paires clé-valeur qu’aux applications HTTP.

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

Remarque : le magasin clé-valeur et l’API sont exclusivement disponibles dans NGINX Plus.

Améliorations apportées au module JavaScript de NGINX

Le module JavaScript NGINX (anciennement appelé nginScript) est un langage de script basé sur JavaScript pour NGINX Plus. Dans NGINX Plus R14, les fonctionnalités de JavaScript NGINX ont été étendues afin d’améliorer encore la programmabilité. La version mise à jour du paquet de modules dynamiques JavaScript NGINX apporte les nouvelles améliorations suivantes.

Prise en charge des objets JSON

L’objet JSON JavaScript est désormais disponible en tant qu’objet natif dans NGINX JavaScript. Cela permet de gérer plus facilement les 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 suivant dans le shell njs montre comment analyser et extraire des données JSON à l’aide de la syntaxe objet intégrée.

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

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 permettant d’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 de système de fichiers de Node.js dans NGINX JavaScript pour lire et écrire des fichiers, ce qui vous permet de personnaliser le workflow de déploiement de vos applications. Les opérations suivantes sont autorisées :

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

Cet exemple de shell JavaScript NGINX montre comment utiliser JavaScript NGINX pour lire le contenu d’un fichier dans une variable.

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

Objets d’erreur et traces d’appels

Afin d’aider davantage les développeurs à déboguer et à résoudre les problèmes, un large éventail d’objets d’erreur est désormais disponible :

• Erreur
• EvalError
• InternalError
• RangeError
• ReferenceError
• SyntaxError
• TypeError
• URIError

De plus, NGINX JavaScript fournit désormais des traces d’appels pour les erreurs et les exceptions. L’entrée suivante du journal des erreurs présente une trace d’appels simple correspondant à l’échec d’une opération système.

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"

Découvrez comment bien 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, qui permet d’accéder aux données de surveillance et aux métriques en temps réel au format JSON. Dans NGINX Plus R14, le tableau de bord intégré de surveillance de l’activité en direct utilise désormais l’API NGINX Plus et fournit à l’utilisateur plus de 80 métriques de surveillance 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. Elles restent disponibles dans cette version et seront incluses dans NGINX Plus R15. Elles seront entièrement supprimées dans NGINX Plus R16. Nous vous recommandons donc de mettre à jour vos configurations dès maintenant.

La configuration du tableau de bord obsolète se présente comme suit :

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

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

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 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;
}

Comme indiqué dans les extraits de configuration, nous vous recommandons vivement de limiter l’accès à l’API, par exemple à l’aide des directives « allow » et « deny ». Veillez à transférer 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 de NGINX Plus R13.

Remarque : le tableau de bord intégré est réservé à NGINX Plus.

Mise hors service progressive des serveurs en amont dans le fichier de configuration

Lors de la mise hors ligne d’un serveur, vous pouvez améliorer l’expérience utilisateur en permettant aux sessions existantes de se terminer tout en empêchant l’établissement de nouvelles sessions. Le serveur n’est mis hors ligne que lorsqu’il ne reste plus aucune session active. Cette opération est appelée la mise en attente du serveur. Vous pouvez l’effectuer dynamiquement avec l’API NGINX Plus en envoyant une requête PATCH contenant {"drain":true} à la ressource d’API du serveur concerné.

NGINX Plus R14 étend cette fonctionnalité à la configuration basée sur des fichiers en ajoutant un paramètre drain à la directive server du bloc upstream.

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

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

Prise en charge de la mise en cluster pour Sticky Learn (aperçu technologique)

Avec NGINX Plus R14, nous avons le plaisir d’annoncer une version préliminaire d’une future fonctionnalité permettant de partager l’état entre les instances d’un cluster NGINX Plus. Cette version préliminaire met en œuvre la méthode de persistance de session « sticky learn » afin de démontrer les avantages du partage des données de session qui, autrement, seraient gérées séparément par chaque instance.

La version préliminaire de cette technologie est proposée sous la forme d’un package installable séparément et disponible sur demande. Veuillez contacter votre représentant commercial NGINX pour y accéder.

Remarques :

1. La fonctionnalité de clustering de sticky learn est disponible en préversion et ne convient donc pas à une utilisation en production. Si le partage d’état au sein d’un cluster constitue une exigence importante pour votre environnement, nous vous encourageons à tester cette préversion technologique et à faire part à NGINX de vos commentaires sur la manière dont elle répond à vos besoins.
2. Des paquets en version préliminaire sont disponibles pour CentOS/RHEL/Oracle Linux 7, Debian 8 et 9, ainsi qu’Ubuntu 16.04, 16.10 et 17.10.

Remarque: la prise en charge du clustering et la persistance de session sticky‑learn sont toutes deux réservées à NGINX Plus.

Fonctionnalités supplémentaires

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

• Persistance de l’état du résolveur lors des rechargements – Une façon de reconfigurer dynamiquement l’ensemble des serveurs d’un groupe en amont consiste à utiliser un nom d’hôte ou de domaine comme paramètre de la directive server ; le DNS résout périodiquement le nom et NGINX Plus utilise automatiquement l’ensemble de serveurs mis à jour (consultez le Guide d’administration de NGINX Plus). NGINX Plus conserve désormais les enregistrements DNS du nom d’hôte ou de domaine lors d’un rechargement de NGINX Plus. Auparavant, le nom devait être résolu à nouveau après un rechargement, ce qui empêchait de traiter les requêtes reçues avant la fin de la résolution.
• Nouvelle variable de certificat client SSL – La variable « $ssl_client_escaped_cert » est une nouvelle variable intégrée à NGINX qui permet d’encoder facilement et en toute sécurité vos certificats clients dans un en-tête HTTP afin de les transmettre à vos applications backend. Cette variable est encodée au format URL.

Mettez à niveau ou essayez NGINX Plus

NGINX Plus R14 offre des fonctionnalités d’authentification améliorées pour vos applications clientes, des fonctionnalités de clustering supplémentaires, des améliorations de NGINX JavaScript et de notables corrections de bugs. En particulier, NGINX Plus R13 avait introduit un bug dans les contrôles d’intégrité actifs, qui pouvait amener un ancien processus worker à effectuer indéfiniment des contrôles d’intégrité. Ce problème a été résolu dans NGINX Plus R14.

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 14 dès que possible. Vous bénéficierez ainsi de plusieurs correctifs et améliorations, et cette mise à niveau permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir 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 encore essayé NGINX Plus, nous vous invitons à le faire, que ce soit pour accélérer vos sites web, équilibrer la charge et assurer la mise à disposition de vos applications, ou pour l’utiliser comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. 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 à déployer vos applications et à les faire évoluer.

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly