Equilibrio de carga TCP/UDP mejorado y configuración WAF con el controlador de ingreso NGINX

Si bien el recurso estándar de Kubernetes Ingress es excelente para aprovisionar y configurar el equilibrio de carga básico de Ingress, no incluye el tipo de funciones de personalización necesarias para que Kubernetes sea de nivel de producción . En cambio, los usuarios que no utilizan NGINX deben usar anotaciones, ConfigMaps y plantillas personalizadas que son propensas a errores, difíciles de usar, no son seguras y carecen de un alcance detallado. Los recursos de NGINX Ingress son nuestra respuesta a este problema.

Los recursos de NGINX Ingress están disponibles tanto para la versión de código abierto NGINX como para la versión basada en NGINX Plus de NGINX Ingress Controller. Proporcionan un estilo de configuración nativo, seguro en cuanto a tipos y sangrado que simplifica la implementación del equilibrio de carga de Ingress. En este blog, nos centramos en dos características introducidas en NGINX Ingress Controller 1.11.0 que facilitan la configuración de WAF y las políticas de equilibrio de carga:

• Recurso TransportServer : el recurso TransportServer define la configuración para el equilibrio de carga de paso a través de TCP, UDP y TLS. Hemos agregado controles de estado, informes de estado y fragmentos de configuración para mejorar el equilibrio de carga TCP/UDP.
• Política WAF de NGINX Ingress : cuando implementa NGINX App Protect 3.0 con NGINX Ingress Controller, puede aprovechar los recursos de NGINX Ingress para aplicar políticas WAF a servicios de Kubernetes específicos.

Mejoras en el recurso TransportServer

NGINX Ingress Controller 1.11.0 amplía el recurso TransportServer (TS) en las siguientes áreas:

• Fragmentos
• Comprobaciones de estado
• Compatibilidad con múltiples recursos TS

Nota:  Las incorporaciones al recurso TransportServer en la versión 1.11.0 son una vista previa de tecnología en desarrollo activo. Se graduarán a un estándar de calidad estable y listo para producción en una versión futura.

Fragmentos de TransportServer

En NGINX Ingress Controller , presentamos fragmentos de configuración para los recursos VirtualServer y VirtualServerRoute (VS y VSR) que le permiten extender de forma nativa las configuraciones de NGINX Ingress para clientes basados en HTTP. La versión 1.11.0 introduce fragmentos para recursos TS, de modo que pueda aprovechar fácilmente la gama completa de capacidades de NGINX y NGINX Plus para brindar servicios basados en TCP/UDP. Por ejemplo, puede usar fragmentos para agregar directivas de denegación y permiso que usan direcciones IP y rangos para definir qué clientes pueden acceder a un servicio.

Versión de API: k8s.nginx.org/v1alpha1kind: Servidor de Transporte
Metadatos:
Nombre: Cafe
Especificación:
Host: Cafe.ejemplo.com
ServidorSnippets: |
Denegar 192.168.1.1;
Permitir 192.168.1.0/24;
Subidas:
- Nombre: Tea
Servicio: Tea-Svc
Puerto: 80

Comprobaciones de estado

Para monitorear la salud de un clúster de Kubernetes, NGINX Ingress Controller no solo considera las sondas de Kubernetes que son locales en los pods de aplicação , sino que también controla el estado de la red entre los servicios ascendentes basados ​​en TCP/UDP, con controles de salud pasivos para evaluar la salud de las transacciones en vuelo y controles de salud activos (exclusivos de NGINX Plus) para sondear los puntos finales periódicamente con solicitudes de conexión sintéticas.

Los controles de salud pueden ser muy útiles para interrumpir circuitos y gestionar errores de aplicação . Puede personalizar la comprobación de estado mediante parámetros en el campo HealthCheck del recurso TS que establecen el intervalo entre sondas, el tiempo de espera de la sonda, los tiempos de retraso entre sondas y más.

Además, puede configurar el servicio ascendente y el puerto de destino de las sondas de estado desde el controlador de ingreso NGINX. Esto es útil en situaciones donde la salud de la aplicação ascendente está expuesta en un oyente diferente por otro proceso o subsistema que monitorea múltiples componentes descendentes de la aplicação.

Compatibilidad con múltiples recursos de TransportServer con ingressClassName

Al actualizar y aplicar un recurso TS, es útil verificar que la configuración sea válida y se haya aplicado correctamente a la implementación del controlador de ingreso correspondiente. La versión 1.11.0 introduce el campo ingressClassName y los informes de estado para el recurso TS. El campo ingressClassName garantiza que el recurso TS sea procesado por una implementación particular del controlador de ingreso en entornos donde tiene múltiples implementaciones.

Para mostrar el estado de uno o todos los recursos TS, ejecute el comando kubectl get transportserver ; la salida incluye el estado ( Válido o Inválido ), el motivo de la actualización más reciente y (para un solo TS) un mensaje personalizado.

$ kubectl get transportserver NOMBRE ESTADO RAZÓN EDAD dns-tcp Válido Agregado o actualizado 47 m $ kubectl describe transportserver dns-tcp . . .
Estado:
  Mensaje:  Se agregó o actualizó la configuración para default/dns-tcp Motivo:   Estado añadido o actualizado:    Válido

Si varios recursos TS compiten por el mismo host/escucha, NGINX Ingress Controller selecciona el recurso TS con las marcas de tiempo más antiguas, lo que garantiza un resultado determinista en esa situación.

Definición de una política WAF con compatibilidad nativa con NGINX App Protect

Los recursos de Ingress de NGINX no solo hacen que la configuración sea más sencilla y flexible, sino que también le permiten delegar el control de tráfico a diferentes equipos e imponer restricciones de privilegios más estrictas a los usuarios que poseen subrutas de aplicação , como se define en los recursos de VirtualServerRoute (VSR). Al brindar a los equipos adecuados acceso a los recursos adecuados de Kubernetes, los recursos de NGINX Ingress le brindan un control detallado sobre los recursos de red y reducen el daño potencial a las aplicações si los usuarios se ven comprometidos o pirateados.

La versión 1.11.0 presenta un objeto de política de firewall de aplicação web (WAF) nativo para extender estos beneficios a la configuración de NGINX App Protect en sus implementaciones de Kubernetes. La política aprovecha los objetos APLogConf y APPolicy introducidos en la versión 1.8.0 y se puede adjuntar a recursos tanto de VirtualServer (VS) como de VSR. Esto significa que los administradores de seguridad pueden tener propiedad sobre el alcance completo de la configuración de Ingress con recursos de VS, mientras delegan responsabilidades de seguridad a otros equipos haciendo referencia a los recursos de VSR.

En el siguiente ejemplo, la política waf-prod se aplica a los usuarios que se enrutan al servidor webapp-prod ascendente. Para delegar responsabilidades de seguridad de la ruta /v2 en espacios de nombres propiedad de diferentes equipos, la directiva de ruta resaltada hace referencia a un recurso VSR.

Versión de API: k8s.nginx.org/v1kind: Metadatos de VirtualServer: nombre: webapp especificación: host: webapp.example.com políticas: - nombre: waf-prod tls: secreto: app-secret upstreams: - nombre: webapp-prod servicio: webapp-svc puerto: 80 rutas: - ruta: /v2 ruta: test/test - ruta: /v1 acción: pass: webapp-prod

Los equipos que administran el espacio de nombres de prueba pueden establecer sus propios parámetros y políticas WAF utilizando recursos VSR en ese espacio de nombres.

Versión de API: k8s.nginx.org/v1kind: RutaServidorVirtual
Metadatos:
Nombre: prueba
Espacio de nombres: prueba
Especificación:
Host: webapp.example.com
Subidas:
Nombre: webapp
Servicio: webapp-test-svc
Puerto: 80
Subrutas:
- Ruta: /v2
Políticas:
- Nombre: waf-test
Acción:
Contraseña: webapp

Este ejemplo separa a los inquilinos por espacio de nombres y aplica una política WAF diferente para el servicio webapp-test-svc en el espacio de nombres de prueba . Ilustra cómo delegar recursos a diferentes equipos y encapsularlos con objetos simplifica la prueba de nuevas funcionalidades sin interrumpir las aplicações en producción.

¿Qué más hay de nuevo en la versión 1.11.0?

Con NGINX Ingress Controller 1.11.0 continuamos nuestro compromiso de proporcionar un controlador Ingress de nivel de producción que sea flexible, potente y fácil de usar. Además de las mejoras de WAF y TS, la versión 1.11.0 incluye las siguientes mejoras:

• Validación de más anotaciones : evitar más errores de configuración
• Información del estado de la política : muestra el estado de los objetos de política antes de que se apliquen a la configuración de Ingress
• Compatibilidad con Istio : aproveche las capacidades avanzadas del controlador de ingreso NGINX en un entorno Istio
• Direcciones IP del clúster para puntos finales ascendentes : rellene los puntos finales ascendentes en la configuración del controlador de ingreso NGINX con direcciones IP del servicio/clúster

Validación de más anotaciones

Basándonos en las mejoras en la validación de anotaciones introducidas en la versión 1.10.0, ahora estamos validando las siguientes anotaciones adicionales:

Si el valor de la anotación no es válido cuando se aplica el recurso de Ingress, el controlador de Ingress rechaza el recurso y elimina la configuración correspondiente de NGINX.

Información sobre el estado de las políticas

El comando kubectl get policy ahora informa el estado de la política ( Válida o Inválida ) y (para un solo TS) un mensaje personalizado y el motivo de la actualización más reciente.

$ kubectl get policy NOMBRE ESTADO EDAD webapp-policy Válido 30 s $ kubectl describe policy webapp-policy . . .
Estado:
  Mensaje:  Se agregó o actualizó la configuración para la política de aplicación web/predeterminada Motivo:   Estado añadido o actualizado:    Válido

Compatibilidad con Istio

El controlador de ingreso NGINX ahora se puede utilizar como controlador de ingreso para aplicaciones que se ejecutan dentro de una malla de servicio Istio. Esto permite a los usuarios continuar utilizando las capacidades avanzadas que NGINX Ingress Controller proporciona en entornos basados en Istio sin recurrir a soluciones alternativas. Esta integración implica dos requisitos:

• La inyección de un sidecar de Istio en la implementación del controlador de ingreso de NGINX
• Solo se envía un encabezado de host HTTP al backend

Para satisfacer el primer requisito, incluya los siguientes elementos en el campo de anotaciones de su archivo de implementación de NGINX Ingress.

Anotaciones: Traffic.sidecar.istio.io/includeInboundPorts: "" 
Traffic.sidecar.istio.io/excludeInboundPorts: "80.443"         
  Traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'verdadero'

El segundo requisito se logra mediante un cambio en el comportamiento del campo requestHeaders . En versiones anteriores, con la siguiente configuración, se enviaban dos encabezados de Host al backend: $host y el valor especificado, bar.example.com .

Versión de API: k8s.nginx.org/v1kind: Metadatos del servidor virtual: nombre: foo especificación: host: foo.example.com upstreams: - nombre: foo puerto: Servicio 8080: backend-svc use-cluster-ip: true rutas: - ruta: "/" acción: proxy: upstream: foo requestHeaders: set: - nombre: Valor del host: bar.example.com

En la versión 1.11.0 y posteriores, solo se envía el valor especificado. Para enviar $host , omita el campo requestHeaders por completo.

Direcciones IP de clúster para puntos finales ascendentes

Los puntos finales ascendentes en la configuración del controlador de ingreso NGINX ahora se pueden completar con direcciones IP de servicio/clúster, en lugar de las direcciones IP individuales de los puntos finales del pod. Para permitir que el controlador de ingreso de NGINX enrute el tráfico a los servicios de Cluster-IP, incluya el campo use-cluster-ip: true en la sección upstreams de su configuración de VS o VSR:

upstreams: - nombre: servicio de té: puerto tea-svc: 80 use-cluster-ip: true - nombre: servicio de café: puerto coffee-svc: 80 use-cluster-ip: verdadero

Recursos

Para ver el registro de cambios completo de la versión 1.11.0, consulte las Notas de la versión .

Para probar NGINX Ingress Controller para Kubernetes con NGINX Plus y NGINX App Protect, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .

Para probar NGINX Ingress Controller con NGINX Open Source, puede obtener el código fuente de la versión o descargar un contenedor prediseñado desde DockerHub .

Para obtener una discusión sobre las diferencias entre los controladores de ingreso, consulte Espere, ¿qué controlador de ingreso NGINX para Kubernetes estoy usando? en nuestro blog.