Presentamos NGINX Plus R23

Liam CrillyDirector sénior de Gestión de Producto

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

Entre las nuevas funciones de NGINX Plus R23 se incluyen:

• Comprobaciones de estado de gRPC – Comprobar de forma activa que un servicio gRPC puede gestionar las solicitudes antes de enviárselas aumenta considerablemente la fiabilidad.
• Compatibilidad con la instalación sin privilegios – NGINX Plus ahora puede instalarse y actualizarse con un usuario sin privilegios (que no sea root). Esta solución totalmente compatible se ajusta a la creciente tendencia hacia los 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) para el flujo de código de autorización de OpenID Connect. PKCE evita varios tipos de ataques y permite intercambios OAuth seguros con clientes públicos.

Para completar esta versión se incluyen un control más granular de SSL/TLS, un método nativo para configurar los atributos de las cookies y la configuración de variables en el módulo Stream. Las novedades 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 for 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 ha sustituido por la nueva directiva proxy_cookie_flags. El módulo se eliminará en NGINX Plus R26. Para obtener más información, consulte Método nativo para configurar indicadores de cookies.
• Nuevos sistemas operativos compatibles:
  • Alpine 3.12 (x86_64, aarch64)
  • Debian 10 (aarch64; x86_64 es compatible desde NGINX Plus R17)
• Sistemas operativos antiguos eliminados o que se eliminarán:
  • Alpine 3.9 ya no es compatible; la versión más antigua compatible es la 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ ya no es compatible; la versión más antigua compatible es la 7.4
  • Ubuntu 19.10 ya no es compatible
  • Debian 9 se eliminará en NGINX Plus R24

Nuevas funcionalidades en detalle

Comprobaciones de estado de gRPC

Cuando se implementa como equilibrador de carga, NGINX Plus puede supervisar el estado de los servidores backend (upstream) mediante comprobaciones de estado activas. NGINX Plus R23 es compatible con el protocolo de comprobación de estado de gRPC, lo que le permite comprobar con precisión si los servidores gRPC backend pueden gestionar nuevas solicitudes. Esto resulta especialmente útil en entornos dinámicos y en contenedores. Al poner en marcha nuevas instancias de un servicio gRPC, es importante enviar solicitudes únicamente cuando el servicio esté «completamente operativo». Para ello, se necesita una comprobación de estado que vaya más allá de examinar el puerto TCP o verificar la disponibilidad del URI HTTP; es decir, 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 comprobación de estado de gRPC, la configuración es sencilla.

Cargando ejemplo de código…

Esta configuración distribuye la carga de todas las solicitudes entre el grupo de servidores ascendentes 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 SERVING se consideran en buen estado. El parámetro mandatory garantiza que, cuando se inicia NGINX Plus o se añade un nuevo servidor al grupo de servidores ascendentes, no se reenvíe tráfico hasta que se supere una comprobación de estado (de lo contrario, los nuevos servicios se consideran en buen estado de forma predeterminada).

Si hay varios servicios gRPC expuestos en cada servidor ascendente, se puede supervisar el servicio más importante (aquel del que dependen otros servicios o que tiene servicios subordinados) especificando su nombre como valor del parámetro grpc_service, como en este ejemplo:

Cargando ejemplo de código…

En el caso de los servicios gRPC que no implementan el protocolo de comprobación de estado de gRPC, podemos comprobar si el servidor ascendente responde al menos a las solicitudes gRPC, ya que, en ese caso, envía un código de estado de error en respuesta al método Check. Con la configuración de grpc_health.conf, esperamos que un servicio que no implemente el protocolo gRPC responda con el código de estado 12 (UNIMPLEMENTED).

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:

Cargando ejemplo de código…

Instalación para usuarios sin privilegios

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

$ 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

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

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

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

Nota: Si algún listener de NGINX Plus está configurado en un puerto inferior al 1024 (por ejemplo, el 80 o el 443), el proceso maestro debe tener privilegios de root (aunque puede instalar NGINX Plus con una cuenta de usuario sin privilegios).

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

1. Descarga el script y asegúrate de que sea ejecutable:

$ chmod +x ngxunprivinst.sh

1. Copie el certificado y la clave de NGINX Plus (nginx-repo.crt y nginx-repo.key) en el directorio local. Las opciones ‑c y ‑k se incluyen en todos los comandos de ngxunprivinst.sh para identificarlos.
2. Enumere las versiones de NGINX Plus disponibles en el repositorio de 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. Obtenga el paquete deseado (en este caso, 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

1. Instale los paquetes que necesite (en este caso, instalamos 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

1. Inicie NGINX e incluya la opción ‑p para especificar la ruta, ‑c para indicar el nombre del archivo de configuración y ‑e para indicar el nombre del registro de errores.

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

1. Incluimos la opción ‑e para suprimir el mensaje de advertencia que aparecería de otro modo. 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 este archivo ni escribir en él, lo que genera una advertencia. Una vez leída 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.
2. (Opcional) Para comprobar que NGINX Plus se ejecuta como un usuario distinto de root, ejecute este comando:

$ 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

Compatibilidad con PKCE en OpenID Connect

Proof Key for Code Exchange (PKCE) es una extensión añadida recientemente al flujo de código de autorización de OpenID Connect (OIDC) para evitar varios tipos de ataques y proteger el intercambio de OAuth con clientes públicos. Para NGINX Plus R23, hemos actualizado nuestra implementación de referencia de OpenID Connect para que sea compatible con esta extensión. PKCE será obligatorio con OAuth 2.1.

El cambio concreto consiste en sustituir client_secret por dos nuevos valores en el desafío de código:

• code_challenge
• code_verifier

Para hacer frente a distintos ataques, especialmente en dispositivos móviles, el desafío para un token (ya sea un token de acceso, de ID o de 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 a la página de inicio de sesión del proveedor de identidad (IdP) OIDC para que inicie sesión. La solicitud incluye una versión con hash de code_verifier denominada code_challenge.
3. El IdP envía un auth_code del usuario a NGINX Plus.
4. Gracias al 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 endpoint de tokens del IdP.

Antes de añadir PKCE, bastaba con que NGINX Plus compartiera un secreto de cliente estático con el IdP.
En la versión actualizada de la implementación de referencia de OIDC NGINX Plus puede gestionar flujos de código de autorización tanto con PKCE como con el método basado en secreto de cliente.

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

Cargando ejemplo de código…

La nueva variable $oidc_pkce_enable actúa como un interruptor para el flujo PKCE. Si se establece en 1 para un dominio específico, se utiliza el flujo PKCE. Si se establece en 0 (el valor predeterminado), se utiliza el flujo de código de autorización sin PKCE.

Otras mejoras de NGINX Plus R23

Control granular de las conexiones SSL/TLS

TLS v1.3 ofrece una seguridad más robusta que las versiones anteriores de TLS, con cifrado de extremo a extremo entre servidores, así como entre los servidores y sus clientes. NGINX Plus R23 proporciona acceso directo a la configuración de OpenSSL para ofrecer un control pormenorizado sobre TLS v1.3.

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

En versiones anteriores, el bloque server predeterminado para el tráfico HTTPS protegido mediante TLS debía incluir las directivas ssl_certificate y ssl_certificate_key, lo que obligaba a crear un certificado autofirmado «ficticio» y su correspondiente clave.

La directiva «ssl_reject_handshake» elimina la necesidad de disponer de un certificado y una clave, como se muestra en este ejemplo de configuración:

Cargando ejemplo de código…

Configuración directa de OpenSSL

NGINX Plus R23 le ofrece un control más preciso sobre cómo NGINX Plus gestiona 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 utiliza ChaCha20 cuando un cliente (normalmente móvil) especifica este cifrado como primera opción en su lista de preferencias. ChaCha20 mejora notablemente el rendimiento de los clientes compatibles.
• Configuración de cifrados de TLS v1.3 – En versiones anteriores, la directiva ssl_ciphers se utilizaba para establecer la lista de cifrados SSL/TLS preferidos de NGINX Plus, como en este ejemplo:

  Cargando ejemplo de código…

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

  Cargando ejemplo de código…

  Para establecer los cifrados tanto para TLS v1.2 como para TLS v1.3, incluya ambas directivas en la configuración:

  Cargando ejemplo de código…

• Actualización de conexiones mediante proxy – Basándose en el mecanismo de configuración de cifrados implementado por la directiva ssl_conf_command, NGINX Plus R23 ofrece el mismo control sobre los conjuntos de cifrado para las conexiones mediante proxy que utilizan estos protocolos:
  • HTTP y TCP – proxy_ssl_conf_command
  • gRPC – grpc_ssl_conf_command
  • uwsgi – uwsgi_ssl_conf_command

El siguiente ejemplo muestra cómo configurar NGINX Plus para actualizar las solicitudes de clientes que utilizan versiones anteriores de TLS, de modo que usen servidores backend compatibles con TLS v1.3.

Cargando ejemplo de código…

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

Cuando NGINX Plus se configura como proxy de caché, el proceso administrador de caché garantiza que el tamaño de la caché no supere el límite establecido por el parámetro max_size de la directiva proxy_cache_path, eliminando el contenido al que se ha accedido menos recientemente.

Con NGINX Plus R23, el administrador de caché también puede supervisar la cantidad de espacio disponible en el sistema de archivos donde se aloja la caché y eliminar contenido cuando el espacio disponible sea inferior al valor del nuevo parámetro min_free de la directiva proxy_cache_path.

Esto significa que, incluso cuando la caché comparte el mismo sistema de archivos con otros procesos, NGINX Plus garantiza que llenarla no ocupe accidentalmente todo el espacio del disco.

Cargando ejemplo de código…

Método nativo para configurar los atributos de las cookies

Las cookies no protegidas siguen siendo un vector de ataque de alto riesgo. Como se señala en Mozilla Developer Network (MDN), una forma de garantizar que las cookies no sean accesibles para terceros o scripts no autorizados es establecer indicadores como HttpOnly y Secure en la cabecera Set-Cookie.

En versiones anteriores, proporcionábamos la directiva set_cookie_flag para este fin, implementada en el módulo Cookie‑Flag de terceros disponible en nuestro repositorio de módulos dinámicos. NGINX Plus R23 incorpora la directiva proxy_cookie_flags para sustituir dicha directiva y módulo.

El módulo Cookie‑Flag obsoleto se eliminará en NGINX Plus R26, por lo que le recomendamos que localice cuanto antes todas las directivas set_cookie_flag de su configuración y las sustituya por la directiva proxy_cookie_flags.

A continuación se muestra un ejemplo de configuración para usar un proxy con una aplicación de backend sencilla que no establece por sí misma ninguna marca de protección de cookies:

Cargando ejemplo de código…

En este ejemplo, añadimos las marcas HttpOnly, Secure y SameSite para proteger la cookie de sesión appcookie creada por el servidor ascendente, que NGINX Plus utiliza para la persistencia de sesiones, tal como se describe en la Guía de administración de NGINX Plus.

Al usar el comando curl o las herramientas para desarrolladores de su navegador, puede comprobar que las marcas HttpOnly, Secure y SameSite ahora están configuradas para 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

Con NGINX Plus R23, también puede añadir la marca SameSite a las cookies mediante la directiva sticky, como en este ejemplo (los parámetros httponly y secure son compatibles desde NGINX Plus R6):

Cargando ejemplo de código…

Configuración de variables en el módulo Stream

NGINX Plus R23 incorpora la directiva «set» para definir variables en configuraciones TCP/UDP, ampliando así una funcionalidad utilizada habitualmente para el procesamiento del tráfico HTTP.

Este es un ejemplo que crea valores compuestos complejos a partir de varias variables.

Cargando ejemplo de código…

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

Cargando ejemplo de código…

A continuación, puede utilizar la API de NGINX Plus para saber cuándo realizó cada cliente su solicitud 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 de NGINX Plus

Mejoras en el módulo JavaScript de NGINX

El módulo JavaScript de NGINX (njs) se ha actualizado a la versión 0.5.0. Esta versión incorpora el módulo Buffer, que es análogo al módulo Buffer de Node.js. Los objetos Buffer facilitan el trabajo con datos binarios, en lugar de depender de cadenas de texto.

Otras mejoras destacables del módulo son el módulo Query String para acceder fácilmente a los pares clave-valor incluidos en la URL y la compatibilidad con trazas inversas a nivel de línea para la depuración.

Cambios en los módulos dinámicos

Nuevo módulo SPNEGO para Kerberos

La compatibilidad con la autenticación Kerberos mediante SPNEGO ya está disponible en el repositorio de módulos dinámicos de NGINX Plus. Para consultar las instrucciones de instalación y obtener más información, consulte la Guía de administración de NGINX Plus.

Módulo Cookie-Flags obsoleto

Como se detalla en «Método nativo para establecer indicadores de cookies» más arriba, la nueva directiva «proxy_cookie_flags» sustituye a la directiva «set_cookie_flag», implementada en el módulo de terceros Cookie-Flag, que ahora está obsoleto y cuya eliminación está prevista en NGINX Plus R26. Si su configuración incluye la directiva «set_cookie_flag», sustitúyala por «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 admitir implementaciones que utilizan el módulo JavaScript de NGINX (njs). Al actualizar Prometheus‑njs a la versión 1.3.1 o posterior, es importante actualizar el archivo de configuración de NGINX para evitar referencias a opciones de configuración obsoletas de njs:

• La directiva js_include está obsoleta y se ha sustituido por la directiva js_import directive
• Las directivas js_content y js_set pueden hacer referencia a una función de módulo

Corrección de error destacada

Es posible que las comprobaciones de estado que utilizaban la directiva require en un bloque match para comprobar que las variables no estuvieran vacías no detectaran servidores ascendentes en mal estado si la respuesta era mayor que el valor de la directiva proxy_buffer_size.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R23 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para la seguridad, el balanceo de carga y la puerta de enlace de API, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo con una prueba gratuita de 30 días. Compruebe por sí mismo cómo NGINX Plus puede ayudarle a ofrecer y escalar sus aplicaciones.

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly