Annonce de NGINX Plus R23

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

Les nouvelles fonctionnalités de NGINX Plus R23 incluent :

• Contrôles de santé gRPC – Tester activement qu’un service gRPC peut gérer les requêtes avant de les 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 (non root ). Cette solution entièrement prise en charge s’aligne sur la tendance croissante vers les modèles de sécurité zéro confiance.
• Prise en charge d'OpenID Connect PKCE – NGINX Plus R23 implémente l'extension Proof Key for Code Exchange (PKCE) au flux de code d'autorisation OpenID Connect. PKCE empêche plusieurs types d'attaques et permet des échanges OAuth sécurisés avec des clients publics.

Cette version est complétée par un contrôle plus précis sur SSL/TLS, une méthode native de définition des indicateurs de cookies et la définition de variables dans le module Stream. Les mises à jour de l'écosystème NGINX Plus incluent les nouveaux modules Buffer et Query String pour le module JavaScript NGINX, le nouveau module dynamique SPNEGO pour Kerberos et les améliorations du module dynamique Prometheus-njs.

Changements importants dans le 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, voir Méthode native pour définir les indicateurs 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 )
• Systèmes d'exploitation plus anciens supprimés ou à supprimer :
  • Alpine 3.9 n'est plus pris en charge ; la version la plus ancienne prise en charge est 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ n'est plus pris en charge ; la version la plus ancienne prise en charge est 7.4
  • Ubuntu 19.10 n'est plus pris en charge
  • Debian 9 sera supprimée dans NGINX Plus R24

Nouvelles fonctionnalités en détail

Contrôles de santé gRPC

Lorsqu'il est déployé en tant qu'équilibreur de charge, NGINX Plus peut surveiller l'état de santé des serveurs back-end (en amont) en effectuant des contrôles de santé actifs . NGINX Plus R23 prend en charge le protocole de vérification de l'état gRPC , ce qui lui permet de tester avec précision si les serveurs gRPC back-end sont capables de gérer les nouvelles demandes. Ceci est particulièrement utile dans les environnements dynamiques et conteneurisés. Lors du lancement de nouvelles instances d'un service gRPC, il est important d'envoyer des requêtes uniquement une fois que le service est « entièrement opérationnel ». Cela nécessite un contrôle de santé qui va plus loin que l'examen du port TCP ou la vérification de la disponibilité de l'URI HTTP - un contrôle où le service lui-même indique s'il est prêt à recevoir des requêtes.

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

Cette configuration équilibre la charge de toutes les demandes adressées au groupe en amont grpc_backend . La directive health_check inclut le paramètre type=grpc pour appeler la méthode Check du service Health de chaque serveur en amont. Les services qui répondent par SERVIR sont considérés comme sains. Le paramètre obligatoire garantit que lorsque NGINX Plus démarre ou qu'un nouveau serveur est introduit dans le groupe en amont, le trafic n'est pas transféré tant qu'un contrôle d'intégrité n'est pas réussi (sinon, les nouveaux services sont supposés être sains par défaut).

S'il existe plusieurs services gRPC exposés sur chaque serveur en amont, le service le plus important (celui avec des services dépendants ou subordonnés) peut être surveillé en spécifiant son nom comme valeur du paramètre grpc_service comme dans cet exemple :

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

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

Installation d'un utilisateur non privilégié

Dans les versions précédentes, NGINX Plus fonctionnait avec un minimum de processus exécutés en tant qu'utilisateur privilégié root . Par exemple, les instructions d’installation du guide d’administration de NGINX Plus créent ces processus :

$ ps auxf | grep nginx root ...  9068 888 ?  Ss 21:44 0:00 nginx : processus maître nginx nginx ...  9712 3572 ?  S 21:44 0:00 \_ nginx : processus de travail

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

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

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

Note: 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 de privilèges root (mais vous pouvez toujours installer NGINX Plus sous un compte utilisateur non privilégié).

Pour utiliser le script d’installation, exécutez les commandes suivantes. (Pour voir toutes les commandes ngxunprivinst.sh disponibles, exécutez le script sans paramètre command‑name ou consultez le code du script dans le référentiel GitHub.)

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

   $ chmod +x ngxunprivinst.sh

2. 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 pour les identifier.

3. Répertoriez les versions de NGINX Plus disponibles dans le référentiel NGINX Plus.

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

4. Récupérez le package souhaité (ici nous récupérons NGINX Plus R23-1 ). L'option ‑p spécifie le répertoire d'installation :

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

5. Installez les packages 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

6. Démarrez NGINX, y compris l’option ‑p pour spécifier le chemin, ‑c pour nommer le fichier de configuration et ‑e pour nommer le journal des erreurs.

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

   Nous incluons l’option ‑e pour supprimer le message d’avertissement qui apparaît autrement. Avant que NGINX Plus n'ait lu sa configuration au démarrage, il écrit dans le journal des erreurs par défaut, /var/log/nginx/error.log . Les utilisateurs non privilégiés n'ont pas l'autorisation de créer ou d'écrire dans ce fichier, ce qui entraîne un avertissement. Une fois la configuration lue, la directive error_log définit le journal des erreurs à un emplacement dans lequel l'utilisateur non privilégié peut écrire.

7. (Facultatif) Pour vérifier que NGINX Plus s’exécute en tant qu’utilisateur non root , exécutez cette commande :

   $ ps auxf | grep nginx nginxrun ...  9068 888 ?  Ss 21:55 0:00 nginx : processus maître nginxrun ...  9712 3572 ?  S 21:55 0:00 \_ nginx : processus de travail

Prise en charge de OpenID Connect PKCE

Proof Key for Code Exchange ( PKCE ) est une extension récemment ajoutée au flux de code d'autorisation OpenID Connect (OIDC) pour empêcher plusieurs types d'attaques et sécuriser l'échange OAuth avec les clients publics. Pour NGINX Plus R23 , nous avons mis à jour notre implémentation de référence OpenID Connect pour prendre en charge l'extension. PKCE deviendra obligatoire avec OAuth 2.1 .

Le changement spécifique consiste à remplacer client_secret par deux nouvelles valeurs dans le défi du code :

• code_challenge
• code_verifier

Pour répondre à différentes attaques, notamment sur les appareils mobiles, le défi d'un jeton (qu'il s'agisse d'un jeton d'accès, d'identification ou d'actualisation) a été ajusté comme suit :

1. NGINX Plus génère (et mémorise) un code_verifier .
2. NGINX Plus redirige l'utilisateur final pour se connecter à la page de connexion du fournisseur d'identité OIDC (IdP). La demande 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. Sur la base de l'état partagé, NGINX Plus est capable de trouver le code_verifier généré et d'envoyer la demande d'échange du code d'autorisation contre un ensemble de jetons à partir du point de terminaison du jeton de l'IdP.

Avant d’ajouter PKCE, il suffisait à NGINX Plus de partager un secret client statique avec l’IdP.
Dans l' implémentation de référence OIDC mise à jour, NGINX Plus est capable de gérer les flux de code d'autorisation pour la méthodologie PKCE et client-secret.

Voici un exemple de configuration qui permet le flux de code d’autorisation étendu avec PKCE :

La nouvelle variable $oidc_pkce_enable agit comme un commutateur pour le flux PKCE. Si défini sur1 pour un domaine spécifique, le flux PKCE est utilisé. Si défini sur0 (par défaut), le flux de code d'autorisation non PKCE est utilisé.

Autres améliorations dans NGINX Plus R23

Contrôle précis des connexions SSL/TLS

TLS v1.3 permet une sécurité renforcée par rapport aux versions TLS précédentes, avec un cryptage de bout en bout entre les serveurs et entre les serveurs et leurs clients. NGINX Plus R23 fournit un accès direct à la configuration OpenSSL pour un contrôle précis sur TLS v1.3.

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

Dans les versions précédentes, le bloc de serveur par défaut pour le trafic HTTPS protégé par TLS devait inclure les directives ssl_certificate et ssl_certificate_key , ce qui vous obligeait à créer un certificat et une clé auto-signés « factices ».

La directive ssl_reject_handshake élimine l'exigence d'un certificat et d'une clé, comme dans cet exemple de configuration :

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 versions ultérieures.

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

• Chiffres ChaCha – NGINX Plus utilise ChaCha20 lorsqu'un client (généralement mobile) spécifie ce chiffrement en haut de sa liste de préférences. ChaCha20 améliore considérablement les performances des clients qui le prennent en charge.

• Configuration du chiffrement TLS v1.3 – Dans les versions précédentes, la directive ssl_ciphers était utilisée pour définir la liste des chiffrements SSL/TLS préférés de NGINX Plus, comme dans cet exemple :

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

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

• Mise à niveau des connexions proxy – En s’appuyant sur le mécanisme de configuration de chiffrement implémenté par la directive ssl_conf_command , NGINX Plus R23 vous offre le même contrôle sur les suites de chiffrement pour les connexions proxy avec ces protocoles :

  • HTTP et TCP – proxy_ssl_conf_command
  • gRPC – commande grpc_ssl_conf
  • uwsgi – commande uwsgi_ssl_conf_

L'exemple suivant montre comment configurer NGINX Plus pour mettre à niveau les demandes des clients utilisant des versions TLS plus anciennes afin d'utiliser des serveurs back-end connus pour prendre en charge TLS v1.3.

Le gestionnaire de cache peut surveiller l'espace disque disponible

Lorsque NGINX Plus est configuré comme proxy de mise en cache, le processus du 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 la quantité d'espace disque disponible sur le système de fichiers hébergeant le cache et supprimer le contenu lorsque l'espace disponible est inférieur au 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 garantit que le remplissage du cache ne remplira pas le disque par inadvertance.

Méthode native pour définir les indicateurs de cookies

Les cookies non sécurisés restent un vecteur d’attaque à haut risque. Comme indiqué sur le Mozilla Developer Network (MDN), une façon de garantir que les cookies ne sont pas consultés par des parties ou des scripts non intentionnels est de définir des indicateurs tels que HttpOnly et Secure dans l'en-tête Set-Cookie .

Dans les versions précédentes, nous avons fourni la directive set_cookie_flag à cette fin, telle qu'implémentée dans le module Cookie-Flag tiers disponible dans notre référentiel de modules dynamiques. NGINX Plus R23 introduit la directive proxy_cookie_flags pour remplacer cette directive et ce module.

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

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

Dans cet exemple, nous ajoutons les indicateurs HttpOnly , Secure et SameSite pour sécuriser le cookie de session appcookie créé par le serveur en amont, que NGINX Plus utilise pour la persistance de session comme décrit dans le Guide d'administration NGINX Plus .

À l'aide de la commande curl ou de l'outil de développement de votre navigateur, vous pouvez voir que les indicateurs HttpOnly , Secure et SameSite sont désormais définis pour appcookie .

< HTTP/1.1 200 OK< Serveur : nginx/1.19.4
< Date : Jeu, 08 déc. 2020 14:46:12 GMT
< Content-Type: application/octet-stream
< Content-Length: 9
< Connexion : keep-alive
< Set-Cookie : appcookie=appserver1 ; Secure ; HttpOnly ; SameSite=Strict
< Content-Type : text/html

Avec NGINX Plus R23 , vous pouvez également ajouter l'indicateur SameSite aux cookies avec la directive sticky , comme dans cet exemple (les paramètres httponly et secure sont pris en charge depuis NGINX Plus R6) :

Définition des variables dans le module Stream

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

Voici un exemple qui construit des valeurs complexes et composées à partir de plusieurs variables.

Un cas d’utilisation plus sophistiqué utilise 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 client effectue une requête DNS, en conservant chaque enregistrement pendant 24 heures.

Vous pouvez ensuite utiliser l' API NGINX Plus pour savoir quand chaque client a effectué sa demande DNS la plus récente 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 NGINX

Le module JavaScript NGINX (njs) a été mis à jour pour0.5.0 . Cette version introduit le module Buffer , qui est analogue au module Buffer de Node.js. Les objets tampon facilitent le travail avec des données binaires, au lieu de s'appuyer sur des chaînes.

D’autres améliorations notables du module sont le module Query String pour un accès facile aux paires clé-valeur transmises dans l’URL et la prise en charge du backtrace au niveau de la ligne pour le débogage.

Modifications apportées aux modules dynamiques

Nouveau module SPNEGO pour Kerberos

La prise en charge de l'authentification SPNEGO Kerberos est désormais disponible dans le référentiel de modules dynamiques NGINX Plus. Pour obtenir des instructions d'installation et des pointeurs vers plus d'informations, consultez le Guide d'administration NGINX Plus .

Module Cookie-Flags obsolète

Comme détaillé dans la méthode native de définition des indicateurs de cookies ci-dessus, la nouvelle directive proxy_cookie_flags remplace la directive set_cookie_flag implémentée dans le module Cookie-Flag tiers, qui est désormais obsolète et dont la suppression est prévue dans NGINX Plus R26 . Si votre configuration inclut 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 et supérieure, il est important de mettre à jour le fichier de configuration NGINX pour éviter les références à une configuration njs obsolète :

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

Correction de bugs notables

Les contrôles d'intégrité qui utilisaient la directive require dans un bloc de correspondance pour tester que les variables n'étaient pas vides n'auraient peut-être pas détecté de serveurs en amont défectueux si la réponse était supérieure à la valeur de la directive proxy_buffer_size .

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R23 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, 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 dès aujourd'hui avec un essai gratuit de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.