Anunciamos NGINX Plus R23

Nos complace anunciar la disponibilidad de NGINX Plus Release 23 (R23) . Basado en NGINX de código abierto, NGINX Plus es el único equilibrador de carga de software, proxy inverso y puerta de enlace API.

Las nuevas características de NGINX Plus R23 incluyen:

• Comprobaciones del estado de gRPC : probar activamente que un servicio gRPC puede manejar solicitudes antes de enviarlas aumenta significativamente la confiabilidad.
• Soporte de instalación sin privilegios : NGINX Plus ahora puede ser instalado y actualizado por un usuario sin privilegios (no root ). Esta solución totalmente compatible se alinea con la tendencia creciente hacia modelos de seguridad de confianza cero.
• Compatibilidad con PKCE de OpenID Connect : NGINX Plus R23 implementa la extensión Proof Key for Code Exchange (PKCE) en el flujo de código de autorización de OpenID Connect. PKCE previene varios tipos de ataques y permite intercambios OAuth seguros con clientes públicos.

Para completar esta versión se incluyen un control más detallado sobre SSL/TLS, un método nativo para configurar indicadores de cookies y una configuración de variables en el módulo Stream. Las actualizaciones del ecosistema NGINX Plus incluyen los nuevos módulos Buffer y Query String para el módulo JavaScript de NGINX, el nuevo módulo dinámico SPNEGO para Kerberos y mejoras en el módulo dinámico Prometheus-njs.

Cambios importantes en el comportamiento

• Módulo obsoleto : el módulo de terceros Cookie-Flag está obsoleto y se reemplaza por la nueva directiva proxy_cookie_flags . El módulo se eliminará en NGINX Plus R26 . Para obtener más detalles, consulte Método nativo para configurar indicadores de cookies .
• Nuevos sistemas operativos compatibles :
  • Alpine 3.12 (x86_64, aarch64)
  • Debian 10 (aarch64; x86_64 se admite desde NGINX Plus R17 )
• Sistemas operativos antiguos eliminados o que se eliminarán:
  • Alpine 3.9 ya no recibe soporte; la versión compatible más antigua es la 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ ya no recibe soporte; la versión compatible más antigua es 7.4
  • Ubuntu 19.10 ya no recibe soporte
  • Debian 9 se eliminará en NGINX Plus R24

Nuevas funciones en detalle

Comprobaciones de estado de gRPC

Cuando se implementa como balanceador de carga, NGINX Plus puede monitorear el estado de los servidores backend (ascendentes) al realizar controles de estado activos . NGINX Plus R23 admite el protocolo de verificación del estado de gRPC , lo que le permite probar con precisión si los servidores gRPC backend pueden manejar nuevas solicitudes. Esto es particularmente valioso en entornos dinámicos y en contenedores. Al crear nuevas instancias de un servicio gRPC, es importante enviar solicitudes solo una vez que el servicio esté "completamente activo". Esto requiere una comprobación de estado que vaya más allá de mirar el puerto TCP o verificar la disponibilidad del URI HTTP: una comprobación en la que el propio servicio indique si está listo para recibir solicitudes.

Para los servicios gRPC que implementan el protocolo de verificación del estado de gRPC, la configuración es sencilla.

Esta configuración equilibra la carga de todas las solicitudes al grupo ascendente grpc_backend . La directiva health_check incluye el parámetro type=grpc para invocar el método Check del servicio Health de cada servidor ascendente. Los servicios que responden con SERVIR se consideran saludables. El parámetro obligatorio garantiza que cuando se inicia NGINX Plus, o se introduce un nuevo servidor al grupo ascendente, el tráfico no se reenvía hasta que se aprueba una verificación de estado (de lo contrario, se asume que los nuevos servicios están en buen estado de manera predeterminada).

Si hay varios servicios gRPC expuestos en cada servidor ascendente, entonces el servicio más significativo (uno con servicios dependientes o subordinados) se puede monitorear especificando su nombre como valor del parámetro grpc_service como en este ejemplo:

Para los servicios gRPC que no implementan el protocolo de verificación de estado de gRPC, podemos probar si el servidor ascendente al menos responde a las solicitudes de gRPC, porque en ese caso envía un código de estado de error en respuesta al método Check . Con la configuración en grpc_health.conf , esperamos que un servicio que no implementa el protocolo gRPC responda con el código de estado 12(NO IMPLEMENTADO) .

También podemos comprobar que un servicio gRPC es capaz de responder a las solicitudes entrantes sin necesidad de modificar el código del backend. Podemos utilizar este enfoque para supervisar cualquier servicio gRPC:

Instalación de usuario sin privilegios

En versiones anteriores, NGINX Plus funcionaba con un mínimo de procesos ejecutándose como el usuario privilegiado root . Por ejemplo, las instrucciones de instalación en la Guía de administración de NGINX Plus crean estos procesos:

$ ps auxf | grep nginx root ...  9068 888 ?  Ss 21:44 0:00 nginx: proceso maestro nginx nginx ...  9712 3572 ?  S 21:44 0:00 \_ nginx: proceso de trabajo

Como se muestra, el proceso maestro se ejecuta con privilegios de root . Todos los demás procesos (trabajadores y gestión de caché) utilizan la cuenta de usuario sin privilegios nginx .

Es posible que los sistemas críticos que manejan datos confidenciales no quieran utilizar el usuario root . En este caso, NGINX Plus R23 se puede instalar y ejecutar como un usuario sin privilegios. Proporcionamos un script de instalación, ngxunprivinst.sh , en nuestro repositorio de GitHub para su uso en los siguientes sistemas operativos:

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

Nota:  Si hay algún oyente de NGINX Plus configurado en puertos inferiores a 1024 (por ejemplo, 80 o 443), el proceso maestro debe tener privilegios de root (pero aún puede instalar NGINX Plus con una cuenta de usuario sin privilegios).

Para utilizar el script de instalación, ejecute los siguientes comandos. (Para ver todos los comandos ngxunprivinst.sh disponibles, ejecute el script sin un parámetro de nombre de comando o consulte el código del script en el repositorio de GitHub).

1. Descargue el script y asegúrese de que sea ejecutable:

   $ chmod +x ngxunprivinst.sh

2. Copie su certificado y clave NGINX Plus ( nginx-repo.crt y nginx-repo.key ) al directorio local. Las opciones -c y -k están incluidas en todos los comandos ngxunprivinst.sh para identificarlos.

3. Enumere las versiones de NGINX Plus disponibles en el repositorio de NGINX Plus.

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

4. Obtenga el paquete deseado (aquí estamos obteniendo NGINX Plus R23-1 ). La opción -p especifica el directorio de instalación:

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

5. Instale los paquetes que necesita (aquí estamos instalando NGINX Plus y el módulo JavaScript de 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. Inicie NGINX, incluida la opción -p para especificar la ruta, -c para nombrar el archivo de configuración y -e para nombrar el registro de errores.

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

   Incluimos la opción -e para suprimir el mensaje de advertencia que de lo contrario aparece. Antes de que NGINX Plus haya leído su configuración durante el inicio, escribe en el registro de errores predeterminado, /var/log/nginx/error.log . Los usuarios sin privilegios no tienen permiso para crear ni escribir en este archivo, lo que genera una advertencia. Una vez que se lee la configuración, la directiva error_log establece el registro de errores en una ubicación en la que el usuario sin privilegios puede escribir.

7. (Opcional) Para verificar que NGINX Plus se esté ejecutando como un usuario no root , ejecute este comando:

   $ ps auxf | grep nginx nginxrun ...  9068 888 ?  Ss 21:55 0:00 nginx: proceso maestro nginxrun ...  9712 3572 ?  S 21:55 0:00 \_ nginx: proceso de trabajo

Compatibilidad con PKCE de OpenID Connect

Proof Key for Code Exchange ( PKCE ) es una extensión agregada recientemente al flujo de código de autorización de OpenID Connect (OIDC) para prevenir varios tipos de ataques y asegurar el intercambio de OAuth con clientes públicos. Para NGINX Plus R23 , hemos actualizado nuestra implementación de referencia de OpenID Connect para admitir la extensión. PKCE será obligatorio con OAuth 2.1 .

El cambio específico es reemplazar client_secret con dos nuevos valores en el desafío del código:

• desafío de código
• verificador de código

Para abordar diferentes ataques, especialmente en dispositivos móviles, el desafío para un token (ya sea un token de acceso, ID o actualización) se ha ajustado de la siguiente manera:

1. NGINX Plus genera (y recuerda) un code_verifier .
2. NGINX Plus redirige al usuario final para iniciar sesión en la página de inicio de sesión del proveedor de identidad (IdP) OIDC. La solicitud incluye una versión en hash del code_verifier denominada code_challenge .
3. El IdP envía un código de autenticación para el usuario a NGINX Plus.
4. Según el estado compartido, NGINX Plus puede encontrar el code_verifier generado y enviar la solicitud para intercambiar el código de autorización por un conjunto de tokens desde el punto final del token del IdP.

Antes de agregar PKCE, era suficiente que NGINX Plus compartiera un secreto de cliente estático con el IdP.
En la implementación de referencia OIDC actualizada, NGINX Plus puede manejar flujos de códigos de autorización tanto para PKCE como para la metodología de secreto del cliente.

A continuación se muestra una configuración de ejemplo que habilita el flujo de código de autorización extendido con PKCE:

La nueva variable $oidc_pkce_enable actúa como un interruptor para el flujo PKCE. Si se establece en1 Para un dominio específico, se utiliza el flujo PKCE. Si se establece en0 (predeterminado), se utiliza el flujo de código de autorización que no es PKCE.

Otras mejoras en NGINX Plus R23

Control detallado sobre conexiones SSL/TLS

TLS v1.3 permite una seguridad más fuerte que las versiones TLS anteriores, con cifrado de extremo a extremo entre servidores y entre servidores y sus clientes. NGINX Plus R23 proporciona acceso directo a la configuración de OpenSSL para un control detallado sobre TLS v1.3.

Creación de un servidor HTTPS predeterminado sin certificado ni clave

En versiones anteriores, el bloque de servidor predeterminado para el tráfico HTTPS protegido con TLS tenía que incluir las directivas ssl_certificate y ssl_certificate_key , lo que requería la creación de un certificado y una clave autofirmados “ficticios”.

La directiva ssl_reject_handshake elimina el requisito de un certificado y una clave, como en esta configuración de ejemplo:

Configuración directa de OpenSSL

NGINX Plus R23 le brinda un control más preciso sobre cómo NGINX Plus maneja SSL/TLS con OpenSSL 1.0.2 y versiones posteriores.

Los siguientes casos de uso aprovechan el nuevo nivel de control:

• Cifrados ChaCha – NGINX Plus usa ChaCha20 cuando un cliente (generalmente móvil) especifica ese cifrado en la parte superior de su lista de preferencias. ChaCha20 mejora notablemente el rendimiento de los clientes que lo admiten.

• Configuración de cifrado TLS v1.3 : en versiones anteriores, se usaba la directiva ssl_ciphers para establecer la lista de cifrados SSL/TLS preferidos de NGINX Plus, como en este ejemplo:

  Sin embargo, esta directiva no se aplica a TLS v1.3 porque la implementación de cifrados OpenSSL para TLS v1.3 no es compatible con las interfaces más antiguas. Para establecer la lista de cifrados para TLS v1.3, utilice la nueva directiva ssl_conf_command como en este ejemplo:

  Para configurar cifrados para TLS v1.2 y v1.3, incluya ambas directivas en la configuración:

• Actualización de conexiones proxy : basándose en el mecanismo de configuración de cifrado implementado por la directiva ssl_conf_command , NGINX Plus R23 le brinda el mismo control sobre los conjuntos de cifrado para conexiones proxy con estos protocolos:

  • HTTP y TCP – proxy_ssl_conf_command
  • gRPC – comando grpc_ssl_conf
  • uwsgi – uwsgi_ssl_conf_comando

El siguiente ejemplo muestra cómo configurar NGINX Plus para actualizar las solicitudes de clientes que usan versiones anteriores de TLS para usar servidores back-end que se sabe que admiten TLS v1.3.

El administrador de caché puede supervisar el espacio disponible en disco

Cuando NGINX Plus se configura como un proxy de almacenamiento en caché, el proceso del administrador de caché garantiza que el tamaño de la caché no exceda el límite establecido por el parámetro max_size en la directiva proxy_cache_path , eliminando el contenido al que se accedió menos recientemente.

Con NGINX Plus R23 , el administrador de caché también puede monitorear la cantidad de espacio disponible en disco en el sistema de archivos que alberga el caché y eliminar contenido cuando el espacio disponible es menor que el nuevo parámetro min_free de la directiva proxy_cache_path .

Esto significa que incluso cuando el caché comparte el mismo sistema de archivos que otros procesos, NGINX Plus garantiza que al completar el caché no se llene el disco inadvertidamente.

Método nativo para configurar indicadores de cookies

Las cookies no seguras siguen siendo un vector de ataque de alto riesgo. Como se señala en Mozilla Developer Network (MDN), una forma de garantizar que terceros o scripts no accedan a las cookies es establecer indicadores como HttpOnly y Secure en el encabezado Set-Cookie .

En versiones anteriores, proporcionamos la directiva set_cookie_flag para este propósito, tal como se implementó en el módulo de terceros Cookie-Flag disponible en nuestro repositorio de módulos dinámicos. NGINX Plus R23 presenta la directiva proxy_cookie_flags para reemplazar esa directiva y módulo.

El módulo obsoleto Cookie‑Flag se eliminará en NGINX Plus R26 , por lo que le recomendamos que ubique cualquier directiva set_cookie_flag en su configuración y las reemplace con la directiva proxy_cookie_flags lo antes posible.

A continuación se muestra una configuración de ejemplo para realizar un proxy a una aplicação backend simple que no configura ningún indicador de protección de cookies:

En este ejemplo, agregamos los indicadores HttpOnly , Secure y SameSite para proteger la cookie de sesión appcookie creada por el servidor ascendente, que NGINX Plus usa para la persistencia de la sesión como se describe en la Guía de administración de NGINX Plus .

Si utiliza el comando curl o la herramienta para desarrolladores de su navegador, podrá ver que los indicadores HttpOnly , Secure y SameSite ahora están configurados para appcookie .

< HTTP/1.1 200 OK< Servidor: nginx/1.19.4
< Fecha: Jueves, 08 de diciembre de 2020 14:46:12 GMT
< Tipo de contenido: aplicação/octet-stream
< Longitud del contenido: 9
< Conexión: keep-alive
< Establecer cookie: appcookie=appserver1; Segura; Solo HTTPS; Mismo sitio=Estricto
< Tipo de contenido: text/html

Con NGINX Plus R23 , también puedes agregar la bandera SameSite a las cookies con la directiva sticky , como en este ejemplo (los parámetros httponly y secure son compatibles desde NGINX Plus R6):

Configuración de variables en el módulo Stream

NGINX Plus R23 presenta la directiva set para configurar variables en configuraciones TCP/UDP, ampliando la capacidad comúnmente utilizada para el procesamiento del tráfico HTTP .

A continuación se muestra un ejemplo que construye valores compuestos complejos a partir de múltiples variables.

Un caso de uso más sofisticado emplea la directiva set para actualizar el almacén de clave-valor . En esta configuración para el equilibrio de carga de DNS, el almacén de clave-valor registra el momento en que cada dirección IP del cliente realiza una solicitud de DNS y conserva cada registro durante 24 horas.

Luego puede utilizar la API NGINX Plus para saber cuándo cada cliente realizó su solicitud de DNS más reciente durante las 24 horas anteriores.

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

Actualizaciones del ecosistema NGINX Plus

Mejoras en el módulo JavaScript de NGINX

El módulo JavaScript de NGINX (njs) se ha actualizado a0.5.0 . Esta versión presenta el módulo Buffer , que es análogo al módulo Buffer de Node.js. Los objetos de búfer facilitan el trabajo con datos binarios, en lugar de depender de cadenas.

Otras mejoras notables del módulo son el módulo de cadena de consulta para un acceso fácil a los pares clave-valor pasados en la URL y soporte de seguimiento inverso a nivel de línea para depuración.

Cambios en los módulos dinámicos

Nuevo módulo SPNEGO para Kerberos

El soporte para la autenticación Kerberos SPNEGO ahora está disponible en el repositorio de módulos dinámicos NGINX Plus. Para obtener instrucciones de instalación y sugerencias para obtener más información, consulte la Guía de administración de NGINX Plus .

Módulo de indicadores de cookies obsoleto

Como se detalla en Método nativo para configurar indicadores de cookies más arriba, la nueva directiva proxy_cookie_flags reemplaza la directiva set_cookie_flag implementada en el módulo de terceros Cookie-Flag, que ahora está obsoleto y está programado para su eliminación en NGINX Plus R26 . Si su configuración incluye la directiva set_cookie_flag , reemplácela con proxy_cookie_flags lo antes posible.

Actualizaciones del módulo Prometheus-njs

El módulo Prometheus-njs ahora expone métricas adicionales. También se ha actualizado para adaptarse a implementaciones que utilizan el módulo JavaScript NGINX (njs). Al actualizar Prometheus‑njs a la versión 1.3.1 y superiores, es importante actualizar el archivo de configuración de NGINX para evitar referencias a la configuración de njs obsoleta:

• La directiva js_include está obsoleta y ha sido reemplazada por la directiva js_import
• Las directivas js_content y js_set pueden hacer referencia a una función del módulo

Corrección de errores notable

Es posible que las comprobaciones de estado que usaron la directiva require en un bloque de coincidencia para probar que las variables no estuvieran vacías no hayan detectado servidores ascendentes en mal estado si la respuesta fue mayor que el valor de la directiva proxy_buffer_size .

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R23 lo antes posible. También recibirás varias correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicações.