Implementación de Network Policies con Cilium y eBPF en Clusters de Kubernetes

El Desafío del Tráfico Interno en Contenedores

Cuando ejecutamos decenas o cientos de aplicaciones dentro de un cluster de Kubernetes (un administrador automatizado de contenedores), una de las mayores preocupaciones es garantizar que una aplicación vulnerada no pueda acceder a los servicios vecinos. Tradicionalmente, el ecosistema confía en reglas de iptables, que funcionan como una larga cola de instrucciones que el sistema operativo debe leer secuencialmente para cada paquete de datos en la red. En la práctica, esto significa que cuantas más reglas de seguridad creas, más lento se vuelve el sistema, creando un cuello de botella invisible.

Para resolver este dilema de escala y rendimiento, la ingeniería de redes en la nube migró su atención hacia eBPF, una tecnología revolucionaria que permite ejecutar pequeños programas seguros directamente dentro del núcleo del sistema operativo sin modificar su código fuente. En la práctica, eBPF actúa como un conjunto de centinelas inteligentes que interceptan el tráfico de red al llegar, aplicando filtros de seguridad a velocidad de máquina y eliminando la necesidad de pasar por tablas de enrutamiento convencionales.

Por Qué Elegir Cilium como CNI

Cilium es un componente de red (conocido en el ecosistema como CNI, o Container Network Interface) construido desde cero para aprovechar todo el potencial de eBPF. Mientras que las redes tradicionales necesitan traducir direcciones IP virtuales a direcciones físicas a través de capas complejas de túneles, Cilium enruta paquetes directamente entre los nodos del cluster con una eficiencia impresionante. En la práctica, esto significa que el camino que recorren los datos es el más corto posible, reduciendo la latencia y aumentando la estabilidad.

Además de acelerar el tráfico, Cilium redefine cómo aplicamos aislamiento de seguridad a través de políticas de red avanzadas. Las reglas estándar de Kubernetes se limitan a filtrar tráfico basado en direcciones IP y puertos TCP, lo cual resulta insuficiente en entornos modernos donde los servicios cambian de dirección constantemente. Con el soporte nativo de Cilium, podemos crear reglas basadas en la identidad de las aplicaciones, permitiendo que únicamente el microservicio de pagos hable con la base de datos.

Configurando el Entorno e Instalando Cilium

Antes de aplicar cualquier regla restrictiva, debemos asegurarnos de que el cluster de Kubernetes ejecute una versión reciente del sistema operativo con soporte adecuado para eBPF en el kernel. La instalación se realiza típicamente mediante la herramienta de línea de comandos oficial de Cilium, cilium-cli, que verifica automáticamente la compatibilidad del entorno. En la práctica, necesita permisos administrativos en el cluster y acceso configurado a su archivo de contexto de Kubernetes para iniciar el proceso.

El procedimiento estándar para desplegar Cilium en un cluster recién creado implica ejecutar un comando directo en su terminal de administración. A continuación se muestra un ejemplo práctico de cómo realizar esta instalación utilizando los parámetros recomendados para habilitar el reemplazo completo del sistema de enrutamiento antiguo:

cilium install --set ipam.mode=kubernetes --set kubeProxyReplacement=strict

Después de unos minutos, puede verificar que todos los componentes se inicien correctamente ejecutando el comando de diagnóstico integrado. Este comando analiza la salud de los túneles, la carga de eBPF y la conectividad entre nodos, asegurando que el plano de datos esté listo para recibir políticas de seguridad restrictivas.

cilium status --wait

Implementando Políticas de Red Restrictivas en la Práctica

Con Cilium operando activamente, podemos comenzar a diseñar políticas de seguridad de denegación predeterminada (default-deny), donde todo el tráfico se bloquea por defecto y solo se permite lo estrictamente necesario. Este enfoque garantiza que, si un atacante vulnera un contenedor, permanezca aislado sin capacidad de explotar vulnerabilidades en otros servicios. En la práctica, configuramos el sistema para exigir un consentimiento explícito para cualquier comunicación entre pods.

A continuación presentamos un manifiesto YAML completo que define una política de red restrictiva. Este ejemplo bloquea todo el tráfico entrante al espacio de nombres de producción, permitiendo exclusivamente que los pods etiquetados como frontend se comuniquen con el servicio backend en el puerto 8080:

apiVersion: