Nos complace anunciar la disponibilidad de NGINX Plus Release 29 (R29). Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno, balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.
Las características nuevas y mejoradas de NGINX Plus R29 incluyen:
Nota : Si está actualizando desde una versión distinta a NGINX Plus R28, asegúrese de consultar la sección Cambios importantes en el comportamiento en los blogs de anuncios anteriores para todas las versiones entre su versión actual y esta.
El antiguo repositorio de paquetes plus-pkgs.nginx.com se desmantela inmediatamente con el lanzamiento de NGINX Plus R29. Este repositorio no se ha actualizado desde NGINX Plus R25 y se recomienda encarecidamente utilizar el repositorio de paquetes pkgs.nginx.com que se introdujo en NGINX Plus R24 .
Nuevos sistemas operativos compatibles:
Sistemas operativos más antiguos eliminados:
Sistemas operativos antiguos obsoletos y programados para su eliminación en NGINX Plus R30:
De acuerdo con el anuncio de EOL de ModSecurity , NGINX Plus R29 elimina el soporte de los paquetes de ModSecurity. Si es cliente de NGINX Plus y utiliza paquetes ModSecurity, pronto podrá optar por un programa de intercambio entre ModSecurity y NGINX App Protect . Los detalles sobre esto estarán disponibles pronto y puedes comunicarte con tu contacto en F5 para obtener más información.
MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería de publicación-suscripción popular y liviano, ideal para conectar dispositivos y aplicações de IoT (clientes) a través de Internet. Permite a los clientes publicar mensajes sobre un tema específico y suscribirse a otros temas. Los clientes suscritos reciben todos los mensajes publicados en ese tema, lo que permite un intercambio de datos eficiente y tolerante a fallas entre muchos dispositivos y servicios.
En el corazón de una arquitectura MQTT hay un bróker. Un broker es un servidor responsable de rastrear a los clientes y cualquier tema al que estén suscritos, procesar mensajes y enrutar esos mensajes a los sistemas apropiados. NGINX Plus R29 es compatible con MQTT 3.1.1 y MQTT 5.0 . Actúa como proxy entre clientes y corredores, lo que simplifica la arquitectura del sistema, descarga tareas y reduce costos.
El conjunto de características inicial de MQTT permite:
El protocolo MQTT define varios tipos de mensajes, incluidos CONECTAR, PUBLICAR y SUSCRIBIRSE. NGINX Plus R29 puede analizar y reescribir activamente partes de mensajes MQTT CONNECT, lo que permite escenarios de configuración que antes solo eran posibles con scripts personalizados.
El análisis y la reescritura de mensajes MQTT deben definirse en el contexto Stream de un archivo de configuración NGINX y es posible con ngx_stream_mqtt_preread_module
y módulos ngx_stream_mqtt_filter_module
.
Ejemplos de MQTT
Modificar el identificador de cliente predeterminado enviado por un dispositivo MQTT permite a NGINX ocultar información confidencial, como el número de serie de un dispositivo. En este primer ejemplo, el identificador se reescribe a la dirección IP del dispositivo.
Nota: No se recomienda utilizar la dirección IP de un dispositivo como identificador de cliente MQTT en un entorno de producción.
flujo { mqtt activado;
servidor { escuchar 1883; proxy_pass 10.0.0.8:1883; mqtt_set_connect clientid '$remote_addr'; } }
Dada la naturaleza efímera de los clientes MQTT, no se puede confiar simplemente en el nombre de host o la dirección IP de un dispositivo para establecer sesiones persistentes con agentes de equilibrio de carga. En este ejemplo, el identificador de cliente MQTT de un dispositivo actúa como una clave hash para persistir las conexiones a agentes MQTT individuales en un clúster con equilibrio de carga:
transmisión { mqtt_preread activado;
corredores ascendentes{ zona tcp_mem 64k; hash $mqtt_preread_clientid consistente;
servidor 10.0.0.7:1883; # agente mqtt 1 servidor 10.0.0.8:1883; # agente mqtt 2 servidor 10.0.0.9:1883; # agente mqtt 3 }
servidor { escuchar 1883; proxy_pass brokers; proxy_connect_timeout 1s; } }
Los desarrollos futuros de MQTT en NGINX Plus pueden incluir el análisis de otros tipos de mensajes MQTT, así como un análisis más profundo del mensaje CONNECT para habilitar funciones como:
Nos encantaría conocer tus comentarios sobre las características que más te interesan. Déjanos saber lo que piensas en los comentarios.
SAML (Security Assertion Markup Language) es un estándar de federación abierto que permite a un proveedor de identidad (IdP) autenticar a los usuarios para acceder a un recurso (garantizando que el usuario final es, de hecho, quien dice ser) y pasar esa información de autenticación, junto con los derechos de acceso del usuario en ese recurso, a un proveedor de servicios (SP) para su autorización.
Con una larga trayectoria como proveedor de un medio seguro para intercambiar datos de identidad, SAML es un protocolo ampliamente adoptado para intercambiar información de autenticación y autorización entre un IdP y un SP.
Las principales razones por las que las empresas e instituciones gubernamentales deciden adoptar SAML incluyen:
SAML también ofrece varios beneficios:
La implementación de referencia actual de SAML utiliza SAML 2.0 y está construida utilizando el marco NGINX JavaScript (njs). En esta implementación, NGINX Plus actúa como un SP SAML, lo que le permite participar en una configuración SSO con un IdP SAML. La implementación actual también depende del almacén de clave-valor , que es una característica existente de NGINX Plus y, como tal, no es adecuada para NGINX Open Source sin modificaciones adicionales.
La compatibilidad con SAML en NGINX Plus está disponible como una implementación de referencia en GitHub. El repositorio de GitHub incluye una configuración de muestra con instrucciones de instalación, configuración y ajuste para casos de uso específicos.
OpenTelemetry (OTel) es una tecnología y un estándar que se puede utilizar para supervisar, rastrear, solucionar problemas y optimizar aplicações. OTel funciona recopilando datos de telemetría de varias fuentes, como servidores proxy, aplicações u otros servicios en una pila de aplicação implementada.
Como proxy inverso y equilibrador de carga que reconoce protocolos, NGINX está en una posición ideal para iniciar llamadas de telemetría para rastrear solicitudes y respuestas de aplicação . Si bien los módulos OTel de terceros han estado disponibles durante algún tiempo, nos complace anunciar soporte nativo para OTel en NGINX Plus con un nuevo módulo dinámico .
El nuevo módulo ngx_otel_module
se puede instalar usando el paquete nginx-plus-module-otel
y proporciona varias mejoras clave para los módulos de terceros, que incluyen:
Más detalles sobre el módulo dinámico OTel están disponibles en la documentación de NGINX .
Ejemplos de rastreo de OTel
A continuación se muestra un ejemplo de seguimiento OTel básico de una aplicação servida directamente por NGINX:
módulo de carga módulos/ngx_otel_module.so;
eventos {}
http { hotel_exporter { punto final localhost:4317; }
servidor { escuchar 127.0.0.1:8080;
hotel_trace activado; otel_span_name aplicación1; } }
En el siguiente ejemplo, heredamos los contextos de seguimiento de las solicitudes entrantes y registramos los intervalos solo si se muestrea un intervalo principal. También propagamos contextos de seguimiento y decisiones de muestreo a servidores ascendentes.
módulo de carga módulos/ngx_otel_module.so;
http { servidor { ubicación / { otel_trace $otel_parent_sampled; otel_trace_context propagate; proxy_pass http://backend; } } }
En este ejemplo basado en proporciones, el seguimiento se configura para un porcentaje del tráfico (en este caso, el 10 %):
http { # seguimiento del 10% de las solicitudes split_clients "$otel_trace_id" $ratio_sampler { 10% activado; * desactivado; }
# o podemos rastrear el 10% de las sesiones de usuario
split_clients "$cookie_sessionid" $session_sampler { 10% activado; * desactivado; }
servidor { ubicación / { otel_trace $ratio_sampler; otel_trace_context inyectar;
contraseña_proxy http://backend; } } }
En este ejemplo controlado por API, el seguimiento se habilita manipulando el almacén de clave-valor a través del punto final /api:
http { keyval "otel.trace" $trace_switch zona=nombre;
servidor { ubicación / { otel_trace $trace_switch; otel_trace_context inyectar; proxy_pass http://backend; }
ubicación /api { api write=on; } } }
Tras nuestro anuncio de paquetes binarios de vista previa para NGINX Open Source , nos complace anunciar paquetes QUIC experimentales para NGINX Plus R29. Esto permite probar y evaluar HTTP/3 con NGINX Plus.
Con una nueva pila de protocolos subyacente, HTTP/3 lleva UDP y QUIC a la capa de transporte. QUIC es un protocolo de transporte encriptado diseñado para mejorar TCP al proporcionar multiplexación de conexión y resolver problemas como el bloqueo de cabecera de línea. Reimplementa y mejora una serie de capacidades TCP de HTTP/1.1 y HTTP/2, incluido el establecimiento de conexión, el control de la congestión y la entrega confiable. QUIC también incorpora TLS como un componente integral, a diferencia de HTTP/1.1 y HTTP/2 que tienen TLS como una capa separada. Esto significa que los mensajes HTTP/3 son inherentemente seguros ya que se envían a través de una conexión cifrada de forma predeterminada.
Normalmente, para una comunicación segura y una funcionalidad criptográfica, NGINX Plus se basa en OpenSSL , haciendo uso de las bibliotecas SSL/TLS que vienen con los sistemas operativos. Sin embargo, debido a que las interfaces TLS de QUIC no son compatibles con OpenSSL al momento de escribir este artículo, se necesitan bibliotecas de terceros para proporcionar la funcionalidad TLS faltante que requiere HTTP/3.
Para abordar esta inquietud, desarrollamos una capa de compatibilidad OpenSSL para QUIC, eliminando la necesidad de crear y enviar bibliotecas TLS de terceros como quictls, BoringSSL y LibreSSL. Esto ayuda a administrar la experiencia QUIC+HTTP/3 de extremo a extremo en NGINX sin la carga de una implementación TLS personalizada ni la dependencia de cronogramas y hojas de ruta de bibliotecas de terceros.
Nota : La capa de compatibilidad de OpenSSL está incluida en los paquetes experimentales NGINX Plus QUIC+HTTP/3 y requiere OpenSSL 1.1.1 o superior para proporcionar TLSv1.3 (que es requerido por el protocolo QUIC). Aún no implementa 0-RTT.
Configuración de muestra de QUIC+HTTP/3
Veamos una configuración de muestra de QUIC+HTTP/3 en NGINX Plus:
http { formato_de_registro rápido '$dirección_remota - $usuario_remoto [$tiempo_local]' '"$solicitud" $estado $bytes_del_cuerpo_enviados ' '"$http_referer" "$http_user_agent" "$http3"';
access_log registros/access.log quic;
servidor { # para una mejor compatibilidad se recomienda # usar el mismo puerto para quic y https listen 8443 quic reuseport; listen 8443 ssl;
certificado_ssl certs/ejemplo.com.crt; clave_certificado_ssl certs/ejemplo.com.clave;
ubicación / { # requerido para que los navegadores los dirijan al puerto rápido add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }
De manera similar a nuestra implementación de HTTP/2 , cuando NGINX Plus actúa como proxy, las conexiones QUIC+HTTP/3 se realizan en el lado del cliente y se convierten a HTTP/1.1 cuando se conecta a servicios backend y upstream.
Los paquetes experimentales NGINX Plus QUIC+HTTP/3 están disponibles en un repositorio separado, accesible con certificados y claves NGINX Plus existentes. La instalación de los paquetes experimentales QUIC es similar a una instalación estándar de NGINX Plus . Asegúrese de utilizar el repositorio QUIC, como se destaca en los pasos de instalación.
Puede consultar Configuración de NGINX para QUIC+HTTP/3 para obtener más información sobre cómo configurar NGINX para QUIC+HTTP/3. Para obtener información sobre todas las nuevas directivas y variables, consulte la sección Configuración del archivo README de nginx-quic .
Próximos pasos
En un futuro cercano, planeamos fusionar el código QUIC+HTTP/3 en la rama principal de NGINX. La última versión de la línea principal de NGINX con soporte QUIC+HTTP/3 se fusionará en una próxima versión de NGINX Plus. Se espera un anuncio sobre la disponibilidad oficial del soporte QUIC+HTTP/3 en NGINX Plus a finales de este año.
La compatibilidad con OpenID Connect (OIDC) se introdujo en NGINX Plus R15 y luego se mejoró significativamente en versiones posteriores. NGINX Plus R29 continúa mejorando OIDC, con las siguientes incorporaciones.
Compatibilidad con tokens de acceso
Los tokens de acceso se utilizan en la autenticación basada en tokens para permitir que un cliente OIDC acceda a un recurso protegido en nombre del usuario. NGINX Plus recibe un token de acceso después de que un usuario se autentica y autoriza el acceso con éxito, y luego lo almacena en el almacén de clave-valor. NGINX Plus puede pasar ese token en el encabezado de autorización HTTP como un token portador para cada solicitud que se envía a la aplicação descendente.
Nota : NGINX Plus no verifica la validez del token de acceso en cada solicitud (como lo hace con el token de identificación) y no puede saber si el token de acceso ya ha expirado. Si la vida útil del token de acceso es menor que la del token de identificación, debe utilizar la directiva proxy_intercept_errors
. Esto interceptará y redirigirá las respuestas 401 no autorizadas
a NGINX y actualizará el token de acceso.
Para obtener más información sobre OpenID Connect y la validación de JSON Web Token (JWT) con NGINX Plus, consulte Autenticación de usuarios en aplicações existentes con OpenID Connect y NGINX Plus .
Argumentos añadidos en el punto final de autenticación de OIDC
Algunos proveedores de identidad, como Keycloak , permiten agregar argumentos de cadena de consulta adicionales a la solicitud de autenticación para habilitar capacidades adicionales. Por ejemplo, Keycloak permite especificar un IdP predeterminado agregando un parámetro kc_idp_hint
a la solicitud de autenticación. Como parte de esta mejora, el usuario puede especificar argumentos adicionales para el punto final de autorización de OIDC.
En NGINX Plus R28, agregamos soporte de contador SSL adicional para errores de protocolo de enlace y fallas de validación de certificados en los módulos HTTP y Stream para conexiones del lado del cliente y del lado del servidor. Nuestro módulo Prometheus-njs , que convierte las métricas de NGINX Plus a un formato compatible con Prometheus, ahora admite estos contadores.
internal_redirect
La nueva directiva y módulo internal_redirect
permiten redirecciones internas después de verificar los límites de procesamiento de solicitudes , los límites de procesamiento de conexión y los límites de acceso .
A continuación se muestra un ejemplo de configuración de internal_redirect
:
http { zona_de_solicitud_límite $jwt_claim_sub zona=jwt_sub:10m tasa=1r/s;
servidor { ubicación / { auth_jwt "reino"; auth_jwt_key_file key.jwk;
redirección interna @rate_limited; }
ubicación @rate_limited { interno; límite_solicitud zona=jwt_sub ráfaga=10;
contraseña_proxy http://backend ; } } }
En el ejemplo anterior, la autenticación JWT se realiza en el bloque de ubicación y, si el token es válido, la solicitud se pasa al controlador de contenido interno @rate_limited, donde se aplica un límite de tasa de solicitud basado en el valor del reclamo secundario. Esto sucede en el JWT antes de que la solicitud se pase al servicio ascendente.
Esta configuración particular evita un ataque de denegación de servicio (DoS) en el que un atacante envía una avalancha de solicitudes que contienen JWT legibles, codificados con un usuario particular como subcampo. Esa avalancha de solicitudes no pasará la autenticación, pero se contabilizará para el límite de velocidad. Al autenticar el JWT antes de pasar la solicitud al controlador de contenido, se garantiza que solo las solicitudes válidas cuenten para el límite de velocidad.
NGINX Plus R29 se basa en NGINX Open Source 1.23.4 y hereda los cambios funcionales y las correcciones de errores realizados desde que se lanzó NGINX Plus R28 (en NGINX 1.23.3 a 1.23.4).
Cambios
protocolos_ssl
( HTTP , transmisión , correo ) protocolos proxy_ssl
( HTTP , transmisión ) protocolos grpc_ssl
protocolos uwsgi_ssl
protocolos_ssl_de_sincronización_de_zona
Características
ngx_http_gzip_static_module
.Corrección de errores
ngx_http_autoindex_module
, ngx_http_dav_module
y la directiva include.error_page
para redirigir errores con código400
.syslog
, que no contenían información de que los errores ocurrieron al registrar en syslog
.Soluciones alternativas
El filtro zip no pudo usar la memoria preasignada.
Aparecieron alertas en los registros cuando se usó zlib-ng
. listen
se resuelve en múltiples direcciones, NGINX ahora ignora los duplicados dentro de estas direcciones.Para obtener la lista completa de nuevas características, cambios, correcciones de errores y soluciones alternativas heredadas de estas versiones, consulte el archivo CAMBIOS .
NGINX Plus R29 incorpora cambios de las versiones 0.7.9 a 0.7.12 del módulo NGINX JavaScript (njs). Se agregaron varias características interesantes a njs, entre ellas:
Para obtener una lista completa de todas las características, cambios y correcciones de errores de la versión 0.7.9 a la 0.7.12 de njs, consulte el registro de cambios de njs .
Se agregan los constructores Headers()
, Request()
y Response()
a la API Fetch, junto con otras mejoras:
función asíncrona makeRequest(uri, headers) { let h = new Headers(headers);
h.delete("bar");
h.append("foo", "xxx");
let r = new Request(uri, {headers: h});
return await ngx.fetch(r);
}
La API de Web Crypto se amplió para admitir el formato de clave web JSON (JWK) y importKey() ahora toma claves en formato JWK como entrada:
función asíncrona importSigningJWK(jwk) { return await crypto.subtle.importKey('jwk', jwk,
{nombre: "RSASSA-PKCS1-v1_5"},
verdadero, ['signo']);
}
njs 0.7.10 también agregó los métodos generateKey()
y exportKey()
. El método generateKey()
le permite generar una nueva clave para algoritmos simétricos o un par de claves para algoritmos de clave pública. El método exportKey()
toma un objeto CryptoKey
como entrada y devuelve la clave en un formato externo y portátil. Admite el formato JWK para exportar la clave como un objeto JSON.
Para obtener más detalles, consulte Web Crypto API .
El módulo XML se agregó en njs 0.7.10 para proporcionar soporte nativo para trabajar con documentos XML.
Ahora puede analizar una cadena o un búfer para un documento XML, que luego devuelve un objeto contenedor XMLDoc que representa el documento XML analizado:
const xml = require("xml"); let data = `<note><to b="bar" a= "foo">Tove</to><from>Jani</from></note>`;
let doc = xml.parse(data);
console.log(doc.note.to.$texto) /* 'Tove' */
console.log(doc.note.to.$attr$b) /* 'bar' */
console.log(doc.note.$tags[1].$texto) /* 'Jani' */
API de XMLNode para modificar documentos XML
La API XMLNode se agregó en njs 0.7.11 para modificar documentos XML:
Const xml = require("xml"); let data = `<note><to b="bar" a="foo">Tove</to><from>Jani</from></note>`;
let doc = xml.parse(data);
doc.$root.to.$attr$b = 'bar2';
doc.$root.to.setAttribute('c', 'baz');
eliminar doc.$root.to.$attr$a;
console.log(xml.serializeToString(doc.$root.to))
/* '<to b="bar2" c="baz">Tove</to>' */
doc.$root.to.removeAllAttributes();
doc.$root.from.$text = 'Jani2';
console.log(xml.serializeToString(doc))
/* '<nota><a>Tove</a><de>Jani2</de></nota>' */
doc.$root.to.$tags = [xml.parse(`<a/>`), xml.parse(`<b/>`)];
doc.$root.to.addChild(xml.parse(`<a/>`));
console.log(xml.serializeToString(doc.$root.to))
/* '<a></a><b></b><a></a></to>' */
doc.$root.to.removeChildren('a');
console.log(xml.serializeToString(doc.$root.to))
/* '<a><b></b></a>' */
Para obtener más detalles sobre todas las mejoras relacionadas con XML, consulte los documentos XML .
El módulo zlib se agregó en njs 0.7.12 y proporciona funcionalidad de compresión utilizando los algoritmos de inflado y desinflado.
Constante zlib = require('zlib'); zlib.deflateRawSync('αβγ').toString('base64') /* "O7fx3KzzmwE=" */
zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString() /* "αβγ" */
Para obtener más detalles sobre zlib, consulte los documentos de zlib .
Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R29 lo antes posible. Además de todas las nuevas y excelentes funciones, también obtendrá varias correcciones y mejoras adicionales, y estar actualizado ayudará a NGINX a ayudarlo si necesita 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. Comience hoy con una prueba gratuita de 30 días .
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.