¿Qué es un WAF para Kubernetes?

Un WAF de Kubernetes es un cortafuegos de aplicaciones web que se utiliza para proteger las aplicaciones web y las API que se ejecutan en entornos Kubernetes del tráfico malicioso de la capa de la aplicación. Es una parte importante de la seguridad de Kubernetes.

Kubernetes facilita el despliegue, el escalado y la gestión de aplicaciones en contenedores, pero no protege automáticamente esas aplicaciones frente a amenazas como la inyección SQL, el cross-site scripting (XSS), la inyección de comandos, los bots maliciosos u otros ataques web. Un WAF añade una capa de seguridad para la aplicación que analiza las peticiones HTTP y HTTPS y puede detectar, bloquear o registrar actividad maliciosa antes de que llegue a las cargas de trabajo protegidas.

Según la arquitectura, un WAF puede operar en el borde de la red, junto a la infraestructura de ingreso de Kubernetes o dentro del propio entorno de Kubernetes. La estrategia adecuada depende de las aplicaciones, la arquitectura del tráfico, los requisitos de rendimiento y el modelo de seguridad de una organización.

¿Cómo funciona un WAF de Kubernetes?

Un WAF de Kubernetes es un WAF que protege las aplicaciones y las API desplegadas en Kubernetes. Un WAF tradicional se sitúa entre los usuarios y una aplicación web y analiza las peticiones entrantes en busca de actividad maliciosa. El mismo principio se aplica a Kubernetes, pero el entorno detrás del WAF puede estar formado por muchos contenedores, pods, servicios, API y microservicios que pueden cambiar y escalar dinámicamente.

Una aplicación de Kubernetes puede tener una ruta de petición similar a esta:

Usuario-red de distribución de contenidos/edge-WAF-Kubernetes ingress o gateway-Service-Pod

La posición exacta del WAF varía. Algunas organizaciones despliegan software de seguridad dentro de sus clústeres de Kubernetes. Otros inspeccionan el tráfico antes de que llegue al clúster mediante un WAF en la nube o en el edge. Los enfoques híbridos pueden usar más de un punto de vigilancia.

El objetivo es el mismo: identificar y detener el tráfico malicioso de la aplicación antes de que pueda aprovechar o interrumpir las cargas de trabajo de Kubernetes.

Flujo del proceso de WAF de Kubernetes
Un WAF de Kubernetes examina las peticiones de la capa de la aplicación y aplica lógica de seguridad antes de permitir que lleguen a las cargas de trabajo protegidas.

Una petición típica podría seguir estos pasos:

Un usuario o cliente envía una petición HTTP. La petición podría estar destinada a un sitio web, API u otro servicio accesible desde internet que se ejecute en Kubernetes.
El WAF inspecciona la petición. Según el despliegue, esto puede ocurrir en el edge o más cerca de la carga de trabajo de Kubernetes.
El WAF analiza la información de la capa de la aplicación. Puede inspeccionar elementos como URL, parámetros, encabezados, cookie, cuerpos de petición y carga útil de API.
Las reglas de seguridad y los mecanismos de detección evalúan el tráfico. El sistema determina si la petición parece legítima, sospechosa o maliciosa.
Se realiza una acción. El WAF puede permitir la petición, bloquearla, registrarla o aplicar otra respuesta configurada.
El tráfico permitido sigue llegando a Kubernetes. La petición puede pasar entonces por el equilibrador de carga, el controlador de entrada o la puerta de enlace adecuados hasta el servicio de Kubernetes y, en última instancia, el pod correspondiente.

Los WAF modernos pueden complementar las firmas de ataque con análisis del comportamiento, inteligencia sobre amenazas, limitación de frecuencia, detección de bots u otras señales de seguridad.

¿Por qué los entornos de Kubernetes necesitan un WAF?

Kubernetes proporciona importantes capacidades de infraestructura y orquestación, pero no sustituye la seguridad de la capa de la aplicación. Estas son las razones por las que un WAF es necesario en un entorno de Kubernetes:

Las aplicaciones de Kubernetes siguen siendo aplicaciones web
Trasladar una aplicación a contenedores no elimina las vulnerabilidades de su código. Una aplicación alojada en Kubernetes puede seguir estando expuesta a la inyección SQL, XSS, inyección de comandos, recorrido de rutas, ataques de autenticación, abuso de API y otras amenazas web.

Kubernetes fomenta las arquitecturas distribuidas
Kubernetes se utiliza habitualmente para microservicios y aplicaciones basadas en API. Esto puede crear muchos puntos de conexión de aplicaciones con diferentes funciones, requisitos de acceso a datos y perfiles de riesgo. En consecuencia, las API se convierten en una parte importante de la superficie de ataque.

Los entornos Kubernetes cambian rápidamente
Los pods se pueden crear, destruir y reprogramar automáticamente. Las aplicaciones también pueden actualizarse varias veces al día mediante canalizaciones de CI/CD. La arquitectura de seguridad debe funcionar con este modelo dinámico en lugar de depender de supuestos estáticos sobre la infraestructura.

Las cargas de trabajo expuestas a Internet son un objetivo constante
Las aplicaciones públicas y las API pueden recibir análisis de vulnerabilidades, intentos de explotación, ataques de credenciales, bots maliciosos y tráfico DDoS independientemente de si el backend se ejecuta en Kubernetes, máquinas virtuales o servidores físicos.

Cómo ayuda un WAF
La seguridad de Kubernetes incluye varias cuestiones diferenciadas. La configuración del clúster, la gestión de secretos, las políticas de red, la gestión de identidades y accesos, la seguridad de los contenedores, el análisis de imágenes, la seguridad en tiempo de ejecución y la protección de WAF resuelven problemas diferentes.

Un WAF ayuda específicamente a proteger la capa de la aplicación. No debe considerarse un sustituto de la protección de la propia plataforma Kubernetes.

¿De qué amenazas puede ayudar a proteger un WAF de Kubernetes?

Según el WAF, la protección de la capa de la aplicación puede abordar ataques como:

Inyección de código SQL
Scripting entre sitios
Inyección de comandos
Cruce de ruta
Peticiones HTTP maliciosas
Explotación de vulnerabilidades conocidas
ataques a la interfaz de programación de aplicaciones
Escaneo y sondeo de aplicaciones

Cuando se integran con tecnologías complementarias, las organizaciones también pueden abordar bots maliciosos, ataques de credenciales, scraping, ataques DDoS de capa de la aplicación y otras formas de abuso automatizado.

Los 10 principales ataques según OWASP son una referencia útil para comprender las principales categorías de riesgo de seguridad de las aplicaciones web. Sin embargo, no debe esperarse que un WAF elimine todos los riesgos de OWASP, porque algunas vulnerabilidades implican el diseño, la autorización, la configuración o la lógica de negocio de la aplicación y deben corregirse en la propia aplicación.

¿Cuáles son las mejores prácticas para desplegar un WAF con Kubernetes?

Un WAF es más eficaz cuando forma parte de una estrategia más amplia de Kubernetes y seguridad de las aplicaciones.

1. Protege las aplicaciones antes de que el tráfico llegue al clúster cuando sea posible
Un WAF desplegado en el edge puede identificar peticiones maliciosas antes de que consuman recursos de red, de entrada, de computación y de aplicación de Kubernetes. Reducir el tráfico no deseado en sentido ascendente puede mejorar tanto la seguridad como la eficiencia de la infraestructura.

2. Protege las interfaces de programación de aplicaciones, además de las páginas web
Los entornos de Kubernetes suelen alojar microservicios basados en API. Haz un inventario de las API accesibles desde el exterior y asegúrate de que las políticas de seguridad tengan en cuenta los endpoints de API en lugar de proteger solo el tráfico tradicional del navegador.

3. Restringe el acceso directo a los orígenes
Si se supone que una aplicación debe recibir tráfico de Internet a través de un nivel de seguridad edge, los atacantes no deberían poder eludir ese nivel simplemente conectándose directamente a un origen expuesto. Cuando la arquitectura lo permita, restringe el acceso al origen a rutas de tráfico autorizadas.

4. Integra la seguridad en CI/CD
Los despliegues de Kubernetes suelen estar automatizados, por lo que la seguridad debe encajar en el mismo modelo operativo. La infraestructura como código, las políticas con control de versiones, las pruebas de seguridad automatizadas y los despliegues repetibles pueden reducir la desviación de la configuración.

5. Empieza con visibilidad
Antes de bloquear tráfico de forma agresiva, comprende lo que detecta el WAF. Los modos de supervisión o registro pueden ayudar a los equipos a evaluar posibles falsos positivos y comprender el comportamiento normal de la aplicación antes de aplicar nuevas reglas.

6. Mantén las políticas de seguridad gestionables
Tener más reglas no produce necesariamente una mejor seguridad. Las políticas excesivamente complejas pueden resultar difíciles de mantener y pueden generar falsos positivos. Da prioridad a las protecciones de alto valor y revisa periódicamente las excepciones obsoletas.

7. Combina WAF y Protección frente a bots
Una petición HTTP de apariencia válida puede seguir siendo maliciosa cuando se automatiza miles de veces. La gestión de bots puede complementar un WAF al identificar automatizaciones maliciosas implicadas en actividades como el relleno de credenciales, el escaneo, el scraping y el abuso de aplicaciones.

8. Protección contra ataques DDoS
Un WAF no debería ser la única defensa contra los ataques de denegación de servicio. Utiliza una protección DDoS adecuada a nivel de red y de capa de aplicación para que el tráfico de ataque pueda mitigarse antes de agotar los recursos de Kubernetes o de la aplicación.

9. Supervisar los eventos de seguridad de forma centralizada
Integra la telemetría de seguridad de WAF con las plataformas de registro, gestión de eventos e información de seguridad y observabilidad cuando corresponda. Los equipos de Desarrollo, Operaciones y equipos de seguridad deben poder investigar los ataques sin correlacionar manualmente la información entre pods individuales.

10. Corregir vulnerabilidades en la aplicación
Un WAF añade una capa defensiva importante, pero no sustituye el desarrollo seguro. Sigue aplicando parches a las dependencias, probando las aplicaciones, corrigiendo configuraciones inseguras, implementando una autorización sólida y corrigiendo el código vulnerable.

¿Debe ejecutarse un WAF dentro o fuera de Kubernetes?

Ambos enfoques son posibles.

WAF dentro de Kubernetes
Un WAF o componente de seguridad puede operar dentro del entorno de Kubernetes o cerca de él, con la posibilidad de integrarse con la infraestructura de entrada o los servicios de la aplicación. Este enfoque puede ofrecer a las organizaciones flexibilidad de despliegue y controles de seguridad cerca de las cargas de trabajo individuales.

Sin embargo, la infraestructura de seguridad dentro del clúster puede consumir recursos del clúster y puede necesitar escalar junto con el tráfico de ataque.

WAF fuera de Kubernetes
Un WAF externo o edge inspecciona las peticiones antes de que lleguen a Kubernetes. Esto puede evitar que las peticiones maliciosas consuman recursos de entrada, red, computación y aplicación dentro del clúster. También desacopla el nivel de aplicación de la seguridad de la infraestructura que protege.

Despliegue híbrido
Algunas organizaciones combinan la seguridad edge con controles más cercanos a las cargas de trabajo. El modelo adecuado depende de la arquitectura, los requisitos de cumplimiento, las prácticas operativas, las aplicaciones y el modelo de amenazas de la organización.

¿Quién necesita un WAF de Kubernetes?

Las organizaciones deberían considerar la protección WAF cuando sus entornos de Kubernetes alojan aplicaciones web o API expuestas a Internet.

Proveedores de Saas
Las aplicaciones Saas suelen exponer sistemas de inicio de sesión, API, paneles y funcionalidad orientada al cliente a la que los atacantes pueden dirigirse.

Empresas de comercio electrónico
Los escaparates, sistemas de pago, funciones de búsqueda y API alojados en Kubernetes pueden enfrentarse a intentos de inyección, bot malicioso, ataques a cuentas y amenazas DDoS.

Servicios financieros
Las aplicaciones que gestionan información financiera o transacciones pueden beneficiarse de una seguridad de aplicación por capas junto con una autenticación, autorización, cifrado y desarrollo seguro sólidos.

Empresas de medios y publicación
Las plataformas de contenido con mucho tráfico pueden enfrentarse a escaneos de vulnerabilidades, scraping, abuso automatizado y picos de tráfico repentinos.

Empresas centradas en las API
Las organizaciones que operan un gran número de API públicas necesitan controles capaces de proteger los puntos de conexión de las aplicaciones sin depender exclusivamente de la seguridad de red tradicional.

Las empresas adoptan microservicios
A medida que las organizaciones dividen las aplicaciones monolíticas en servicios distribuidos, el número de API e interfaces de aplicación puede aumentar significativamente. Un WAF puede proporcionar una capa adicional de seguridad en el punto en el que esas aplicaciones quedan expuestas a tráfico no fiable.

¿Es la seguridad de Kubernetes lo mismo que la seguridad de la aplicación?

No. La seguridad de Kubernetes abarca el entorno subyacente de orquestación de contenedores, incluidas áreas como:

Acceso al clúster
RBAC
Secretos
Políticas de red
Imágenes de contenedores
Seguridad de pods
Seguridad del nodo
Seguridad en tiempo de ejecución
Seguridad de la cadena de suministro

La seguridad de las aplicaciones se centra en el software que se ejecuta en esa infraestructura, incluido su código, las API, la autenticación, la autorización y el procesamiento de la entrada del usuario. Un WAF aborda principalmente las amenazas de la capa de la aplicación. Por lo tanto, las organizaciones que ejecutan Kubernetes deben proteger tanto la plataforma como las aplicaciones que se ejecutan en ella.

¿Es suficiente un WAF de Kubernetes para proteger las API?

Respuesta corta: no. Un WAF es un nivel importante, pero la seguridad integral de API suele requerir controles adicionales.

Las organizaciones también deberían considerar:

Autenticación y autorización sólidas
Detección e inventario de interfaces de programación de aplicaciones
Validación de esquemas y de entrada
Limitación de frecuencia
Protección frente a bots
Mitigación de DDoS
Desarrollo seguro de interfaces de programación de aplicaciones
Registros y supervisión
Protección adecuada frente al abuso de la lógica empresarial

El objetivo es evitar tanto los exploits web tradicionales como los ataques que abusan de una funcionalidad de API que, por lo demás, es legítima.

¿Cómo complementa Fastly a los entornos de Kubernetes?

Fastly puede proteger aplicaciones alojadas en Kubernetes sin requerir que el punto principal de vigilancia de seguridad resida dentro de cada clúster de Kubernetes. Una arquitectura típica puede situar la plataforma de edge cloud de Fastly delante de las aplicaciones alojadas en Kubernetes:

Usuarios - Fastly edge - Infraestructura de Kubernetes - Cargas de trabajo de aplicaciones

El tráfico entrante de la aplicación llega primero a Fastly, donde se pueden aplicar controles de distribución y seguridad antes de que las peticiones permitidas continúen hacia el entorno de Kubernetes. Esta arquitectura puede ayudar a las organizaciones a mantener el tráfico malicioso o innecesario alejado de la infraestructura de Kubernetes, al tiempo que proporciona un nivel de seguridad coherente en todos los clústeres y entornos de aplicación.

¿Cómo funciona el WAF de última generación de Fastly con Kubernetes?

El WAF de última generación de Fastly puede proteger aplicaciones web y API alojadas en Kubernetes. Admite varios modelos de despliegue, incluidos los despliegues de WAF en la nube en el edge de Fastly, así como opciones de despliegue más cercanas a la infraestructura de la aplicación. Esto ofrece a las organizaciones flexibilidad para determinar dónde se lleva a cabo la inspección de seguridad de las aplicaciones.

El WAF de Fastly utiliza la tecnología SmartParse para analizar los parámetros de las peticiones e identificar comportamientos maliciosos de la aplicación. En lugar de depender exclusivamente de reglas tradicionales basadas en expresiones regulares, SmartParse está diseñado para identificar la intención detrás de las peticiones y reducir los falsos positivos.

Para las aplicaciones de Kubernetes, esto puede proporcionar protección contra clases de ataque como:

Inyección de código SQL
Scripting entre sitios
Inyección de comandos
Cruce de ruta
Otros ataques en la capa de la aplicación

El despliegue en el edge también puede reducir la cantidad de tráfico malicioso que llega a los clústeres de Kubernetes en primer lugar.

¿Puede Fastly proteger varios clústeres de Kubernetes?

Sí. Una arquitectura de seguridad basada en el edge puede ser útil cuando las aplicaciones abarcan varios clústeres, regiones o proveedores de infraestructura. En lugar de requerir una pila de seguridad independiente orientada a Internet para cada clúster, el tráfico puede pasar por Fastly antes de dirigirse al origen de aplicación adecuado.

Esto puede ser útil para las organizaciones que operan:

Varios clústeres de Kubernetes
Despliegues multirregión
Aplicaciones de nube híbrida
Arquitecturas multinube
Kubernetes junto con infraestructura no basada en Kubernetes

La configuración precisa dependerá de la arquitectura de red y de origen de la aplicación.

¿Qué otras capacidades de seguridad de Fastly complementan la protección de Kubernetes WAF?

La protección WAF es una parte de la cartera más amplia de seguridad de aplicaciones de Fastly.

Fastly Bot Management
Fastly Bot Management ayuda a identificar y control el tráfico automatizado. Esto puede complementar la protección de WAF frente a bots implicados en el análisis de vulnerabilidades, ataques de credenciales, scraping y abuso de aplicaciones.

Fastly DDoS Protection
Fastly DDoS Protection ayuda a defender las aplicaciones frente a ataques diseñados para saturar los recursos de red o de la aplicación. Mitigar los ataques en el edge puede evitar que grandes volúmenes de tráfico no deseado lleguen a la infraestructura de Kubernetes.

Limitación de frecuencia
Limitación de frecuencia puede ayudar a proteger endpoints sensibles y costosos desde el punto de vista computacional. En las aplicaciones de Kubernetes, esto puede ser especialmente útil para las API, los endpoints de autenticación, las funciones de búsqueda y otros servicios en los que las peticiones excesivas podrían consumir recursos del backend.

Red de distribución de contenidos y almacenamiento en caché
La red de distribución de contenidos de Fastly puede almacenar en caché el contenido apto en el edge, lo que reduce las peticiones que deben llegar a las cargas de trabajo de Kubernetes. Esto puede mejorar el rendimiento de la aplicación y reducir al mismo tiempo la demanda sobre los controladores de entrada, los servicios, los pods, las bases de datos y otra infraestructura de origen.

Visibilidad en tiempo real
Fastly proporciona registro en tiempo real y capacidades de observabilidad que pueden ayudar a los equipos de seguridad y Operaciones a comprender los patrones de tráfico e investigar actividades maliciosas. Esto puede complementar la observabilidad nativa de Kubernetes al proporcionar visibilidad del tráfico antes de que llegue al clúster.