💻 computer science

Runtime Detection of Attacks and Misconfigurations in Cloud-Native Kubernetes Environments Using eBPF Network Telemetry

Este artículo demuestra que la telemetría de red Hubble/eBPF, al combinarse con etiquetas de verdad fundamental cuidadosamente construidas, puede detectar eficazmente ataques en tiempo de ejecución y configuraciones erróneas en entornos Kubernetes, revelando que los atributos de identidad del lado del destino son los indicadores más fuertes de amenazas a pesar de un compromiso entre la alta precisión de los detectores basados en reglas y el mayor recobro de los clasificadores Random Forest.

Autores originales: Andrew Oppong-Asante, Bernard Kyiewu, Clinton Amponsah, Linda Bessa-Simons, Caleb Boakye Yiadom

Publicado 2026-06-25

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Andrew Oppong-Asante, Bernard Kyiewu, Clinton Amponsah, Linda Bessa-Simons, Caleb Boakye Yiadom

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina un clúster de Kubernetes como un edificio de oficinas enorme y bullicioso donde viven y trabajan miles de trabajadores diminutos y temporales (llamados contenedores). Estos trabajadores están organizados en diferentes departamentos (llamados namespaces). En un edificio seguro, existen reglas estrictas: el equipo de contabilidad no puede deambular por la sala de servidores, y los pasantes no pueden acceder a la oficina del CEO.

Sin embargo, a veces los administradores del edificio cometen errores. Podrían dejar las puertas sin llave, dar la llave maestra a todo el mundo o permitir que los trabajadores usen armaduras de "traje súper" que les permiten romper paredes. Estos errores son malas configuraciones.

Este artículo trata sobre la construcción de un sistema de cámaras de seguridad superpotente para atrapar a los malos actores en el momento en que intentan explotar estos errores, sin ralentizar el edificio.

El Problema: Puertas Invisibles y Llaves Maestras

Los investigadores comenzaron cometiendo intencionalmente tres errores específicos en su edificio de oficinas de prueba:

Sin Guardias de Seguridad (Falta de Políticas de Red): Eliminaron las reglas que impiden que los trabajadores caminen entre departamentos. Ahora, cualquiera podía caminar por cualquier parte.
Demasiadas Llaves Maestras (RBAC Excesivo): Le dieron a un trabajador de bajo nivel una llave que abría todas las puertas del edificio, incluyendo la bóveda secreta.
Trajes Súper (Contenedores Privilegiados): Dejaron que un trabajador usara un traje que le permitía ver y tocar todo, incluso los cimientos y el cableado eléctrico del edificio.

Una vez que estos errores estuvieron en su lugar, enviaron a un "red team" (un grupo de hackers éticos) para intentar entrar, robar datos o saltar de un departamento a otro.

La Solución: La Supercámara "eBPF"

Para atrapar a estos intrusos, los investigadores no utilizaron una cámara de seguridad estándar. Utilizaron algo llamado eBPF (extended Berkeley Packet Filter), que describen como un sensor superavanzado y de alta velocidad embebido directamente en la tubería y el cableado del edificio.

Este sensor, junto con una herramienta llamada Hubble, no solo toma fotos; registra cada una de las gotas de agua (datos) que fluyen por las tuberías. Sabe exactamente:

Quién envió la gota (Pod de Origen).
Quién recibió la gota (Pod de Destino).
Por qué tubería pasó (Namespace).
Qué tipo de gota era (Puerto/Protocolo).

Los investigadores recolectaron más de 3.8 millones de estos "registros de flujo" (gotas de datos).

El Gran Desafío: Clasificar el Ruido

Aquí está la parte difícil: la cámara registró todo. La mayor parte del tiempo, el edificio solo estaba realizando un trabajo normal (tráfico benigno). Los ataques reales eran como encontrar unas pocas agujas en un pajar de 3 millones de trozos de paja.

Además, la cámara tenía una peculiaridad extraña. A veces, veía la gota de agua cuando salía del grifo (TO_STACK), otras veces cuando golpeaba la tubería (TO_ENDPOINT), y otras veces cuando viajaba a través de la línea principal (TO_OVERLAY).

El Problema: Cuando la cámara veía la gota en la etapa del "grifo", a menudo no podía ver hacia dónde iba. Era como ver una carta salir de un buzón pero no saber la dirección en el sobre.
La Solución: Los investigadores tuvieron que pasar por un riguroso proceso de limpieza de cuatro pasos para desechar los registros borrosos e incompletos y conservar solo aquellos donde pudieran ver claramente el destino. Esto convirtió sus 3.8 millones de registros desordenados en un conjunto de datos limpio de 3.18 millones de registros, con solo 456 registros de "ataque" confirmados.

Los Detectives: Reglas vs. IA

Los investigadores probaron dos formas diferentes de detectar a los malos en estos datos limpios:

El Detective Basado en Reglas: Este detective sigue una lista de verificación estricta. "¡Si un trabajador del departamento 'Atacante' intenta hablar con el departamento 'Base de Datos' en el puerto 5432, suene la alarma!"
- Resultado: Este detective fue muy preciso. Cuando hacía sonar la alarma, generalmente tenía razón. Sin embargo, se le escaparon algunos ataques sigilosos que no encajaban en su lista de verificación exacta.
El Detective de Bosque Aleatorio (IA): Este detective es como un estudiante que ha estudiado miles de ejemplos de comportamientos normales y malos. Mira el panorama completo y adivina: "Esto parece un 80% un ataque".
- Resultado: Este detective atrapó a más malhechores (mayor recall), pero también hizo sonar la alarma algunas veces cuando se trataba de un trabajador normal haciendo algo ligeramente inusual.

El Gran Descubrimiento: Con Quién Hablas Importa Más

El hallazgo más sorprendente fue sobre con quién intentaban hablar los malos.

Los investigadores descubrieron que las pistas más importantes no se trataban de quién enviaba el mensaje, sino de quién lo recibía.

La Metáfora: No importa si una persona de apariencia normal (Origen) envía una carta. Lo que importa es que intenta entregarla en la Bóveda del Banco (Destino).
La Proporción: Las pistas del "Destino" fueron 2.8 veces más importantes que las pistas del "Origen". Si un trabajador intenta hablar con la base de datos o el servidor de la API, eso es una gran señal de alerta, independientemente de quién sea.

La Conclusión

El artículo concluye que usar estos sensores de alta velocidad (eBPF/Hubble) funciona de maravilla para atrapar ataques en tiempo real, pero solo si eres muy cuidadoso con la forma en que etiquetas los datos.

Si no filtras los registros borrosos (donde el destino es desconocido), no puedes distinguir entre un trabajador normal y un hacker. Pero si realizas la limpieza correctamente, puedes construir un sistema que detecta intrusos en el momento en que intentan saltar entre departamentos o acceder a la bóveda.

En resumen: Puedes atrapar a los malos en un edificio de oficinas en la nube, pero necesitas una supercámara que sepa exactamente hacia dónde va el agua, y necesitas enseñar a tus guardias de seguridad que a dónde va el mensaje es más importante que quién lo envió.

Resumen Técnico: Detección en Tiempo de Ejecución de Ataques y Configuraciones Erróneas en Entornos Nativos de la Nube Kubernetes mediante Telemetría de Red eBPF

Declaración del Problema

Kubernetes se ha convertido en el estándar de facto para las cargas de trabajo nativas de la nube, pero su flexibilidad introduce una superficie de configuración compleja propensa a riesgos de seguridad. Las configuraciones erróneas, como la ausencia de NetworkPolicies, los permisos excesivos de Control de Acceso Basado en Roles (RBAC) y la ejecución de contenedores privilegiados, crean rutas explotables para el movimiento lateral, el acceso no autorizado a servicios y la escalada de privilegios. Aunque existe el análisis estático y el endurecimiento previo al despliegue, estos suelen fallar al no capturar patrones de comunicación inseguros que se manifiestan solo en tiempo de ejecución. Además, los enfoques de detección en tiempo de ejecución existentes dependen frecuentemente de la telemetría de llamadas al sistema o de conjuntos de datos de red genéricos que carecen de contexto específico de Kubernetes. Persiste una brecha metodológica significativa en el uso de la telemetría de red Hubble/eBPF para la seguridad: la arquitectura de múltiples puntos de observación de Cilium (TO_STACK, TO_ENDPOINT, TO_OVERLAY) plantea desafíos para la construcción de una verdad de terreno (ground truth) fiable a nivel de flujo, ya que la integridad de los metadatos varía entre estos puntos.

Metodología

El estudio emplea un enfoque experimental reproducible para abordar estos desafíos mediante los siguientes pasos:

Entorno Experimental: Se estableció un clúster de cuatro nodos kind (Kubernetes-in-Docker) ejecutando Kubernetes v1.35.0. Se desplegó Cilium v1.16.6 como Interfaz de Red de Contenedores (CNI) con Hubble habilitado para la observabilidad por flujo.
Diseño de Carga de Trabajo y Namespace: El entorno alojó una aplicación de microservicios de múltiples niveles distribuida en cinco namespaces: frontend, backend, database, attacker y monitoring.
Inyección de Configuraciones Erróneas: Se introdujeron tres clases específicas de configuraciones erróneas para permitir ataques:
- M1 (Ausencia de Network Policy): No se desplegaron NetworkPolicies, permitiendo una red de pods plana.
- M2 (RBAC Excesivo): Se otorgaron privilegios de cluster-admin a una cuenta de servicio en el namespace del atacante.
- M3 (Runtime Privilegiado): Un pod fue configurado con privileged: true, montajes de hostPath y capacidades elevadas de Linux.
Escenarios de Ataque: Se ejecutaron cuatro escenarios de ataque contra el clúster mal configurado:
- Ataque A: Movimiento lateral mediante escaneo de red interna (nmap).
- Ataque B: Intentos repetidos de acceso no autorizado a la base de datos.
- Ataque C: Acceso al sistema de archivos del host mediante contenedores privilegiados.
- Ataque D: Abuso de RBAC para la enumeración de secretos en todo el clúster.
Recolección de Telemetría y Resolución de Verdad de Terreno: Hubble capturó registros JSON por flujo. Para abordar el desafío de la verdad de terreno planteado por la variabilidad de la integridad de los metadatos en los puntos de observación, se aplicó un proceso de resolución de verdad de terreno de cuatro versiones:
- v1: Etiquetado inicial a nivel de archivo (sobreestimó los ataques).
- v2: Eliminación del tráfico del pod atacante (sobre-filtrado, resultando en cero ataques).
- v3: Aplicación de filtrado por punto de observación y lógica de namespace de origen a nivel de flujo.
- v4 (Final): Exclusión de la comunicación del pod atacante con los namespaces de infraestructura (p. ej., kube-system), lo que resultó en un conjunto limpio de flujos de origen de ataque.
Marco de Detección: Se evaluaron dos detectores:
- Detector Basado en Reglas de Comportamiento: Definió reglas para el acceso a la base de datos entre namespaces, movimiento lateral y escaneo de puertos sensibles.
- Clasificador Random Forest: Entrenado con características derivadas de Hubble (identidades, puertos, puntos de observación, flags TCP) con pesos de clase equilibrados.
Evaluación: Los modelos se evaluaron mediante validación cruzada de ventana temporal de cinco pliegues, priorizando el análisis de Precisión-Recall y el Área Bajo la Curva de Precisión-Recall (AUPRC) debido al severo desequilibrio de clases.

Contribuciones Clave

Entorno Reproducible: Desarrollo de un entorno de prueba de cuatro nodos instrumentado con Cilium/Hubble, que aloja una aplicación de múltiples niveles en cinco namespaces.
Configuraciones Erróneas Validadas: Inyección y validación experimental de tres clases críticas de configuraciones erróneas (ausencia de NetworkPolicies, RBAC excesivo y ejecución privilegiada) vinculadas a escenarios de ataque reales.
Construcción de Conjunto de Datos Etiquetado: Creación de un conjunto de datos que contiene 3,180,125 flujos etiquetados (456 de origen de ataque, 3,179,669 benignos) derivados de 3.8 millones de registros brutos, utilizando una metodología documentada de resolución de verdad de terreno de cuatro versiones para manejar la arquitectura de múltiples puntos de observación de Cilium.
Evaluación Comparativa: Una comparación rigurosa de un detector basado en reglas y un clasificador Random Forest utilizando validación cruzada de ventana temporal, análisis de importancia de características y pruebas de ablación.
Perspectiva de Importancia de Características: Identificación de que los atributos de identidad del lado del destino son las señales discriminantes más fuertes en la telemetría de flujo de Kubernetes, exhibiendo una relación de importancia destino-origen de 2.8:1.

Resultados

Características del Conjunto de Datos: El conjunto de datos final contenía 456 flujos de ataque (0.014% del total), confirmando un desequilibrio de clases extremo. Los flujos de ataque se concentraron en PostgreSQL (5432), la API del backend (8080) y HTTP (80).
Impacto del Punto de Observación: No se etiquetaron flujos de ataque en el punto de observación TO_STACK debido a la falta de metadatos de destino completos. Todos los 456 flujos de ataque se localizaron en TO_ENDPOINT y TO_OVERLAY, donde los metadatos eran suficientes para la atribución. Una prueba de chi-cuadrado confirmó una asociación estadísticamente significativa entre los puntos de observación y las etiquetas de ataque ( $\chi^2 = 2610.1, p < 0.001$ ).
Rendimiento de los Detectores:
- Detector Basado en Reglas: Logró un AUPRC superior (0.311) en comparación con el Random Forest (0.284), lo que indica una precisión superior en puntos operativos de alta confianza. Sin embargo, tuvo un recall medio (0.746) menor que el del Random Forest (0.833).
- Random Forest: Logró un recall medio más alto pero con un AUPRC menor. Demostró una cobertura más amplia pero produjo puntuaciones de probabilidad más distribuidas.
Importancia de las Características: Los atributos del lado del destino (dst_identity, dst_port, dst_namespace, dst_pod) representaron el 64.2% de la importancia total de las características, con una relación destino-origen de 2.8:1. Las pruebas de ablación confirmaron que eliminar las características de namespace y pod de destino redujo el AUPRC en un 7.4%.
Rendimiento de las Reglas: La regla CROSS_NS_DB_ACCESS generó la mayor cantidad de verdaderos positivos (324) pero también la mayor cantidad de falsos positivos (425). La regla LATERAL_MOVEMENT tuvo una precisión más alta (0.556) pero un recall muy bajo (0.022).

Significancia y Reivindicaciones

El artículo sostiene que la telemetría de Hubble/eBPF puede soportar eficazmente la detección de ataques en tiempo de ejecución en entornos Kubernetes, siempre que se gestione con cuidado la arquitectura de múltiples puntos de observación. El estudio enfatiza que:

La Construcción de la Verdad de Terreno es Crítica: El etiquetado ingenuo de los datos de Hubble conduce a clases de ataque infladas o incorrectas. El proceso de resolución de cuatro versiones propuesto es esencial para crear conjuntos de datos de seguridad fiables.
El Contexto del Destino es Clave: A diferencia de la detección de intrusiones de red genérica, la detección de ataques en Kubernetes depende fuertemente de los atributos de identidad del lado del destino para distinguir la intención maliciosa (p. ej., un pod comprometido accediendo a una base de datos a través de namespaces).
Enfoques Complementarios: Los enfoques basados en reglas y de aprendizaje automático ofrecen fortalezas complementarias; las reglas proporcionan alertas interpretables de alta precisión, mientras que el aprendizaje automático ofrece una cobertura de recall más amplia.
Limitaciones: Los autores declaran modestamente que, aunque los resultados son prometedores, son específicos para el entorno de prueba evaluado. La generalización a entornos de producción más grandes, diversos y multi-inquilino requiere una validación adicional. El estudio no pretende resolver todos los problemas de seguridad de Kubernetes, sino demostrar la viabilidad de la telemetría de flujo basada en eBPF para la detección en tiempo de ejecución cuando se combina con una ingeniería de datos rigurosa.