Annonce de NGINX Plus R23

Liam CrillyDirecteur senior de la gestion des produits

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 23 (R23). Basé sur NGINX Open Source, NGINX Plus est le seul logiciel faisant office d’équilibreur de charge, de proxy inverse et de passerelle API.

Les nouvelles fonctionnalités de NGINX Plus R23 incluent :

• Contrôles d’intégrité gRPC – Vérifier activement qu’un service gRPC est capable de traiter les requêtes avant de les lui envoyer améliore considérablement la fiabilité.
• Prise en charge de l’installation sans privilèges – NGINX Plus peut désormais être installé et mis à niveau par un utilisateur sans privilèges (autre que root). Cette solution entièrement prise en charge s’inscrit dans la tendance croissante à l’adoption de modèles de sécurité Zero Trust.
• Prise en charge de PKCE pour OpenID Connect – NGINX Plus R23 implémente l’extension Proof Key for Code Exchange (PKCE) pour le flux Authorization Code d’OpenID Connect. PKCE empêche plusieurs types d’attaques et permet des échanges OAuth sécurisés avec des clients publics.

Pour compléter cette version : un contrôle plus précis de SSL/TLS, une méthode native pour définir les attributs des cookies et la définition de variables dans le module Stream. Les mises à jour de l’écosystème NGINX Plus comprennent les nouveaux modules Buffer et Query String pour le module JavaScript de NGINX, le nouveau module dynamique SPNEGO for Kerberos, ainsi que des améliorations apportées au module dynamique Prometheus‑njs.

Modifications importantes du comportement

• Module obsolète – Le module tiers Cookie-Flag est obsolète et remplacé par la nouvelle directive proxy_cookie_flags. Le module sera supprimé dans NGINX Plus R26. Pour plus de détails, consultez Méthode native de définition des attributs de cookies.
• Nouveaux systèmes d’exploitation pris en charge :
  • Alpine 3.12 (x86_64, aarch64)
  • Debian 10 (aarch64 ; x86_64 est pris en charge depuis NGINX Plus R17)
• Anciens systèmes d’exploitation supprimés ou qui seront supprimés :
  • Alpine 3.9 n’est plus pris en charge ; la version la plus ancienne encore prise en charge est la 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ n’est plus pris en charge ; la plus ancienne version prise en charge est la 7.4
  • Ubuntu 19.10 n’est plus pris en charge
  • Debian 9 sera supprimé dans NGINX Plus R24

Présentation détaillée des nouvelles fonctionnalités

Contrôles d’intégrité gRPC

Lorsqu’il est déployé en tant qu’équilibreur de charge, NGINX Plus peut surveiller l’état des serveurs backend (en amont) en effectuant des contrôles d’état actifs. NGINX Plus R23 prend en charge le protocole de contrôle d’état gRPC, ce qui lui permet de vérifier avec précision si les serveurs gRPC backend sont en mesure de traiter de nouvelles requêtes. Cette fonctionnalité est particulièrement utile dans les environnements dynamiques et conteneurisés. Lors du lancement de nouvelles instances d’un service gRPC, il est important de n’envoyer des requêtes qu’une fois le service « entièrement opérationnel ». Cela nécessite un contrôle d’état plus approfondi que la simple vérification du port TCP ou de la disponibilité d’un URI HTTP : le service lui-même doit indiquer s’il est prêt à recevoir des requêtes.

Pour les services gRPC qui implémentent le protocole de vérification de l’état de santé gRPC, la configuration est simple.

Chargement de l’exemple de code…

Cette configuration répartit la charge de toutes les requêtes entre les serveurs du groupe en amont « grpc_backend ». La directive health_check inclut le paramètre type=grpc afin d’appeler la méthode Check du service Health de chaque serveur en amont. Les services qui répondent avec l’état SERVING sont considérés comme sains. Le paramètre mandatory garantit qu’au démarrage de NGINX Plus ou lorsqu’un nouveau serveur est ajouté au groupe en amont, le trafic ne lui est pas transmis tant qu’une vérification de l’état n’a pas réussi (sinon, les nouveaux services sont considérés comme sains par défaut).

Si plusieurs services gRPC sont exposés sur chaque serveur en amont, le service le plus important (celui dont dépendent d’autres services ou qui comporte des services subordonnés) peut être surveillé en indiquant son nom comme valeur du paramètre « grpc_service », comme dans cet exemple :

Chargement de l’exemple de code…

Pour les services gRPC qui n’implémentent pas le protocole de vérification de l’état de santé gRPC, nous pouvons vérifier si le serveur en amont répond au moins aux requêtes gRPC, car, dans ce cas, il renvoie un code d’état d’erreur en réponse à la méthode Check. Avec la configuration définie dans grpc_health.conf, nous nous attendons à ce qu’un service qui n’implémente pas le protocole gRPC réponde avec le code d’état 12 (UNIMPLEMENTED).

Nous pouvons également vérifier qu’un service gRPC est capable de répondre aux requêtes entrantes sans avoir à modifier le code du backend. Cette approche permet de surveiller n’importe quel service gRPC :

Chargement de l’exemple de code…

Installation pour un utilisateur non privilégié

Dans les versions précédentes, NGINX Plus fonctionnait avec un nombre minimal de processus exécutés sous le compte de l’utilisateur privilégié « root ». Par exemple, les instructions d’installation du Guide d’administration de NGINX Plus créent les processus suivants :

$ ps auxf | grep nginxroot  ...  9068  888 ?  Ss 21:44  0:00 nginx: master process nginx
nginx ...  9712 3572 ?  S  21:44  0:00  \_ nginx: worker process

Comme indiqué, le processus maître s’exécute avec les privilèges root. Tous les autres processus (processus de travail et gestion du cache) utilisent le compte utilisateur non privilégié nginx.

Les systèmes critiques traitant des données sensibles peuvent ne pas souhaiter utiliser l’utilisateur root. Dans ce cas, NGINX Plus R23 peut être installé et exécuté par un utilisateur non privilégié. Nous fournissons un script d’installation, ngxunprivinst.sh, dans notre dépôt GitHub pour les systèmes d’exploitation suivants :

• Alpine Linux
• Amazon Linux, Amazon Linux 2
• CentOS, Red Hat Enterprise Linux
• Debian, Ubuntu

Remarque : Si des écouteurs NGINX Plus sont configurés sur des ports inférieurs à 1024 (par exemple, 80 ou 443), le processus maître doit disposer des privilèges root (mais vous pouvez tout de même installer NGINX Plus avec un compte utilisateur non privilégié).

Pour utiliser le script d’installation, exécutez les commandes suivantes. (Pour afficher toutes les commandes disponibles de ngxunprivinst.sh, exécutez le script sans paramètre de nom de commande ou consultez le code du script dans le dépôt GitHub.)

1. Téléchargez le script et assurez-vous qu’il est exécutable :

$ chmod +x ngxunprivinst.sh

1. Copiez votre certificat et votre clé NGINX Plus (nginx-repo.crt et nginx-repo.key) dans le répertoire local. Les options ‑c et ‑k sont incluses dans toutes les commandes ngxunprivinst.sh afin de les identifier.
2. Répertoriez les versions de NGINX Plus disponibles dans le dépôt NGINX Plus.

$ ./ngxunprivinst.sh list -c nginx-repo.crt -k nginx-repo.key
18-1
18-2
19-1
20-1
21-1
22-1
23-1

1. Récupérez le paquet souhaité (ici, nous récupérons NGINX Plus R23-1). L’option « ‑p » indique le répertoire d’installation :

$ ./ngxunprivinst.sh fetch -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23-1

1. Installez les paquets dont vous avez besoin (ici, nous installons NGINX Plus et le module JavaScript NGINX, njs).

$ ./ngxunprivinst.sh install -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23.1 nginx-plus-23-1.el8.ngx.x86_64.rpm nginx-plus-module-njs-23%2B0.4.6-1.el8.ngx.x86_64.rpm

1. Démarrez NGINX en incluant l’option ‑p pour spécifier le chemin, ‑c pour indiquer le nom du fichier de configuration et ‑e pour indiquer le nom du journal des erreurs.

$ /home/nginxrun/usr/sbin/nginx -p /home/nginxrun/etc/nginx -c nginx.conf -e /home/nginxrun/var/log/error.log

1. Nous incluons l’option « ‑e » pour supprimer le message d’avertissement qui s’afficherait autrement. Avant que NGINX Plus ait lu sa configuration au démarrage, il écrit dans le journal d’erreurs par défaut, /var/log/nginx/error.log. Les utilisateurs non privilégiés ne sont pas autorisés à créer ce fichier ni à y écrire, ce qui génère un avertissement. Une fois la configuration lue, la directive error_log définit comme emplacement du journal d’erreurs un emplacement dans lequel l’utilisateur non privilégié peut écrire.
2. (Facultatif) Pour vérifier que NGINX Plus s’exécute avec un utilisateur autre que root, exécutez la commande suivante :

$ ps auxf | grep nginx
nginxrun ...  9068  888 ?  Ss 21:55 0:00 nginx: master process
nginxrun ...  9712 3572 ?  S  21:55 0:00  \_ nginx: worker process

Prise en charge de PKCE pour OpenID Connect

La clé de preuve pour l’échange de code (PKCE) est une extension récemment ajoutée au flux de code d’autorisation OpenID Connect (OIDC) afin de prévenir plusieurs types d’attaques et de sécuriser l’échange OAuth avec les clients publics. Pour NGINX Plus R23, nous avons mis à jour notre implémentation de référence d’OpenID Connect afin de prendre en charge cette extension. PKCE deviendra obligatoire avec OAuth 2.1.

La modification consiste précisément à remplacer « client_secret » par deux nouvelles valeurs dans le challenge de code :

• code_challenge
• code_verifier

Afin de contrer différentes attaques, notamment sur les appareils mobiles, le challenge associé à un jeton (qu’il s’agisse d’un jeton d’accès, d’identité ou d’actualisation) a été modifié comme suit :

1. NGINX Plus génère (et mémorise) un « code_verifier ».
2. NGINX Plus redirige l’utilisateur final vers la page de connexion du fournisseur d’identité OIDC (IdP) afin qu’il s’y connecte. La requête inclut une version hachée du code_verifier appelée code_challenge.
3. L’IdP envoie un auth_code pour l’utilisateur à NGINX Plus.
4. Grâce à l’état partagé, NGINX Plus peut retrouver le code_verifier généré et envoyer la requête afin d’échanger le code d’autorisation contre un ensemble de jetons auprès du point de terminaison de jetons de l’IdP.

Avant l’ajout de PKCE, il suffisait que NGINX Plus partage un secret client statique avec l’IdP.
Dans la version mise à jour de l’implémentation de référence d’OIDC, NGINX Plus peut gérer les flux de code d’autorisation aussi bien avec PKCE qu’avec la méthode reposant sur un secret client.

Voici un exemple de configuration qui active le flux étendu Authorization Code avec PKCE :

Chargement de l’exemple de code…

La nouvelle variable « $oidc_pkce_enable » permet d’activer ou de désactiver le flux PKCE. Si elle est définie sur 1 pour un domaine spécifique, le flux PKCE est utilisé. Si elle est définie sur 0 (valeur par défaut), le flux d’autorisation par code sans PKCE est utilisé.

Autres améliorations de NGINX Plus R23

Contrôle précis des connexions SSL/TLS

TLS v1.3 offre une sécurité renforcée par rapport aux versions précédentes de TLS, avec un chiffrement de bout en bout entre les serveurs, ainsi qu’entre les serveurs et leurs clients. NGINX Plus R23 permet d’accéder directement à la configuration d’OpenSSL afin de contrôler précisément TLS v1.3.

Création d’un serveur HTTPS par défaut sans certificat ni clé

Dans les versions précédentes, le bloc server par défaut destiné au trafic HTTPS protégé par TLS devait inclure les directives ssl_certificate et ssl_certificate_key, ce qui vous obligeait à créer un certificat autosigné « factice » et la clé correspondante.

La directive « ssl_reject_handshake » rend inutiles le certificat et la clé, comme dans cet exemple de configuration :

Chargement de l’exemple de code…

Configuration directe d’OpenSSL

NGINX Plus R23 vous offre un contrôle plus précis sur la manière dont NGINX Plus gère SSL/TLS avec OpenSSL 1.0.2 et les versions ultérieures.

Les cas d’utilisation suivants tirent parti de ce nouveau niveau de contrôle :

• Chiffrements ChaCha – NGINX Plus utilise ChaCha20 lorsqu’un client (généralement mobile) place ce chiffrement en tête de sa liste de préférences. ChaCha20 améliore nettement les performances des clients qui le prennent en charge.
• Configuration des suites de chiffrement TLS v1.3 – Dans les versions précédentes, la directive ssl_ciphers permettait de définir la liste des suites de chiffrement SSL/TLS privilégiées par NGINX Plus, comme dans cet exemple :

  Chargement de l’exemple de code…

  Cette directive ne s’applique toutefois pas à TLS v1.3, car l’implémentation des suites de chiffrement TLS v1.3 dans OpenSSL n’est pas compatible avec les anciennes interfaces. Pour définir la liste des suites de chiffrement pour TLS v1.3, utilisez la nouvelle directive ssl_conf_command comme dans cet exemple :

  Chargement de l’exemple de code…

  Pour définir les suites de chiffrement pour TLS v1.2 et v1.3, incluez les deux directives dans la configuration :

  Chargement de l’exemple de code…

• Mise à niveau des connexions mandataires – S’appuyant sur le mécanisme de configuration des chiffrements mis en œuvre par la directive ssl_conf_command, NGINX Plus R23 vous permet de contrôler de la même manière les suites de chiffrement des connexions relayées à l’aide des protocoles suivants :
  • HTTP et TCP – proxy_ssl_conf_command
  • gRPC – grpc_ssl_conf_command
  • uwsgi – uwsgi_ssl_conf_command

L’exemple suivant montre comment configurer NGINX Plus afin que les requêtes provenant de clients utilisant d’anciennes versions de TLS soient transmises à des serveurs backend connus pour prendre en charge TLS v1.3.

Chargement de l’exemple de code…

Le gestionnaire de cache peut surveiller l’espace disque disponible

Lorsque NGINX Plus est configuré en tant que proxy de mise en cache, le processus gestionnaire de cache garantit que la taille du cache ne dépasse pas la limite définie par le paramètre max_size de la directive proxy_cache_path, en supprimant le contenu auquel on a accédé le moins récemment.

Avec NGINX Plus R23, le gestionnaire de cache peut également surveiller l’espace disque disponible sur le système de fichiers hébergeant le cache et supprimer du contenu lorsque l’espace disponible est inférieur à la valeur du nouveau paramètre « min_free » de la directive « proxy_cache_path ».

Cela signifie que même lorsque le cache partage le même système de fichiers que d’autres processus, NGINX Plus veille à ce que le remplissage du cache ne sature pas accidentellement le disque.

Chargement de l’exemple de code…

Méthode native pour définir les attributs des cookies

Les cookies non sécurisés restent un vecteur d’attaque à haut risque. Comme l’indique le Mozilla Developer Network (MDN), l’un des moyens d’empêcher que des tiers ou des scripts non autorisés accèdent aux cookies consiste à définir des attributs tels que HttpOnly et Secure dans l’en-tête Set-Cookie.

Dans les versions précédentes, nous proposions la directive set_cookie_flag à cette fin, telle qu’implémentée dans le module tiers Cookie‑Flag disponible dans notre dépôt de modules dynamiques. NGINX Plus R23 introduit la directive proxy_cookie_flags pour remplacer cette directive et ce module.

Le module Cookie‑Flag obsolète sera supprimé dans NGINX Plus R26. Nous vous recommandons donc de rechercher toutes les directives « set_cookie_flag » dans votre configuration et de les remplacer dès que possible par la directive « proxy_cookie_flags ».

Voici un exemple de configuration de proxy vers une application backend simple qui ne définit elle-même aucun indicateur de protection des cookies :

Chargement de l’exemple de code…

Dans cet exemple, nous ajoutons les attributs « HttpOnly », « Secure » et « SameSite » afin de sécuriser le cookie de session appcookie créé par le serveur en amont et utilisé par NGINX Plus pour la persistance des sessions, comme décrit dans le guide d’administration de NGINX Plus.

À l’aide de la commande curl ou des outils de développement de votre navigateur, vous pouvez constater que les attributs HttpOnly, Secure et SameSite sont désormais définis pour appcookie.

< HTTP/1.1 200 OK< Server: nginx/1.19.4
< Date: Thu, 08 Dec 2020 14:46:12 GMT
< Content-Type: application/octet-stream
< Content-Length: 9
< Connection: keep-alive
< Set-Cookie: appcookie=appserver1; Secure; HttpOnly; SameSite=Strict
< Content-Type: text/html

Avec NGINX Plus R23, vous pouvez également ajouter l’attribut « SameSite » aux cookies à l’aide de la directive « sticky », comme dans cet exemple (les paramètres « httponly » et « secure » sont pris en charge depuis NGINX Plus R6) :

Chargement de l’exemple de code…

Définition de variables dans le module Stream

NGINX Plus R23 introduit la directive « set » permettant de définir des variables dans les configurations TCP/UDP, étendant ainsi la fonctionnalité couramment utilisée pour le traitement du trafic HTTP.

Voici un exemple qui construit des valeurs composites complexes à partir de plusieurs variables.

Chargement de l’exemple de code…

Un cas d’utilisation plus sophistiqué emploie la directive set pour mettre à jour le magasin clé-valeur. Dans cette configuration d’équilibrage de charge DNS, le magasin clé-valeur enregistre l’heure à laquelle chaque adresse IP cliente effectue une requête DNS et conserve chaque enregistrement pendant 24 heures.

Chargement de l’exemple de code…

Vous pouvez ensuite utiliser l’API NGINX Plus pour savoir quand chaque client a effectué sa dernière requête DNS au cours des 24 heures précédentes.

$ curl http://localhost:8080/api/6/stream/keyvals/dns_timestamp{
  "172.17.0.1": "2020-12-08T15:51:28+00:00",
  "172.17.0.2": "2020-12-08T12:36:08+00:00",
  "172.17.0.7": "2020-12-08T15:15:42+00:00"
}

Mises à jour de l’écosystème NGINX Plus

Améliorations apportées au module JavaScript de NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.5.0. Cette version introduit le module Buffer, qui est analogue au module Buffer de Node.js. Les objets Buffer facilitent la manipulation des données binaires, sans avoir à recourir à des chaînes de caractères.

Parmi les autres améliorations notables apportées au module figurent le module Query String qui permet d’accéder facilement aux paires clé-valeur transmises dans l’URL, ainsi que la prise en charge des traces d’appels au niveau des lignes pour le débogage.

Modifications apportées aux modules dynamiques

Nouveau module SPNEGO pour Kerberos

La prise en charge de l’authentification Kerberos SPNEGO est désormais disponible dans le référentiel de modules dynamiques de NGINX Plus. Pour obtenir les instructions d’installation et accéder à des informations complémentaires, consultez le Guide d’administration de NGINX Plus.

Module Cookie-Flags obsolète

Comme indiqué dans la section « Méthode native de définition des attributs de cookies » ci-dessus, la nouvelle directive proxy_cookie_flags remplace la directive set_cookie_flag implémentée dans le module tiers Cookie-Flag, désormais obsolète et dont la suppression est prévue dans NGINX Plus R26. Si votre configuration contient la directive set_cookie_flag, veuillez la remplacer par proxy_cookie_flags dès que possible.

Mises à jour du module Prometheus-njs

Le module Prometheus‑njs expose désormais des métriques supplémentaires. Il a également été mis à niveau pour prendre en charge les déploiements qui utilisent le module JavaScript NGINX (njs). Lors de la mise à niveau de Prometheus‑njs vers la version 1.3.1 ou une version ultérieure, il est important de mettre à jour le fichier de configuration NGINX afin d’éviter toute référence à des éléments de configuration njs obsolètes :

• La directive « js_include » est obsolète et remplacée par la directive « js_import »
• Les directives « js_content » et « js_set » peuvent référencer une fonction de module

Correction de bug notable

Les contrôles d’intégrité qui utilisaient la directive require dans un bloc match pour vérifier que les variables n’étaient pas vides pouvaient ne pas détecter les serveurs en amont défaillants si la réponse était supérieure à la valeur de la directive proxy_buffer_size.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R23 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir un ticket d’assistance.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le faire, que ce soit pour la sécurité, l’équilibrage de charge et la passerelle d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer dès aujourd’hui avec un essai gratuit 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