Presentamos NGINX Plus R10

NGINX | 23 de agosto de 2016


[Editor – El módulo NGINX ModSecurity WAF para NGINX Plus dejó de comercializarse oficialmente el 1 de abril de 2022 y llegará al final de su vida útil el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al final de su vida útil<.htmla> en nuestro blog.]

Nos complace anunciar NGINX Plus Release 10 (R10), nuestra versión más importante hasta la fecha. NGINX Plus amplía NGINX Open Source con funcionalidades avanzadas y un servicio de soporte galardonado, lo que proporciona a los clientes una solución completa para la entrega de aplicaciones. Esta versión incorpora numerosas funciones nuevas que mejoran considerablemente la seguridad y el rendimiento de las aplicaciones entregadas mediante NGINX Plus, además de otras funciones que optimizan la integración de red y permiten personalizar NGINX Plus mediante scripts.

[Editor – Para obtener más información sobre las principales novedades de NGINX Plus R10, consulte estos recursos relacionados:

]

NGINX Plus R10 incluye la versión inicial de nuestro firewall de aplicaciones web (WAF), basado en ModSecurity y con soporte completo de NGINX, Inc. Los ataques contra aplicaciones web aumentaron un 50 % durante el último año y los ataques DDoS aumentaron más del doble, según Akamai. Ahora todas las aplicaciones corren el riesgo de sufrir ataques. NGINX ModSecurity WAF ayuda a proteger las aplicaciones web frente a usuarios malintencionados y ofrece a los clientes una herramienta versátil para mantener seguras sus aplicaciones y sus datos.

NGINX ModSecurity WAF bloquea a los intrusos

NGINX ModSecurity WAF se basa en el nuevo software ModSecurity 3 y se ejecuta de forma nativa en NGINX Plus. Está disponible como opción con coste adicional en nuestro repositorio de módulos dinámicos, cuenta con el soporte de NGINX, Inc. y se ha probado exhaustivamente con NGINX Plus. Colaboramos con Trustwave y mantendremos actualizaciones probadas a medida que añadamos funciones, mejoremos el rendimiento y solucionemos cualquier problema.

Dos nuevas funciones adicionales mejoran aún más las capacidades de seguridad de NGINX Plus:

  • Tokens web JSON – Muchos de nuestros clientes utilizan NGINX Plus como una puerta de enlace de API y nos han pedido una forma común y estándar de autenticar el acceso a las API en la capa de NGINX Plus. Para satisfacer esa necesidad, en esta versión hemos añadido compatibilidad con la autenticación mediante tokens web JSON (JWT). NGINX Plus ahora puede validar un JWT antes de permitir que los clientes accedan a las API. Esta función permite a los administradores de aplicaciones proteger el acceso a sus API mediante un estándar abierto, evitando la dependencia de un estándar propietario. La compatibilidad nativa con JWT también reduce la complejidad para los administradores de aplicaciones al trasladar las operaciones de autenticación –como la validación de tokens de OpenID Connect compatibles con OAuth 2.0– de los servidores de aplicaciones a NGINX Plus.
  • Compatibilidad «dual-stack» con certificados ECC y RSA – Con NGINX Plus R10, puede publicar servicios SSL/TLS utilizando certificados RSA y ECC. NGINX Plus selecciona el certificado óptimo en función de las capacidades de cada cliente, lo que permite a los clientes modernos utilizar certificados ECC más rápidos sin dejar de admitir clientes antiguos que solo son compatibles con RSA. Los certificados ECC pueden ser hasta tres veces más rápidos que los certificados RSA con un nivel de seguridad equivalente, lo que se traduce en más conexiones SSL/TLS por servidor y negociaciones SSL/TLS más rápidas.

Además de las funciones de seguridad, NGINX Plus R10 incluye:

  • Compatibilidad con proxy transparente – Aunque muchas aplicaciones HTTP modernas pueden configurarse para utilizar una cabecera X-Forwarded-For, algunas aplicaciones heredadas y otros servicios TCP o UDP utilizan la dirección IP de origen de la transacción con fines de registro, seguridad o autenticación. NGINX Plus ahora puede «suplantar» la dirección IP y el puerto de las conexiones HTTP y de las conexiones TCP y los datagramas UDP que reenvía a los servidores ascendentes. Esto permite proporcionar transparencia de IP, una configuración en la que NGINX Plus envía paquetes con la dirección IP del cliente remoto para que el servidor ascendente los perciba como procedentes de dicha dirección, en lugar de una dirección IP local del servidor NGINX Plus. Esta función también puede utilizarse para habilitar el retorno directo del servidor en protocolos basados en UDP.
  • Compatibilidad con el módulo JavaScript de NGINX – El módulo JavaScript de NGINX es el lenguaje de configuración y control de nueva generación para NGINX y NGINX Plus, que ofrece a los usuarios un control exhaustivo y preciso sobre cómo se entregan y protegen sus aplicaciones. En esta versión preliminar, el módulo JavaScript de NGINX amplía el control sobre el tráfico HTTP, TCP y UDP, generando respuestas y tomando decisiones precisas para dirigir las solicitudes a los servidores óptimos.

NGINX Plus R10 en detalle

Firewall de aplicaciones web NGINX ModSecurity

La principal novedad de NGINX Plus R10 es la versión inicial de nuestro WAF, basado en la conocida y fiable tecnología ModSecurity. Desde su lanzamiento inicial como software de código abierto en 2002, ModSecurity ha contribuido a proteger algunas de las propiedades web más grandes del mundo frente a usuarios malintencionados. Se le suele llamar la «navaja suiza®» de la seguridad. NGINX ModSecurity WAF es una opción con coste adicional que se ofrece a los suscriptores a través de nuestro repositorio de módulos dinámicos.

NGINX ModSecurity WAF es una solución imprescindible para ayudar a proteger aplicaciones críticas. Ofrece una alternativa rentable a los dispositivos de hardware poco flexibles y costosos, como los de F5, Citrix e Imperva, al tiempo que supera sus prestaciones gracias a la flexibilidad del software. NGINX ModSecurity WAF puede implementarse en cualquier entorno: servidores locales y nubes públicas, privadas e híbridas.

NGINX ModSecurity WAF ayuda a proteger frente a ataques DDoS

Un WAF funciona con una base de datos de «reglas» que definen los comportamientos maliciosos que deben bloquearse o registrarse. El conjunto de reglas básicas de OWASP ModSecurity (CRS) es uno de los conjuntos de reglas más utilizados con ModSecurity. NGINX ModSecurity WAF utiliza el CRS de OWASP para identificar y bloquear una amplia variedad de ataques contra aplicaciones, con funciones como:

  • Protección contra ataques de capa 7 – Proteja sus aplicaciones frente a una amplia variedad de ataques, como infracciones del protocolo HTTP, inyección SQL, XSS, RFI y LFI, entre otros.
  • Mitigación de DDoS – Mantenga un tiempo de actividad continuo mitigando y reduciendo el impacto de sofisticados ataques DDoS a nivel de aplicación y redes de bots.
  • Listas de bloqueo en tiempo real – Bloquee automáticamente a usuarios maliciosos conocidos denegando el tráfico procedente de direcciones IP identificadas como maliciosas según su reputación.
  • Cumplimiento de PCI-DSS 6.6 – Empiece a cumplir los requisitos de PCI-DSS 6.6 para realizar transacciones en línea seguras.
  • Registro de auditoría – Responda con mayor rapidez a los ataques y a otro tráfico anómalo de aplicaciones utilizando la información de los registros detallados.

También hay disponibles conjuntos de reglas adicionales de distintos proveedores, como TrustWave, con diferentes niveles de precios. Además, puede utilizar el potente lenguaje de reglas de ModSecurity para definir sus propias reglas personalizadas que complementen los conjuntos de reglas que esté utilizando.

NGINX, Inc. proporciona directamente soporte para NGINX ModSecurity WAF. Nuestro equipo de soporte puede ayudarle a instalar y configurar el WAF y el conjunto de reglas básicas de OWASP, así como a solucionar cualquier problema relacionado con ellos.

NGINX ModSecurity WAF está disponible como módulo dinámico en el repositorio de NGINX Plus y se instala mediante las herramientas estándar de gestión de paquetes. Estos comandos son para sistemas operativos basados en Debian:

# apt-get update# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurity

Tenga en cuenta que solo los suscriptores que hayan adquirido el módulo NGINX ModSecurity WAF, así como los suscriptores y evaluadores que hayan solicitado acceso, pueden descargar el paquete nginx-plus-module-modsecurity.

Para cargar el módulo NGINX ModSecurity WAF, incluya la directiva load_module en el contexto «main» de nivel superior del archivo de configuración de NGINX Plus:

Cargando ejemplo de código…

Para habilitar NGINX ModSecurity WAF con NGINX Plus, incluya la directiva modsecurity junto con la directiva modsecurity_rules_file para especificar el conjunto de reglas:

Cargando ejemplo de código…

A continuación, vuelva a cargar la configuración de NGINX Plus:

# nginx -t && nginx -s reload

Compatibilidad nativa con JWT para OAuth 2.0 y OpenID Connect

Gracias a la compatibilidad nativa con el estándar de autenticación JSON Web Token (JWT), NGINX Plus R10 facilita la incorporación de soluciones de autenticación avanzadas a sus aplicaciones y API.

Los tokens JWT (pronunciado «yot»), definidos en la RFC 7519, son el formato de datos subyacente para la información de usuario en el estándar OpenID Connect, que constituye la capa de identidad estándar sobre el protocolo OAuth 2.0. Los responsables del despliegue de API y microservicios también están adoptando el estándar JWT por su sencillez y flexibilidad.

[Editor – Para casos de uso que aprovechan la compatibilidad nativa con JWT, consulte estos blogs:

]

NGINX Plus valida el JWT antes de permitir el acceso a los clientes

Como proxy inverso y balanceador de carga, NGINX Plus se sitúa delante de las aplicaciones, lo que le permite simplificar el desarrollo de aplicaciones al encargarse de validar el JWT incluido en cada solicitud HTTP. Esto ofrece dos ventajas. En primer lugar, NGINX Plus puede impedir que las solicitudes no autenticadas, mal formadas y maliciosas lleguen a la aplicación, evitando así el esfuerzo y el riesgo que conlleva gestionar dichas solicitudes.

La segunda ventaja es que NGINX Plus tiene acceso a todos los campos del JWT validado (tras verificar la firma) y puede aprovechar la potencia y flexibilidad inherentes a su sintaxis de configuración para ofrecer soluciones de autenticación avanzadas tanto para microservicios como para API:

  • Un caso de uso habitual para los microservicios consiste en hacer que NGINX Plus valide el JWT y proporcione la identidad del usuario autenticado a la aplicación backend mediante una cabecera HTTP. Esto elimina la necesidad de implementar una y otra vez la misma funcionalidad de autenticación en cada microservicio.
  • Para las API, NGINX Plus puede limitar la tasa de acceso por usuario de forma efectiva, en lugar de depender de la asignación aproximada de direcciones IP a usuarios finales.

El siguiente fragmento de ejemplo de configuración de NGINX Plus muestra cómo usar JWT para proteger un sitio web.

La directiva auth_jwt indica a NGINX Plus que utilice JWT para autenticar a los usuarios que realizan solicitudes a un dominio, en este caso myrealm. La directiva auth_jwt_key_file indica qué clave web JSON (JWK) se debe utilizar para validar la firma del token; funciona como la clave pública en el cifrado SSL/TLS. NGINX Plus debe poder acceder a la ubicación del archivo.

Cuando NGINX Plus valida y analiza el token, crea automáticamente variables de NGINX para las «declaraciones» del JWT, que representan entidades asociadas a él (por ejemplo, su emisor, el usuario para el que se emitió y el destinatario previsto). Todos los nombres de las variables comienzan por $jwt_claim_. A continuación, puede usar la directiva add_header para que NGINX Plus pase una declaración a los servidores backend en forma de una cabecera HTTP cuyo valor sea el de la variable $jwt_claim_. En nuestro ejemplo, NGINX Plus pasa la identidad del usuario a la aplicación backend en la variable $jwt_claim_sub, que corresponde al ID de usuario (declaración sub) del JWT.

Cargando ejemplo de código…

En NGINX Plus R8 lanzamos una versión preliminar de la compatibilidad con OAuth2. En la implementación de NGINX Plus R10 hemos tenido en cuenta los comentarios de nuestros clientes para ofrecer una solución lista para producción que abarca los casos de uso más importantes en el complejo mundo de la autenticación de usuarios y equipos.

Compatibilidad con certificados RSA y ECC de «doble pila»

Ahora existen numerosas razones para empezar a cifrar mediante SSL/TLS todo el tráfico de las aplicaciones. Google recompensa a los sitios cifrados mediante SSL/TLS con un mejor posicionamiento en los motores de búsqueda. Además, los estándares web modernos, como HTTP/2, exigen el cifrado SSL/TLS para todos los sitios web.

Con NGINX Plus R10, puede publicar servicios SSL/TLS utilizando certificados RSA y ECC. En nuestras pruebas, los certificados ECC fueron hasta 3 veces más rápidos que los certificados RSA con un nivel de seguridad equivalente, lo que se traduce en más conexiones SSL/TLS por servidor y negociaciones SSL/TLS más rápidas. NGINX Plus selecciona el certificado óptimo en función de las capacidades de cada cliente, lo que permite a los clientes modernos utilizar certificados ECC de mayor velocidad sin dejar de admitir clientes antiguos que solo son compatibles con RSA.

Para admitir certificados RSA y ECC, basta con incluir en la configuración de un servidor virtual un par de directivas «ssl_certificate» y «ssl_certificate_key» para cada tipo de certificado, como se muestra en el siguiente ejemplo.

Cargando ejemplo de código…

Proxy transparente

Añadimos continuamente funcionalidades a NGINX Plus, como el balanceo de carga de TCP y UDP, para admitir una gama más amplia de aplicaciones y modelos de implementación. Con NGINX Plus R10 hemos añadido una función de proxy transparente que permite a NGINX Plus enviar paquetes a servidores ascendentes utilizando cualquier dirección IP y puerto de origen. Esto permite configuraciones como la transparencia de IP y el retorno directo del servidor.

Transparencia de IP es una configuración en la que el equilibrador de carga (NGINX Plus) utiliza la dirección IP del cliente remoto como dirección IP de origen en los paquetes que envía a los servidores ascendentes. Esto significa que los servidores ascendentes ven los paquetes como procedentes de la dirección IP del cliente remoto, en lugar de una dirección IP local del equilibrador de carga. Esto es importante cuando las aplicaciones utilizan la dirección IP de origen para fines de registro, seguridad, limitación de velocidad o autenticación.

La transparencia de IP también es un componente básico de una técnica de equilibrio de carga de red denominada «retorno directo del servidor» (DSR). NGINX Plus puede implementar DSR para protocolos basados en UDP (pero no para TCP ni HTTP), lo que permite que los paquetes de respuesta omitan por completo el equilibrador de carga y se envíen directamente al cliente remoto.

En modo DSR, el servidor backend responde directamente al cliente

La transparencia de IP y DSR se configuran con el nuevo parámetro transparent de las directivas proxy_bind, fastcgi_bind, memcached_bind, scgi_bind y uwsgi_bind. El siguiente ejemplo muestra cómo configurar DSR para un backend DNS. La directiva proxy_responses especifica que NGINX Plus no necesita recibir ninguna respuesta del servidor (cero es el valor adecuado para DSR).

Cargando ejemplo de código…

Tenga en cuenta que las comprobaciones de estado pasivas no son eficaces cuando DSR está habilitado, ya que implican que NGINX Plus verifique que el servidor haya enviado una respuesta al cliente. Es obligatorio configurar comprobaciones de estado activas que tengan en cuenta la aplicación para una configuración de DSR. Para ver un ejemplo, consulte nuestras instrucciones detalladas para configurarlas en servidores DNS con equilibrio de carga.

Las configuraciones de transparencia de IP y DSR son complejas y tienen requisitos adicionales de enrutamiento y reescritura de paquetes que quedan fuera del ámbito del software NGINX Plus. Para obtener instrucciones completas, consulte Transparencia de IP y retorno directo del servidor con NGINX y NGINX Plus como proxy transparente en nuestro blog.

El módulo JavaScript de NGINX para aplicaciones basadas en HTTP, TCP y UDP

[Editor – El módulo JavaScript de NGINX se llamaba anteriormente nginScript. El módulo pasó a estar disponible de forma general en NGINX Plus R12 (y NGINX 1.11.10).

Para obtener información detallada sobre otros casos de uso del módulo JavaScript de NGINX, consulte Casos de uso del módulo JavaScript de NGINX.

El código de esta sección se ha actualizado para utilizar la js_import directiva, que sustituye a la directiva js_include en NGINX Plus R23 y versiones posteriores. Para obtener más información, consulte la documentación de referencia del módulo JavaScript de NGINX ; en la sección Configuración de ejemplo se muestra la sintaxis correcta para los archivos de configuración de NGINX y JavaScript.]

NGINX Plus R10 incluye una versión preliminar de nuestro nuevo lenguaje de configuración NGINX JavaScript. Aún no dispone de todas las funcionalidades, por lo que agradecemos cualquier comentario sobre el trabajo realizado hasta ahora. NGINX JavaScript permite utilizar código JavaScript para realizar acciones complejas y personalizadas sobre el tráfico HTTP, TCP y UDP. Ofrece una nueva y potente forma de controlar cómo se entregan y protegen sus aplicaciones. Con NGINX JavaScript puede:

  • Escriba funciones «sin servidor» directamente en NGINX Plus utilizando el potente lenguaje de programación JavaScript
  • Formatee, manipule y transforme datos de API
  • Proporcionar servicios TCP sencillos, como un servidor horario
  • Utilice JavaScript para establecer variables de NGINX, crear decisiones personalizadas de equilibrio de carga, claves de caché y mucho más

La versión preliminar de NGINX JavaScript está disponible en nuestro repositorio de módulos dinámicos. Puede instalarla utilizando las herramientas estándar de gestión de paquetes. Estos comandos son para sistemas operativos basados en Debian:

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njs

Para cargar los módulos JavaScript de NGINX para HTTP y TCP/UDP, incluya la directiva load_module en el contexto «main» de nivel superior del archivo de configuración de NGINX Plus:

Cargando ejemplo de código…

A continuación, vuelva a cargar la configuración de NGINX Plus para cargar los módulos JavaScript de NGINX:

# nginx -t && nginx -s reload

Los usuarios de NGINX Open Source pueden obtener NGINX JavaScript desde nuestro repositorio de código abierto.

El código JavaScript no se incluye directamente en la configuración de NGINX Plus. En su lugar, se carga mediante la directiva js_import. En este ejemplo, el código JavaScript de una sencilla función «sin servidor» se carga desde /etc/nginx/conf.d/functions.js. La directiva js_content indica a NGINX Plus que llame a la función JavaScript y devuelva los resultados al cliente.

Cargando ejemplo de código…

El código JavaScript de /etc/nginx/conf.d/functions.js rellena una cadena de caracteres con un conjunto de caracteres especificado:

Cargando ejemplo de código…

Funciones adicionales

NGINX Plus R10 incorpora una serie de mejoras adicionales para ayudarle a ofrecer aplicaciones sin contratiempos, entre ellas:

  • TCP/UDP load balancing, implemented in the Stream module, now has greater feature parity with HTTP load balancing. Newly supported modules include Split Clients for A/B testing, GeoIP to take actions based on the geographical location of clients, and Geo to define variables based on IP address. More information is available through additional NGINX variables, and you can perform routing decisions using a variable as the parameter to the proxy_pass directive.
  • Un problema habitual en las aplicaciones con mucho tráfico es el agotamiento de puertos efímeros, que impide crear nuevas conexiones con los servidores ascendentes porque el sistema operativo se ha quedado sin números de puerto disponibles. Para solucionar este problema, NGINX Plus utiliza ahora la opción de socket IP_BIND_ADDRESS_NO_PORT cuando está disponible. Esta opción permite reutilizar los puertos de origen para las conexiones salientes a servidores ascendentes, siempre que la «tupla de cuatro elementos» estándar (dirección IP de origen, dirección IP de destino, puerto de origen y puerto de destino) sea única. Está disponible en sistemas con la versión 4.2 o posterior del kernel de Linux y con glibc 2.22 o posterior.
  • NGINX Plus genera la nueva variable $request_id automáticamente para cada nueva solicitud HTTP, asignando así a la solicitud un «ID de transacción» único. Esto facilita el seguimiento de las aplicaciones y aporta funciones de APM a las herramientas de análisis de registros. El ID de transacción se transmite mediante proxy a las aplicaciones de backend y a los microservicios para que todos los componentes del sistema puedan registrar un identificador coherente para cada transacción.
  • Las directivas proxy_request_buffering, fastcgi_request_buffering, scgi_request_buffering y uwsgi_request_buffering ahora funcionan con HTTP/2 y pueden utilizarse para activar o desactivar el almacenamiento en búfer de las solicitudes.
  • La nueva directiva http2_body_preread_size permite a los clientes HTTP/2 empezar a enviar inmediatamente el cuerpo de la solicitud. Esta directiva controla el tamaño del búfer utilizado antes de que NGINX Plus empiece a leer el cuerpo de la solicitud del cliente.

El paquete Extras de NGINX Plus está obsoleto

Como ya anunciamos previamente con el lanzamiento de NGINX Plus R9, R10 es la última versión que incluirá el paquete NGINX Plus Extras.

Le recomendamos encarecidamente que modifique ahora sus procedimientos de instalación y configuración para utilizar el paquete nginx-plus y cargar dinámicamente los módulos del paquete nginx-plus-extras que realmente utilice. A partir de NGINX Plus R11, esta será la única forma posible de utilizar módulos que no estén integrados en el paquete nginx-plus.

Para cambiar al paquete nginx-plus y a los módulos dinámicos, siga estos pasos:

  1. Elimine el paquete nginx-plus-extras e instale nginx-plus y los módulos dinámicos que desee utilizar. Para los sistemas basados en Debian, el conjunto de comandos adecuado es:
# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name
  1. En el contexto principal (de nivel superior) de /etc/nginx/nginx.conf, añada una directiva load_module por cada módulo cargado dinámicamente:

    Cargando ejemplo de código…

  2. Compruebe que la nueva configuración sea sintácticamente válida y vuelva a cargarla:
# nginx -t && nginx -s reload

Actualiza o prueba NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a la versión 10 lo antes posible. Obtendrá diversas correcciones y mejoras, y esto nos permitirá ayudarle mejor si necesita abrir una incidencia de soporte. Encontrará las instrucciones de instalación y actualización en el portal para clientes de NGINX Plus.

NOTA: NGINX Plus R10 es la última versión que incluirá el paquete nginx-plus-extras. Consulte «El paquete Extras de NGINX Plus está obsoleto» más arriba.

Si aún no ha probado NGINX Plus, le animamos a utilizarlo para acelerar sitios web, equilibrar cargas y distribuir aplicaciones, o como servidor web con soporte completo y API mejoradas de supervisión y gestión. Puede empezar hoy mismo de forma gratuita con una evaluación de 30 días y comprobar por sí mismo cómo NGINX Plus puede ayudarle a distribuir sus aplicaciones y ampliar su capacidad.

Más información sobre NGINX Plus R10

Para obtener más información sobre las principales novedades de NGINX Plus R10, consulte estos recursos relacionados:

[NGINX ModSecurity WAF dejó de comercializarse oficialmente el 1 de abril de 2022 y pasará a estar fuera de soporte a partir del 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está pasando a estar fuera de soporte en nuestro blog.]


Compartir

Sobre el autor

Owen Garrett
Owen GarrettDirector sénior de Gestión de Producto

Más artículos de Owen Garrett

Artículos relacionados del blog

Únete a F5 NGINX en AppWorld 2024
NGINX | 04/01/2024

Únete a F5 NGINX en AppWorld 2024

Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
NGINX | 26/09/2023

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source

La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.

Exposición de APIs en Kubernetes
NGINX | 10/03/2022

Exposición de APIs en Kubernetes

La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
NGINX | 23/08/2021

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto

Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.

Presentamos NGINX Plus R22
NGINX | 09/06/2020

Presentamos NGINX Plus R22

NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.

Presentamos NGINX Plus R17
NGINX | 11/12/2018

Presentamos NGINX Plus R17

NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.