Balanceo de carga TCP/UDP mejorado y configuración de WAF con NGINX Ingress Controller

Amir RawdatIngeniero de soluciones

Aunque el recurso Ingress estándar de Kubernetes resulta muy útil para aprovisionar y configurar el balanceo de carga básico de Ingress, no incluye las funciones de personalización necesarias para que Kubernetes esté preparado para entornos de producción. Por ello, los usuarios que no utilizan NGINX tienen que recurrir a anotaciones, ConfigMaps y plantillas personalizadas, que son propensas a errores, difíciles de usar, poco seguras y carecen de un control de ámbito detallado. Los recursos Ingress de NGINX son nuestra solución a este problema.

Los recursos Ingress de NGINX están disponibles tanto para la versión de NGINX Ingress Controller basada en NGINX Open Source como para la basada en NGINX Plus. Proporcionan un estilo de configuración nativo, con seguridad de tipos y basado en sangrías, que simplifica la implementación del equilibrio de carga de Ingress. En este artículo, nos centramos en dos funcionalidades introducidas en NGINX Ingress Controller 1.11.0 que facilitan la configuración del WAF y de las políticas de equilibrio de carga:

• Recurso TransportServer – El recurso TransportServer define la configuración del balanceo de carga para TCP, UDP y TLS Passthrough. Hemos añadido comprobaciones de estado, informes de estado y fragmentos de configuración para mejorar el balanceo de carga TCP/UDP.
• Política de WAF de NGINX Ingress – Al implementar NGINX App Protect 3.0 con NGINX Ingress Controller, puede utilizar los recursos de NGINX Ingress para aplicar políticas de WAF a servicios específicos de Kubernetes.

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 de TS

Nota: Las incorporaciones al recurso TransportServer de la versión 1.11.0 constituyen una versión preliminar de la tecnología que se encuentra en desarrollo activo. En una versión futura, alcanzarán un nivel de calidad estable y apto para entornos de producción.

Fragmentos de TransportServer

En NGINX Ingress Controller, introdujimos fragmentos de configuración para los recursos VirtualServer y VirtualServerRoute (VS y VSR), que permiten ampliar de forma nativa las configuraciones de NGINX Ingress para clientes basados en HTTP. La versión 1.11.0 incorpora fragmentos para los recursos TS, lo que permite aprovechar fácilmente todas las funcionalidades de NGINX y NGINX Plus para ofrecer servicios basados en TCP/UDP. Por ejemplo, puede utilizar fragmentos para añadir las directivas deny y allow, que utilizan direcciones IP e intervalos para definir qué clientes pueden acceder a un servicio

apiVersion: k8s.nginx.org/v1alpha1kind: TransportServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  serverSnippets: |
    deny  192.168.1.1;
    allow 192.168.1.0/24;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80

Comprobaciones de estado

Para supervisar el estado de un clúster de Kubernetes, NGINX Ingress Controller no solo tiene en cuenta las sondas de Kubernetes locales de los pods de aplicaciones, sino que también controla el estado de la red entre los servicios ascendentes basados en TCP/UDP mediante comprobaciones de estado pasivas para evaluar el estado de las transacciones en curso y comprobaciones de estado activas (exclusivas de NGINX Plus) para sondear periódicamente los endpoints con solicitudes de conexión sintéticas.

Las comprobaciones de estado pueden resultar muy útiles para interrumpir el circuito y gestionar errores de la aplicación. Puede personalizar la comprobación de estado mediante los parámetros del campo healthCheck field del recurso TS, que permiten configurar el intervalo entre comprobaciones, el tiempo de espera de cada comprobación, los tiempos de espera entre comprobaciones y mucho más.

Además, puede configurar el servicio ascendente y el puerto de destino de los sondeos de estado de NGINX Ingress Controller. Esto resulta útil cuando el estado de la aplicación ascendente se expone en un listener diferente mediante otro proceso o subsistema que supervisa varios componentes descendentes de la aplicación.

Compatibilidad con varios recursos TransportServer mediante ingressClassName

Al actualizar y aplicar un recurso TS, conviene comprobar que la configuración sea válida y que se haya aplicado correctamente al despliegue del controlador de Ingress correspondiente. La versión 1.11.0 incorpora el campo ingressClassName field y la notificación del estado del recurso TS. El campo ingressClassName garantiza que el recurso TS sea procesado por un despliegue específico del controlador de Ingress en entornos con varios despliegues.

Para mostrar el estado de uno o todos los recursos TS, ejecute el comando kubectl get transportserver; la salida incluye el estado (Valid o Invalid), el motivo de la actualización más reciente y, en el caso de un único TS, un mensaje personalizado.

$ kubectl get transportserver  NAME      STATE   REASON           AGE
  dns-tcp   Valid   AddedOrUpdated   47m

$ kubectl describe transportserver dns-tcp
. . .
Status:
  Message:  Configuration for default/dns-tcp was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

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

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

Los recursos de NGINX Ingress no solo facilitan la configuración y la hacen más flexible, sino que también permiten delegar el control del tráfico en distintos equipos e imponer restricciones de privilegios más estrictas a los usuarios responsables de las subrutas de las aplicaciones, tal como se definen en los recursos VirtualServerRoute (VSR). Al proporcionar a los equipos adecuados acceso a los recursos de Kubernetes pertinentes, los recursos de NGINX Ingress ofrecen un control detallado de los recursos de red y reducen los posibles daños a las aplicaciones si las cuentas de los usuarios se ven comprometidas o son pirateadas.

La versión 1.11.0 incorpora un firewall de aplicaciones web (WAF) nativo mediante un objeto Policy para ampliar estas ventajas a la configuración de NGINX App Protect en sus implementaciones de Kubernetes. La política utiliza los objetos APLogConf y APPolicy incorporados en la versión 1.8.0 y puede asociarse tanto a recursos VirtualServer (VS) como VSR. Esto permite que los administradores de seguridad controlen todo el ámbito de la configuración de Ingress mediante recursos VS, a la vez que delegan responsabilidades de seguridad en otros equipos haciendo referencia a recursos VSR.

En el siguiente ejemplo, la política waf-prod se aplica a los usuarios dirigidos al upstream webapp-prod. Para delegar las responsabilidades de seguridad de la ruta /v2 entre espacios de nombres gestionados por distintos equipos, la directiva route resaltada hace referencia a un recurso VSR.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: waf-prod 
  tls:
    secret: app-secret
  upstreams:
  - name: webapp-prod
    service: webapp-svc
    port: 80
  routes:
  - path: /v2
    route: test/test
  - path: /v1
    action:
      pass: webapp-prod

Los equipos que gestionan el espacio de nombres test pueden configurar sus propios parámetros y políticas de WAF mediante recursos VSR en dicho espacio de nombres.

apiVersion: k8s.nginx.org/v1kind: VirtualServerRoute
metadata:
  name: test 
  namespace: test
spec:
  host: webapp.example.com
  upstreams:
  - name: webapp 
    service: webapp-test-svc
    port: 80
  subroutes:
  - path: /v2
    policies:
    - name: waf-test
    action:
      pass: webapp

Este ejemplo separa los inquilinos por espacio de nombres y aplica una política de WAF diferente al servicio webapp-test-svc en el espacio de nombres test. Muestra cómo delegar recursos a distintos equipos y encapsularlos mediante objetos simplifica las pruebas de nuevas funcionalidades sin afectar a las aplicaciones en producción.

¿Qué otras novedades incluye la versión 1.11.0?

Con NGINX Ingress Controller 1.11.0, reafirmamos nuestro compromiso de ofrecer un controlador Ingress apto para entornos de producción que sea flexible, potente y fácil de usar. Además de las mejoras en WAF y TS, la versión 1.11.0 incluye las siguientes novedades:

• Validación de más anotaciones – Evite más errores de configuración
• Información sobre el estado de las políticas – Muestra el estado de los objetos Policy antes de que se apliquen a la configuración de Ingress
• Compatibilidad con Istio – Aproveche las funcionalidades avanzadas de NGINX Ingress Controller en un entorno de Istio
• Direcciones IP de clúster para endpoints ascendentes – Rellene los endpoints ascendentes de la configuración de NGINX Ingress Controller con direcciones IP de servicio o de clúster

Validación de más anotaciones

A partir de las mejoras en la validación de anotaciones introducidas en la versión 1.10.0, ahora validamos las siguientes anotaciones adicionales:

Validación de anotacionesnginx.org/client-max-body-size Debe ser un desplazamiento válidonginx.org/fail-timeout Debe ser un tiempo válidonginx.org/max-conns Debe ser un número entero no negativo válidonginx.org/max-fails Debe ser un número entero no negativo válidonginx.org/proxy-buffer-size Debe ser un tamaño válidonginx.org/proxy-buffers Debe ser una especificación de búfer de proxy válidanginx.org/proxy-connect-timeout Debe ser un tiempo válidonginx.org/proxy-max-temp-file-size Debe ser un tamaño válidonginx.org/proxy-read-timeout Debe ser un tiempo válidonginx.org/proxy-send-timeout Debe ser un tiempo válidonginx.org/upstream-zone-size Debe ser un tamaño válido

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

Información de estado sobre las políticas

El comando «kubectl get policy» ahora muestra el estado de la política (Valid o Invalid) y, en el caso de un único TS, un mensaje personalizado y el motivo de la actualización más reciente.

$ kubectl get policy  NAME              STATE   AGE
  webapp-policy     Valid   30s

$ kubectl describe policy webapp-policy
. . .
Status:
  Message:  Configuration for default/webapp-policy was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

Compatibilidad con Istio

NGINX Ingress Controller ahora puede utilizarse como controlador de Ingress para aplicaciones que se ejecutan dentro de una malla de servicios de Istio. Esto permite a los usuarios seguir utilizando las funciones avanzadas que ofrece NGINX Ingress Controller en entornos basados en Istio sin tener que recurrir a soluciones alternativas. Esta integración implica dos requisitos:

• La inyección de un sidecar de Istio en el despliegue de NGINX Ingress Controller
• Solo se envía una cabecera HTTP Host al backend

Para cumplir el primer requisito, incluya los siguientes elementos en el campo annotations del archivo de despliegue de NGINX Ingress.

annotations:   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: 'true'

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

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: foo 
spec:
  host: foo.example.com
  upstreams:
  - name: foo
    port: 8080
    service: backend-svc
    use-cluster-ip: true
  routes:
  - path: "/"
    action:
      proxy:
        upstream: foo
        requestHeaders: set: - name: Host value: bar.example.com

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

Direcciones IP de clúster para endpoints ascendentes

Ahora, los endpoints de upstream de la configuración de NGINX Ingress Controller pueden rellenarse con direcciones IP de servicio o de clúster, en lugar de con las direcciones IP individuales de los endpoints de los pods. Para permitir que NGINX Ingress Controller enrute el tráfico a servicios Cluster-IP, incluya el campo use-cluster-ip: true en la sección upstreams de la configuración de VS o VSR:

upstreams:  - name: tea
    service: tea-svc
    port: 80
    use-cluster-ip: true
  - name: coffee
    service: coffee-svc
    port: 80
    use-cluster-ip: true

Recursos

Para consultar 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, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre 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 precompilado de DockerHub.

Para conocer las diferencias entre los controladores Ingress, consulta Espera, ¿qué controlador NGINX Ingress para Kubernetes estoy usando? en nuestro blog.

Sobre el autor

Amir RawdatIngeniero de soluciones

Más artículos de Amir Rawdat