Monitoreo de eBPF en Kubernetes: Detección de amenazas de tiempo de ejecución invisibles

9 Min. Tiempo de lectura

Los atacantes estuvieron en los clústeres de Kubernetes alemanes en 2025 más tiempo del que el mediano de los CISO de DACH está dispuesto a admitir. Sysdig ha documentado en su Informe de Amenazas 2026 que el tiempo promedio de permanencia de un intruso en un contenedor es de 196 horas, mientras que el informe M-Trends de Mandiant llega a 21 días. La brecha entre la realidad del clúster y el campo de visión del EDR es amplia y estructural. La detección clásica de puntos finales funciona a nivel de host y no ve la mayoría de las actividades relevantes en un contenedor. Con eBPF y las herramientas de código abierto Falco y Tetragon, esta brecha se cierra en 2026. Black Hat USA 2026 ha elevado a eBPF a un seguimiento oficial, lo que configura el mercado de ingeniería de detección para los próximos doce meses.

Por qué el EDR clásico no es suficiente en el clúster

La detección y respuesta de puntos finales (EDR) se diseñó para configuraciones clásicas de servidores y estaciones de trabajo. Un agente de EDR se ejecuta en el host, observa la genealogía de procesos, las operaciones de archivos, las conexiones de red y responde a anomalías predefinidas. En un entorno de Kubernetes, este modelo falla por tres razones.

Primero: Los contenedores son efímeros. Un pod que solo vive 90 segundos deja como máximo una huella en el EDR del host que cae bajo el muestreo de telemetría. La lógica de detección asume procesos de minutos de duración, cuando en realidad son segundos. Quien observa las cargas de trabajo de contenedores con granularidad de host no ve el 70 al 80 por ciento de los eventos relevantes.

Segundo: Ejecución en memoria. Las cadenas de herramientas de atacantes modernos para contenedores utilizan cargadores que solo residen en memoria y nunca escriben un archivo en disco. La detección clásica de EDR, que se basa en eventos del sistema de archivos, es conceptualmente ciega aquí. eBPF, por otro lado, ve las llamadas al sistema subyacentes porque deben pasar por el kernel.

Tercero: Arquitecturas de sidecar y service mesh. Si un solo pod tiene cinco contenedores y siete conexiones de red que se ejecutan internamente a través de mTLS, un EDR de host ve principalmente paquetes de red poco claros. La capa semántica falta. eBPF puede enriquecer esta telemetría a nivel de carga de trabajo porque proviene del kernel, antes de que se aplique mTLS.

Cómo trabajan Falco y Tetragon concretamente

Ambas herramientas se basan en eBPF, pero se diferencian en su enfoque y nivel de madurez. Falco es el proyecto más antiguo, graduado en CNCF, proporciona una biblioteca de reglas establecida e integra perfectamente con Prometheus, Loki y pipelines SIEM. Su fortaleza radica en su amplitud y madurez: un conjunto de reglas estándar de Falco detecta entre el 60 y el 80 por ciento de las técnicas MITRE-ATT&CK-for-Container en su primera versión.

Tetragon proviene del ecosistema Cilium, está estrechamente vinculado a Cilium CNI y aporta dos características que Falco no proporciona en esta profundidad: primero, una genealogía de procesos completa, es decir, el árbol genealógico padre-hijo de cada actividad de contenedor; segundo, una capa de aplicación en tiempo real. Tetragon no solo puede detectar que un proceso llama a un syscall prohibido, sino que también puede bloquear la llamada directamente en el kernel.

Para 2026, la pila pragmática en los operadores de clústeres DACH más grandes suele verse así: Falco como detector de base amplio con biblioteca de reglas e integración SIEM, Tetragon complementario para la genealogía de procesos en namespaces especialmente sensibles y para la aplicación selectiva en tiempo de ejecución. Quien quiera utilizar solo uno de los dos en 2026, comienza con Falco, porque la curva de aprendizaje es más plana y la integración del operador es más amplia.

Alcance de la telemetría en 2026

Informe de amenazas de Sysdig 2026: el 73 por ciento de las intrusiones de contenedores permanecieron sin detectar en hosts con telemetría EDR pura, el 11 por ciento en clústeres con detección basada en Falco. Black Hat USA 2026 tiene a eBPF en la selección de ponencias con 9 charlas – tantas como nunca.

Ejemplos concretos de detección de amenazas en memoria

Tres patrones de ejemplo que han aumentado mensuradamente en clústeres DACH en 2026 y que se vuelven tangibles con telemetría eBPF.

Cargador Memfd y ejecución sin archivo. Los atacantes crean un descriptor de archivo de memoria anónimo a través de memfd_create, escriben código en él y lo ejecutan sin rastros de disco. Regla de Falco patrón: alerta en memfd_create seguida de execveat dentro del mismo grupo de procesos en un namespace productivo. El EDR del host no ve aquí ningún archivo, eBPF ve las dos llamadas al sistema.

Escape de contenedor a través de la escalada de privilegios cap_sys_admin. Patrón de escape clásico que vuelve a aparecer con más frecuencia en los registros de Honeypot en 2025/2026. Política de rastreo de Tetragon alerta en cambio de capacidad dentro de un contenedor que no comienza en el namespace privilegiado. El EDR del host solo ve el contenedor como un proceso genérico del runtime del contenedor, el cambio de privilegios permanece invisible.

Rootkits basados en eBPF. Los atacantes cargan sus propios programas eBPF que parchean llamadas al sistema y ocultan actividad de herramientas clásicas. Alerta del plugin de Falco ebpf-program-loaded en bpf_prog_load en un namespace no liberado. Aquí solo ayuda la telemetría del propio kernel, porque la vista del espacio de usuario es manipulada por el rootkit.

Ventajas y desventajas de las dos herramientas

A favor de Falco

CNCF-Graduated, alta madurez
Amplia biblioteca de reglas lista para usar
Integración clara con SIEM y Loki
Curva de aprendizaje más suave para los equipos de SOC

En contra de Falco

Detección pura, sin aplicación
Genealogía de procesos menos profunda
La biblioteca de reglas requiere un mantenimiento activo
Tasa de falsos positivos en clústeres densos

A favor de Tetragon

Aplicación en tiempo real en el kernel
Genealogía completa de procesos
Integración con Cilium-CNI
Observabilidad de red a nivel de carga de trabajo

En contra de Tetragon

Curva de aprendizaje más pronunciada para los equipos de detección
Sintaxis de política de rastreo menos documentada
Vínculo más estrecho con la pila de Cilium
Integración con SIEM aún en maduración

Cómo se ve un rollout realista en 2026

Rollout de detección con eBPF en cuatro oleadas

Semana 1 a 4. Operador de Falco en dos clústeres piloto (Staging, un namespace productivo), habilitar reglas estándar, transmitir telemetría a Loki y al SIEM. Objetivo: línea de base para el volumen de alertas y la tasa de falsos positivos.

Semana 5 a 12. Construir biblioteca de reglas personalizadas, utilizar MITRE-ATT&CK-for-Container como mapeo, priorizar tres a cinco riesgos principales (escalada de privilegios, cargador Memfd, minería de criptomonedas, shell inverso, carga de programa eBPF).

Semana 13 a 20. Introducir Tetragon en paralelo en los namespaces más sensibles, inicialmente solo rastreo, sin aplicación. Genealogía de procesos como complemento a la telemetría de Falco en el SIEM.

A partir de la semana 21. Aplicación selectiva de Tetragon para patrones anti claros definidos (por ejemplo, fork-exec desde un contenedor Init, escalada de capacidades en el namespace de carga de trabajo). Control de cambios cuidadoso con los propietarios de la carga de trabajo.

Es importante no considerar el rollout como la introducción de una herramienta, sino como un programa de ingeniería de detección. Una canalización basada en eBPF sin reglas documentadas, sin pruebas de CI para la lógica de detección y sin una rutina de clasificación de alertas en las capas de SOC produce datos sin efecto. Quien quiera utilizar Falco y Tetragon de manera seria, planea para 2026 con dos o tres FTE de ingeniería de detección que no sean absorbidos por el trabajo diario normal del SOC.

Dónde la disciplina 2026 todavía flaquea

Tres puntos abiertos acompañan la tendencia de eBPF en 2026 y deberían estar reflejados en cada concepto. Primero: deriva de la versión del kernel. Los programas eBPF están estrechamente vinculados a la interfaz del kernel, que puede cambiar entre versiones del kernel. Quien apuesta por nodos de trabajo de larga duración debe tomar en serio CO-RE (compilar una vez, ejecutar en todas partes), de lo contrario, cada actualización del kernel destrozará la canalización de detección.

Segundo: sobrecarga de rendimiento en clústeres densos. Falco con reglas moderadas cuesta entre el 1 y el 3 por ciento de CPU de trabajador bajo carga normal, pero puede ser significativamente mayor en clústeres densos de varios inquilinos. Los perfiles de rendimiento de reglas cuidadosas y filtros dirigidos son obligatorios en 2026, de lo contrario, comenzarán las discusiones de FinOps que ponen en peligro el programa.

Tercero: Kubernetes gestionado en la nube con ciclos de vida de bloqueo. AWS EKS, GKE y AKS ahora permiten programas eBPF, pero con diferentes restricciones. Quien opera K8s en varias nubes debe construir una estrategia de detección coherente en todas las plataformas, no en cada clúster por separado.

Preguntas frecuentes

¿Reemplaza la detección de eBPF la EDR clásica en el clúster?

No. La EDR clásica sigue siendo relevante para el nivel de host y el compromiso de nodos de trabajo. Las herramientas basadas en eBPF cierran la brecha de visibilidad de los contenedores y amplían la pila. Una detección de clúster moderna en 2026 combina EDR en el nivel de trabajador con Falco o Tetragon en el nivel de pod y con detección de red en el nivel de malla.

¿Cuánto es el sobrecarga de rendimiento de Falco en producción?

Con reglas moderadas, la sobrecarga de CPU por nodo de trabajo suele estar entre el 1 y el 3 por ciento. En clústeres densos de varios inquilinos con reglas agresivas, pueden aparecer entre el 5 y el 8 por ciento. Quien mantiene activamente los perfiles de rendimiento de reglas mantiene la sobrecarga en un solo dígito porcentual.

¿Qué curva de aprendizaje deben planificar los equipos de SOC para eBPF?

Realísticamente, de dos a cuatro semanas para Falco hasta el cuidado de reglas productivas, de cuatro a ocho semanas para Tetragon. Más importante que la profundización en la herramienta es la práctica de ingeniería de detección: mapeo MITRE-ATT&CK, CI para reglas, bucles de triage de alertas. Sin esta práctica, eBPF sigue siendo una fuente de telemetría costosa.

¿Debería utilizarse Falco y Tetragon simultáneamente?

En grandes clústeres de más de veinte nodos de trabajo y varios espacios de nombres sensibles, vale la pena operar en paralelo. Falco aporta una amplia cobertura y conexión SIEM, Tetragon profundiza en la genealogía de procesos y proporciona aplicación. En configuraciones más pequeñas, normalmente basta con Falco solo.

¿Cómo cambia eBPF la discusión de cumplimiento de NIS2?

Positivo. Los obligados a NIS2 deben demostrar capacidades de detección y respuesta. La telemetría basada en eBPF mejora significativamente la calidad del rastro de auditoría, porque las llamadas al sistema del kernel son la fuente más fiable para la forense. Quien en 2026 tiene que actualizar su conjunto de NIS2 de todos modos, debería incluir la cobertura de eBPF como argumento.