Annonce de NGINX Plus R27

Prabhat Dixit

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus version 27 (R27). Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de serveur web, d’équilibreur de charge, de proxy inverse, de cache de contenu et de passerelle API.

Les fonctionnalités nouvelles et améliorées de NGINX Plus R27 comprennent :

• Connexions persistantes pour les contrôles d’intégrité – Dans les versions précédentes, NGINX Plus établissait une nouvelle connexion pour chaque contrôle d’intégrité. Le nouveau paramètre keepalive_time de la directive HTTP health_check permet d’utiliser des connexions persistantes pour les contrôles d’intégrité et de définir leur durée de vie. L’établissement de nouvelles connexions étant coûteux en ressources de calcul, leur réutilisation peut réduire considérablement l’utilisation du processeur lorsqu’un grand nombre de serveurs en amont sont présents.
• Prise en charge de Kernel TLS – NGINX Plus prend désormais en charge Kernel TLS (kTLS) sur trois systèmes d’exploitation répondant aux exigences requises : FreeBSD 13, RHEL 9.0+ et Ubuntu 22.04 LTS.
• Métriques TLS pour les serveurs en amont et les serveurs virtuels – NGINX Plus génère désormais des statistiques TLS pour chaque serveur en amont et chaque serveur virtuel lorsque le proxy via HTTPS est activé, en plus des statistiques globales qu’il générait dans les versions précédentes. Disposer de métriques côté client comme côté serveur facilite la résolution des problèmes liés aux négociations TLS.
• Personnalisation du code d’erreur en cas d’échec de la validation JWT – Dans NGINX Plus R25 et R26, vous pouvez définir des contrôles de validation JWT personnalisés, mais le code d’erreur renvoyé en cas d’échec de la validation est toujours 401 (Non autorisé). NGINX Plus R27 introduit le paramètre error dans la directive auth_jwt_require, ce qui vous permet de définir le code sur 401 ou 403 (Interdit) pour chaque contrôle afin de mieux distinguer les erreurs d’authentification des erreurs d’autorisation.
• Améliorations apportées aux modules NGINX JavaScript et Prometheus-njs – Les améliorations apportées au module NGINX JavaScript comprennent de nouvelles directives permettant d’affiner le comportement de la fonction ngx.fetch ainsi qu’un nouvel objet qui indique la version de njs sous forme de nombre hexadécimal. Le module Prometheus-njs peut désormais convertir des métriques NGINX Plus supplémentaires dans un format compatible avec Prometheus : le champ codes (qui indique le nombre d’occurrences de chaque code d’état HTTP pour les serveurs en amont et les serveurs virtuels), ainsi que les métriques générées par les modules Limit Connections et Limit Requests.

Pour compléter cette version figurent un nouveau numéro de version (8) pour l’API NGINX Plus et une répartition plus homogène des connexions lorsque le mode EPOLLEXCLUSIVE est utilisé dans les noyaux Linux.

Modifications importantes du comportement

Remarque : Si vous effectuez une mise à niveau depuis une version autre que NGINX Plus R26, veillez à consulter la section « Changements importants de comportement » dans les billets d’annonce de toutes les versions comprises entre votre version actuelle et celle-ci.

Nouveaux systèmes d’exploitation pris en charge :

• Alpine Linux 3.16
• RHEL 9.0+ (ajouté à NGINX Plus R26 après la version initiale)
• Ubuntu 22.04 LTS (ajouté à NGINX Plus R26 après la version initiale)

Anciens systèmes d’exploitation et architectures supprimés :

• Alpine 3.12, dont la fin de vie (EOL) a été atteinte le 1er mai 2022
• CentOS 8.1+, qui a atteint sa fin de vie (EOL) le 31 décembre 2021 (RHEL 8.1+ est toujours pris en charge, car sa date de fin de vie est différente)
• Architecture Power 8 (ppc64le ; concerne CentOS et RHEL)

Anciens systèmes d’exploitation et anciennes architectures obsolètes dont la suppression est prévue dans NGINX Plus R28 :

• Debian 10, qui arrivera en fin de vie en août 2022

Nouvelles fonctionnalités en détail

Connexions persistantes pour les contrôles d’intégrité

Connexions persistantes entre NGINX Plus et les serveurs en amont améliorent considérablement les performances dans les cas d’utilisation de proxy inverse et d’équilibrage de charge. Pour le proxy via HTTPS en particulier, le coût de calcul de la négociation TLS complète requise pour chaque nouvelle connexion peut solliciter fortement vos ressources informatiques, notamment dans les environnements de production comportant un grand nombre de serveurs en amont.

Dans les versions précédentes, NGINX Plus n’utilisait pas de connexions persistantes pour les contrôles d’intégrité, mais établissait une nouvelle connexion pour chaque sonde. NGINX Plus R27 introduit les connexions persistantes pour les contrôles d’intégrité HTTP. Le nouveau paramètre keepalive_time de la directive health_check définit la durée de vie de chaque connexion persistante, après laquelle une nouvelle connexion est établie. Nos tests indiquent que, pour le proxy via HTTPS, les connexions persistantes divisent par 10 à 20 l’utilisation du processeur liée aux contrôles d’intégrité sur les serveurs NGINX Plus. Elles permettent également d’économiser les ressources processeur des serveurs en amont.

L’exemple suivant active les connexions persistantes avec une durée de vie de 60 secondes. Compte tenu de la fréquence des contrôles d’intégrité de 1 seconde définie par le paramètre interval، NGINX Plus n’effectue la négociation TLS et l’établissement de la connexion qu’une seule fois tous les 60 contrôles d’intégrité.

Chargement de l’exemple de code…

Prise en charge de TLS au niveau du noyau

Transport Layer Security (TLS) est le protocole standard de facto pour le chiffrement des données sur Internet. Malheureusement, la protection des données augmente également la latence. L’implémentation de TLS dans le noyau (kTLS) améliore les performances lors de la diffusion de contenu statique en réduisant considérablement les opérations de copie nécessaires entre l’espace utilisateur et le noyau.

La combinaison de kTLS et de l’appel système « sendfile() » permet de chiffrer les données directement dans l’espace noyau avant de les transmettre à la pile réseau, au lieu de les copier dans l’espace utilisateur pour les chiffrer à l’aide de bibliothèques TLS, puis de les recopier dans l’espace noyau avant leur transmission. kTLS permet également de décharger le traitement TLS sur le matériel, notamment le traitement cryptographique symétrique TLS sur les périphériques réseau.

La prise en charge de kTLS nécessite trois conditions :

1. Le noyau du système d’exploitation le prend en charge
2. La distribution du système d’exploitation inclut la bibliothèque cryptographique OpenSSL 3.0+, compilée avec la prise en charge de kTLS
3. NGINX Plus (ou NGINX Open Source) est compilé avec la bibliothèque cryptographique OpenSSL 3.0+

En octobre 2021, nous avons ajouté la prise en charge de kTLS à NGINX Open Source 1.21.4 sur les plateformes qui satisfont aux exigences 1 et 2. Nous ajoutons désormais la prise en charge de kTLS dans NGINX Plus sur les plateformes suivantes :

• FreeBSD 13 (dans NGINX Plus R26 et versions ultérieures)
• RHEL 9.0+
• Ubuntu 22.04 LTS

Métriques TLS pour les serveurs en amont et les serveurs virtuels

Lorsque NGINX Plus est déployé en tant que proxy inverse ou équilibreur de charge, l’API NGINX Plus fournit un riche ensemble de métriques sur le trafic, les codes de réponse et la latence pour chaque serveur en amont et serveur virtuel, permettant ainsi aux clients d’observer et de surveiller les performances et la disponibilité des serveurs.

Dans les versions précédentes, NGINX Plus générait des métriques sur l’activité TLS et les erreurs à l’échelle du système lorsque des connexions HTTPS étaient utilisées entre NGINX Plus et les serveurs en amont, aussi bien dans les contextes http que stream (établies respectivement à l’aide des directives proxy_pass https://path-to-upstream et proxy_ssl on). Les statistiques portent sur les négociations de connexion, les échecs et les réutilisations de session (telles que configurées avec la directive proxy_ssl_session_reuse).

NGINX Plus R27 génère ces métriques TLS pour chaque serveur en amont dont la configuration inclut la directive « zone », ainsi que pour les serveurs virtuels dont la configuration inclut la directive « status_zone ». Disposer de métriques côté client comme côté serveur facilite le diagnostic des problèmes liés aux négociations TLS.

L’exemple suivant active la collecte de statistiques sur le serveur en amont « upstream1 » et sur le serveur virtuel qui lui transmet le trafic.

Chargement de l’exemple de code…

Cette sortie indique que le premier serveur en amont a participé à quatre négociations TLS et à deux reprises de session (par souci de concision, nous n’affichons qu’une partie de la sortie du premier serveur et omettons celle des autres serveurs en amont) :

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq{
  "peers": [
    {
      "id": 0,
      "server": "127.0.0.1:8081",
      "name": "127.0.0.1:8081",
      "backup": false,
      "weight": 1,
      "state": "up",
      "active": 0,
      "ssl": { "handshakes": 4, "handshakes_failed": 0, "session_reuses": 2 },
      "requests": 4,
      "header_time": 4,
      "response_time": 4,
      ...
    }
    ...
  ]
}

Cette sortie indique que NGINX Plus a participé à sept négociations TLS :

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq{
  "processing": 0,
  "requests": 7,
  "responses": {
    "1xx": 0,
    "2xx": 7,
    "3xx": 0,
    "4xx": 0,
    "5xx": 0,
    "codes": {
      "200": 7
    },
    "total": 7
  },
  "discarded": 0,
  "received": 546,
  "sent": 1134,
  "ssl": { "handshakes": 7, "handshakes_failed": 0, "session_reuses": 0 }
  ...
}

Notez que l’API NGINX Plus collecte toujours les métriques TLS globales disponibles dans les versions précédentes de NGINX Plus :

$ curl http://127.0.0.1:8000/api/8/ssl | jq{
  "handshakes": 21,
  "handshakes_failed": 0,
  "session_reuses": 6
}

Personnalisation du code d’erreur en cas d’échec de la validation JWT

NGINX Plus R25 a introduit<.htmla> la directive auth_jwt_require permettant de définir des vérifications personnalisées lors du processus de validation du JWT. Dans NGINX Plus R25 et R26, le code d’erreur renvoyé en cas d’échec de la validation est toujours 401 (Non autorisé).

NGINX Plus R27 introduit le paramètre « error » de la directive « auth_jwt_require », qui permet de définir le code sur 401 ou 403 (Interdit) indépendamment pour chaque directive. Lorsque la demande d’accès d’un utilisateur échoue, le choix du code permet d’indiquer s’il s’agit d’un échec d’authentification (le JWT n’est pas valide) ou d’un échec d’autorisation (la revendication requise est absente). Vous pouvez également créer des gestionnaires personnalisés pour les codes d’erreur, par exemple afin de renvoyer une page spéciale expliquant l’erreur (avec la directive « error_page ») ou de rediriger la requête vers un emplacement interne nommé pour un traitement ultérieur.

Le code d’état par défaut reste 401 en cas d’échec des types de vérifications JWT suivants :

• Les vérifications (non personnalisées) qui sont toujours effectuées
• Vérifications personnalisées configurées avec « auth_jwt_require », mais sans le paramètre « error »

S’il existe plusieurs directives « auth_jwt_require » dans un bloc « location », elles sont évaluées dans leur ordre d’apparition. Le traitement s’arrête au premier échec et le code d’erreur spécifié est renvoyé.

Dans cet exemple, la directive auth_jwt_require renvoie 403 si $req1 ou $req2 prend une valeur vide ou égale à 0 (zéro).

Chargement de l’exemple de code…

Améliorations apportées aux modules NGINX JavaScript et Prometheus-njs

NGINX Plus R27 intègre les versions 0.7.3 et 0.7.4 du module JavaScript NGINX et comprend les améliorations suivantes.

Directives supplémentaires pour l’API Fetch de njs

NGINX Javascript 0.5.3, intégré à NGINX Plus R24, a introduit la fonction « ngx.fetch » (également appelée API Fetch), qui permet d’instancier un client HTTP simple dans le contexte d’une connexion TCP/UDP. (Pour en savoir plus sur les cas d’utilisation de cette fonction, consultez l’article « Exploiter les services HTTP pour TCP.htmlUDP avec un client HTTP simple » sur notre blog.)

NGINX Plus R27 introduit les directives suivantes pour ajuster précisément le comportement de l’API Fetch :

• js_fetch_buffer_size[HTTP][Stream] – Définit la taille du tampon utilisé pour la lecture et l’écriture.
• js_fetch_max_response_buffer_size[HTTP][Stream] – Définit la taille maximale de la réponse reçue avec l’API Fetch.
• js_fetch_timeout[HTTP][Stream] – Définit le délai d’expiration pour la lecture et l’écriture entre deux opérations successives de lecture ou d’écriture (et non pour l’ensemble de la réponse). Si aucune donnée n’est transmise pendant ce délai, la connexion est fermée.
• js_fetch_verify[HTTP][Stream] – Active ou désactive la vérification du certificat du serveur HTTPS.

Numéro de version indiqué sous forme de nombre hexadécimal

Le nouvel objet « njs.version_number » indique la version du module njs sous forme de nombre hexadécimal. (L’objet « njs.version » existant renvoie la version sous forme de chaîne de caractères.)

Le module Prometheus-njs convertit des métriques supplémentaires

Le module Prometheus-njs, qui convertit les métriques NGINX Plus dans un format compatible avec Prometheus, peut désormais convertir les métriques exposées sur les points de terminaison supplémentaires suivants :

• /http/limit_conns
• /http/limit_reqs
• Le champ « codes » (qui indique le nombre de réponses pour chaque code d’état HTTP<.htmla>) sous /http/server_zones et /http/upstreams
• /stream/limit_conns

Autres améliorations de NGINX Plus R27

Changement de version de l’API NGINX Plus

Le numéro de version de l’API NGINX Plus passe de 7 à 8 afin de refléter l’ajout du champ ssl aux métriques rapportées pour les serveurs en amont et les serveurs virtuels, comme décrit dans Métriques TLS pour les serveurs en amont et les serveurs virtuels. Les numéros de version précédents fonctionnent toujours, mais les résultats n’incluent pas les métriques ajoutées dans les versions ultérieures de l’API.

Meilleure répartition des connexions en mode EPOLLEXCLUSIVE sous Linux

NGINX Plus R27 répartit les connexions plus uniformément entre les processus de travail NGINX lorsque le mode EPOLLEXCLUSIVE est utilisé dans les noyaux Linux. Normalement, dans ce mode, le noyau avertit uniquement le processus qui a été le premier à ajouter le socket d’écoute à l’instance EPOLL. Par conséquent, la plupart des connexions sont traitées par le premier processus de travail. NGINX ajoute désormais de nouveau le socket à intervalles réguliers afin de permettre aux autres processus de travail d’accepter des connexions.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R27 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 auprès du support.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le découvrir – 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.

À propos de l’auteur

Prabhat Dixit

Autres articles de Prabhat Dixit