En este post hablaremos de cómo podemos utilizar NGINX Service Mesh para limitar el número de peticiones hacia nuestros servicios.
No importa si la intención es maliciosa (adivinación de contraseñas por fuerza bruta y ataques DDoS) o benigna (clientes que acuden en masa a una venta): un gran volumen de solicitudes HTTP puede saturar sus servicios y hacer que las aplicaciones fallen.
Una solución fácil al problema es la limitación de velocidad, que restringe la cantidad de solicitudes que cada usuario puede realizar en un período de tiempo determinado. En un entorno de Kubernetes, una parte significativa del volumen total de tráfico que llega a un servicio puede estar fuera del alcance del Ingress controller, en forma de comunicación con otros servicios.
En esta situación, es altamente recomendable configurar políticas de limitación de velocidad mediante una malla de servicios.
A continuación describiremos los pasos a seguir para poder implementar este tipo de soluciones sobre cualquier clúster de Kubernetes:
#Paso 1:
El primer paso es la instalación de NGINX Service Mesh. Para realizar correctamente la instalación es importante tener configurado por defecto una StorageClass compatible, y dependiendo del tipo de plataforma donde tengamos alojado nuestro clúster de Kubernetes, necesitaremos añadir una serie de configuraciones que se indican en la documentación de NGINX.
Tras la instalación, deberíamos tener creado en el clúster un namespace llamado: “nginx-mesh” con los siguientes pods en funcionamiento:
#Paso 2:
Debemos asegurarnos que en los pods donde estén corriendo nuestras cargas de trabajo se inyecten correctamente los contenedores de NGINX Service Mesh. Estos contenedores son los que controlan y limitan la velocidad de las peticiones.
#Paso 3:
Una vez comprobados estos pasos ya podemos definir una política de limitación de velocidad como un recurso personalizado. Para ello crearemos en Kubernetes un recurso de tipo RateLimit:
- Donde podemos modificar los siguientes campos:destination: el servicio que recibe solicitudes
- sources: una lista de clientes de los que provienen las solicitudes, cada uno sujeto al límite de tasa. Aquí estamos definiendo solo una fuente, nuestro servicio front-end
- rate: el límite de tasa. Aquí son 10 solicitudes por minuto, o 1 cada 6 segundos
También hay otro par de campos que podemos agregar a la política para personalizar el límite de velocidad. Sabemos que algunas aplicaciones tienen «ráfagas» y envían múltiples solicitudes en rápida sucesión. Para adaptarse a esto, podemos agregar el campo “burst” que nos permite añadir un número de solicitudes adicionales al período que establezcamos en el campo “rate”.
El otro campo que podemos configurar es el “delay”, que nos permite añadir un tiempo adicional entre ráfaga y ráfaga. De forma predeterminada (con el valor “nodelay”) las solicitudes de ráfaga se ponen en cola y se envían inmediatamente de acuerdo con el límite de velocidad.
#Demo:
En la siguiente demostración vamos a simular una página de catálogos de calcetines que está alojada en un clúster de Kubernetes, donde hemos limitado el número de veces que un usuario puede enviar peticiones hacia nuestros servicios.
Se ha aplicado el RateLimit mostrado en el ejemplo anterior, el cual se especifica un límite en el Deployment de los usuarios. De manera que todas las peticiones realizadas en el Ingress que provengan de nuestro servicio de front-end y se dirijan al contenedor donde se almacenan los usuarios, no podrán superar las 10 solicitudes por minuto o 1 cada 6 segundos.
Desde nuestro portal web (front-end) intentaremos loguearnos repetidas veces a través de un usuario forzando contraseñas erróneas:
En los logs de los contenedores obtendremos los siguientes resultados:
Como observamos solo encontramos un: “err=not found” cada 6 segundos, que hace referencia al intento de accesos hacia nuestra página web con unas credenciales erróneas. Sin el RateLimit configurado anteriormente, este mensaje saldría infinitas veces pudiendo llegar a dejar sin funcionalidad la aplicación.
Si analizamos los logs del contenedor inyector de NGINX Service Mesh veremos todas las peticiones que se deniegan gracias a la configuración de este límite de velocidad:
Este es un ejemplo muy sencillo, con el que podemos mejorar la seguridad de nuestros servicios en pocos pasos. NGINX Service Mesh tiene la capacidad de tomar el control de Kubernetes brindando una solución de servicio a servicio totalmente segura, presentando un plano de datos unificado para la gestión de entrada y salida en una única configuración.
Contenido original: How to Use NGINX Service Mesh for Rate Limiting: https://www.nginx.com/blog/how-to-use-nginx-service-mesh-for-rate-limiting/?utm_medium=email&utm_source=nginxdb&utm_campaign=ww-nx_pgkub&utm_content=bg&mkt_tok=NjUzLVNNQy03ODMAAAF9lkWP3oh4T1nKx8I4AKCc58edOgYl1UE_Twk28NCxLOrAKAqpZwn0UdAZQstv6zL-6JedLiAyuiCbJWoQ_2KySD3HXjyvCnYIrwtLxUYVdugJMawF
