27 de febrero de 2026 | Tiempo de lectura: 13 minutos 37 segundos
Introducción: El kernel como infraestructura
Durante décadas, la observabilidad significaba agregar código a tus aplicaciones. Instrumentabas tus servicios con librerías de métricas, esparcías SDKs de trazado a través de tus caminos de llamadas y configurabas shippers de logs en cada host. Cada capa de visibilidad tenía un costo: gestión de dependencias, overhead de rendimiento, cambios de código que necesitaban ser implementados y mantenidos. Perder un endpoint y tenías un punto ciego. Actualizar una librería y arriesgabas romper tu pipeline de telemetría.
eBPF cambia esta ecuación fundamentalmente. En lugar de instrumentar aplicaciones, instrumentas el kernel. Cada llamada del sistema, cada paquete de red, cada acceso a archivo, cada ejecución de proceso pasa a través del kernel de Linux — y eBPF te permite observar y actuar en estos eventos sin modificar las aplicaciones que los generan. Cero cambios de código. Cero dependencias de SDK. Cero coordinación de implementación.
Esto no es una mejora menor. Es una categoría diferente de capacidad. Cuando tu capa de monitoreo opera a nivel de kernel, ves todo — incluyendo las cosas que las aplicaciones eligen no registrar, las conexiones de red que evitan tu service mesh, y los procesos que tu container runtime no conoce.
El ecosistema eBPF ha madurado rápidamente a través de 2025 y hacia 2026. Lo que fue una vez una colección de proyectos de investigación y herramientas especializadas se ha convertido en infraestructura de producción a escala. Cilium maneja networking para proveedores de nube principales. Falco proporciona seguridad en tiempo de ejecución para clusters de Kubernetes en todo el mundo. Tetragon aplica políticas de seguridad directamente en el kernel. Y herramientas como Coroot ofrecen observabilidad de stack completo — métricas, logs, trazas y perfilado continuo — desde un único agente basado en eBPF que requiere cero cambios de aplicación.
Este artículo explica qué es eBPF, por qué importa para seguridad y observabilidad, y cómo adoptarlo en práctica.
Qué eBPF realmente es
eBPF significa extended Berkeley Packet Filter, aunque el nombre es mayormente histórico en este punto. El eBPF moderno ha ido mucho más allá del filtrado de paquetes.
En su núcleo, eBPF es una máquina virtual dentro del kernel de Linux que ejecuta programas en sandbox en respuesta a eventos del kernel. Estos programas pueden observar llamadas del sistema, tráfico de red, operaciones de archivos, planificación de procesos, y esencialmente cualquier actividad a nivel de kernel — todo sin modificar el kernel mismo o requerir módulos del kernel.
El modelo de seguridad
Lo que hace a eBPF práctico es su modelo de seguridad. Antes de que cualquier programa de eBPF se ejecute, el verificador del kernel lo verifica exhaustivamente:
- Sin bucles sin límites: Los programas deben terminar. El verificador rechaza programas que podrían ejecutarse indefinidamente.
- Sin acceso a memoria inválido: Cada desreferencia de puntero se valida. Los desbordamientos de buffer son imposibles.
- Límites de tamaño de pila: Los programas tienen un tamaño de pila fijo (512 bytes), previniendo agotamiento de pila.
- Acceso a funciones auxiliares: Los programas solo pueden llamar a funciones auxiliares del kernel preaprobadas, no código arbitrario del kernel.
- Requisitos de privilegio: Cargar programas de eBPF requiere capacidades apropiadas (típicamente
CAP_BPFo root).
Esta verificación ocurre en tiempo de carga, no en tiempo de ejecución. Una vez que un programa pasa el verificador, se ejecuta a velocidad casi nativa sin comprobaciones de seguridad en tiempo de ejecución. El resultado es observabilidad a nivel de kernel con overhead de rendimiento negligible — típicamente menos de 1-2% impacto en CPU para monitoreo integral.
Puntos de adjunción
Los programas de eBPF se adjuntan a eventos específicos del kernel llamados hooks o puntos de adjunción:
| Tipo de hook | Caso de uso | Ejemplo |
|---|---|---|
| kprobes | Rastrear cualquier función del kernel | Monitorear sys_open para rastrear acceso a archivos |
| tracepoints | Eventos estables de rastreo del kernel | Rastrear creación de procesos vía sched_process_exec |
| XDP | Procesamiento de paquetes de red | Descartar paquetes maliciosos antes de que alcancen el stack de red |
| TC | Control de tráfico | Aplicar políticas de red a nivel de contenedor |
| LSM | Hooks de módulo de seguridad Linux | Aplicar políticas de seguridad en operaciones de archivo |
| uprobe | Rastreo de función de espacio de usuario | Perfilar funciones de aplicación específicas |
| perf events | Contadores de rendimiento CPU | Perfilado continuo de CPU y memoria |
La amplitud de puntos de adjunción es lo que hace a eBPF tan poderoso. Un único agente basado en eBPF puede monitorear simultáneamente tráfico de red, acceso a archivos, ejecución de procesos, resolución de DNS y patrones de llamadas del sistema — proporcionando una vista unificada que tradicionalmente requeriría cinco o seis herramientas separadas.
eBPF para observabilidad: Viendo todo
La observabilidad tradicional tiene tres pilares: métricas, logs y trazas. eBPF habilita los tres sin instrumentación, y agrega un cuarto — perfilado continuo — que es impractico con enfoques a nivel de aplicación.
Mapas de servicio de cero instrumentación
Cuando eBPF monitorea conexiones de red a nivel de kernel, ve cada conexión TCP y UDP entre servicios — incluyendo conexiones que evitan tu service mesh, proxies sidecar o instrumentación a nivel de aplicación. Esto habilita descubrimiento automático de servicios y mapeo de dependencias.
Herramientas como Coroot usan esta capacidad para generar mapas de topología en vivo mostrando todas las dependencias de servicio. Sin cambios de código necesarios. Sin contenedores sidecar. Sin configuración por servicio. Implementa el agente, y dentro de minutos ves qué servicios se comunican con cuáles otros, la latencia de cada conexión y las tasas de error a través de cada camino.
Esto es particularmente valioso para:
- Aplicaciones legacy que no pueden ser instrumentadas sin esfuerzo significativo
- Servicios de terceros donde no controlas el código
- Entornos políglotas donde diferentes servicios usan diferentes lenguajes y frameworks
- Debugging de problemas de producción donde dependencias desconocidas causan fallos en cascada
Métricas conscientes de protocolo
eBPF no solo ve conexiones de red — entiende protocolos. Al analizar encabezados de paquetes a nivel de kernel, los agentes de eBPF pueden extraer métricas a nivel de aplicación sin conciencia de aplicación:
HTTP/HTTPS: Método de solicitud, ruta, código de estado, latencia — equivalente a lo que obtendrías de un log de acceso, pero capturado a nivel de kernel para cada servicio automáticamente.
Protocolos de base de datos: Los protocolos de wire de PostgreSQL, MySQL, Redis y MongoDB se analizan para extraer latencia de consulta, tasas de error y conteos de conexión. Esto significa que obtienes métricas de rendimiento de base de datos sin instalar ningún agente de monitoreo de base de datos o modificar strings de conexión.
gRPC: Seguimiento de latencia y error a nivel de método para servicios gRPC, capturado sin modificar la configuración del framework de gRPC.
DNS: Latencia de resolución y tasas de fallo para cada búsqueda de DNS, ayudando a identificar problemas relacionados con DNS que son notoriamente difíciles de debuggear con herramientas a nivel de aplicación.
Kafka: Medidas de lag de productor y consumidor capturadas a nivel de protocolo, proporcionando visibilidad independiente de broker en rendimiento de pipeline de mensajes.
Perfilado continuo
Quizás la capacidad más subestimada de la observabilidad basada en eBPF es el perfilado continuo. El perfilado tradicional requiere adjuntar un profiler a un proceso específico, ejecutarlo por un período, y analizar la salida. Esto es demasiado disruptivo e intensivo en recursos para uso en producción.
El perfilado basado en eBPF funciona de manera diferente. Se adjunta a perf events y muestrea trazas de pila de CPU en intervalos fijos a través de todos los procesos en un host. El overhead es mínimo — típicamente menos de 1% CPU — haciendo que sea factible ejecutar continuamente en producción.
El valor práctico es significativo. Cuando un servicio experimenta un pico de latencia, no necesitas reproducir el problema con un profiler adjunto. Los datos de perfilado ya están ahí, capturados como flame graphs que muestran exactamente dónde se gastó tiempo de CPU durante el incidente. Esto convierte debugging de rendimiento de una investigación reactiva en un análisis retrospectivo.
eBPF para seguridad: El kernel como primer respondedor
La observabilidad es solo la mitad de la historia. eBPF es igualmente transformador para seguridad en tiempo de ejecución, y la convergencia de observabilidad y seguridad en un único agente a nivel de kernel es uno de los cambios arquitectónicos más importantes en infraestructura moderna.
Detección de amenazas en tiempo de ejecución
El monitoreo de seguridad tradicional se basa en análisis de logs — examinando logs de aplicación, logs de auditoría y logs del sistema en busca de indicadores de compromiso. Este enfoque tiene limitaciones fundamentales: los atacantes pueden modificar o suprimir logs, las aplicaciones pueden no registrar eventos relevantes para la seguridad y el envío de logs introduce latencia entre un evento y su detección.
El monitoreo de seguridad basado en eBPF opera a un nivel diferente. Al enganchar en llamadas del sistema y eventos del kernel, observa actividades que ningún log puede suprimir:
- Ejecución de proceso: Cada proceso generado en un sistema, incluyendo los lanzados por exploits de breakout de contenedor
- Acceso a archivos: Cada archivo abierto, leído, escrito o eliminado, incluyendo acceso a rutas sensibles como
/etc/shadowo claves criptográficas - Conexiones de red: Cada conexión saliente, incluyendo las que evitan políticas de red a nivel de aplicación
- Escalada de privilegios: Llamadas del sistema que modifican capacidades de proceso, IDs de usuario o contextos de seguridad
- Carga de módulo del kernel: Intentos de cargar módulos del kernel, que pueden indicar instalación de rootkit
Aplicación de políticas
La detección es valiosa, pero la prevención es mejor. Los hooks LSM de eBPF (Linux Security Module) habilitan que las políticas de seguridad se apliquen directamente en el kernel, bloqueando acciones no autorizadas antes de que tomen efecto.
Tetragon, desarrollado por el equipo de Cilium, es la herramienta líder en este espacio. Proporciona:
Políticas de ejecución de proceso: Define qué binarios pueden ejecutarse en un contenedor. Si un shell se genera dentro de un contenedor que solo debería ejecutar un binario Go, Tetragon puede bloquear la ejecución y generar una alerta.
Políticas de red: Aplica qué destinos un pod puede conectar a nivel de kernel, evitando vulnerabilidades potenciales del container runtime.
Políticas de acceso a archivos: Restringe qué archivos y directorios un proceso puede acceder, proporcionando defensa en profundidad más allá de permisos del sistema de archivos.
Restricciones de capacidad: Limita qué capacidades de Linux un proceso puede ejercer, incluso si el container runtime las otorga.
La aplicación ocurre en el kernel, lo que significa que no puede ser evitada por exploits a nivel de aplicación. Un atacante que obtiene ejecución de código dentro de un contenedor aún no puede realizar acciones que la política de eBPF bloquea, porque la política se aplica antes de que la llamada del sistema se complete.
Seguridad de red
Cilium, la herramienta basada en eBPF más ampliamente implementada, ha redefinido cómo funciona la seguridad de red en entornos de Kubernetes. Las políticas de red tradicionales operan a nivel de dirección IP y puerto. Las políticas basadas en eBPF de Cilium operan a nivel de identidad y API:
- Políticas basadas en identidad: Las políticas hacen referencia a labels de Kubernetes e identidades de servicio en lugar de direcciones IP, eliminando la necesidad de rastrear asignaciones de IP de pod
- Filtrado L7: Políticas conscientes de HTTP, gRPC y Kafka que pueden restringir acceso a endpoints de API específicos, no solo puertos
- Encriptación transparente: Encriptación basada en WireGuard entre nodos, implementada en el kernel vía eBPF sin requerir cambios de aplicación
- Gestión de ancho de banda: Límites de ancho de banda por pod aplicados a nivel de kernel
El ecosistema de herramientas eBPF
El ecosistema eBPF se ha consolidado alrededor de varios proyectos clave, cada uno abordando un dominio específico.
Networking y seguridad
| Herramienta | Propósito | Mantenedor |
|---|---|---|
| Cilium | Networking de Kubernetes, política de red, service mesh | Isovalent (Cisco) |
| Tetragon | Aplicación de seguridad en tiempo de ejecución | Isovalent (Cisco) |
| Falco | Detección de amenazas en tiempo de ejecución | Sysdig / CNCF |
| Calico eBPF | Networking de Kubernetes con datapath eBPF | Tigera |
Observabilidad
| Herramienta | Propósito | Mantenedor |
|---|---|---|
| Coroot | Observabilidad de stack completo (métricas, logs, trazas, perfilado) | Coroot |
| Hubble | Observabilidad de red para Cilium | Isovalent (Cisco) |
| Pixie | Observabilidad de Kubernetes | New Relic / CNCF |
| Parca | Perfilado continuo | Polar Signals |
| Grafana Beyla | Auto-instrumentación para HTTP y gRPC | Grafana Labs |
Rastreo y debugging
| Herramienta | Propósito | Mantenedor |
|---|---|---|
| bpftrace | Lenguaje de rastreo de alto nivel para eBPF | IO Visor |
| BCC | Conjunto de herramientas BPF Compiler Collection | IO Visor |
| bpftool | Utilidad de gestión de programas eBPF | Linux kernel |
Adopción práctica: Comenzando
Adoptar eBPF no requiere conocimiento profundo del kernel. Las herramientas modernas de eBPF abstraen la complejidad y presentan interfaces familiares — dashboards, alertas y definiciones de políticas.
Comenzando con observabilidad
El punto de entrada de menor riesgo es la observabilidad. Implementa un agente basado en eBPF como Coroot o Grafana Beyla junto con tu stack de monitoreo existente. El agente no requiere cambios de aplicación — se ejecuta como un contenedor privilegiado o DaemonSet e inmediatamente comienza a recopilar métricas.
Para entornos de Kubernetes:
# Implementar Coroot con Helm
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce
# Acceder al dashboard
kubectl port-forward -n coroot service/coroot-coroot 8080:8080
Dentro de minutos, verás un mapa de servicio, métricas de latencia para conexiones HTTP y base de datos, y datos de utilización de recursos — todo capturado sin cambios de instrumentación a tus aplicaciones.
Añadiendo aplicación de seguridad
Una vez que la observabilidad está en su lugar, el siguiente paso natural es la aplicación de seguridad. Tetragon proporciona un camino graduado:
Fase 1: Modo auditoría. Implementa Tetragon con políticas en modo auditoría. Registra violaciones de políticas sin bloquearlas, dándote tiempo para entender tu comportamiento de aplicación y refinar políticas antes de aplicación.
Fase 2: Modo alerta. Conecta eventos de Tetragon a tu sistema de alertas. Recibe notificaciones cuando ocurre actividad sospechosa — procesos inesperados, conexiones de red no autorizadas, acceso a archivos sensibles.
Fase 3: Modo aplicación. Habilita aplicación en políticas que han sido validadas en modo auditoría. Comienza con las restricciones más críticas — prevención de breakout de contenedor, por ejemplo — y gradualmente expande cobertura.
Requisitos del kernel
Las capacidades de eBPF dependen de la versión del kernel de Linux. Para herramientas modernas de observabilidad y seguridad de eBPF, necesitas:
| Característica | Kernel mínimo | Recomendado |
|---|---|---|
| eBPF básico | 4.4 | 5.10+ |
| Soporte BTF | 5.2 | 5.10+ |
| Hooks LSM | 5.7 | 5.15+ |
| Tokens BPF | 6.9 | 6.9+ |
| Ring buffer | 5.8 | 5.10+ |
La mayoría de servicios gestionados de Kubernetes de proveedores de nube (EKS, GKE, AKS) ejecutan kernels que soportan todas las características modernas de eBPF. Las implementaciones on-premises deberían apuntar a kernel 5.10 o posterior para la mejor compatibilidad.
Consideraciones de rendimiento
El monitoreo con eBPF agrega overhead mínimo, pero "mínimo" no es "cero":
- Overhead de CPU: Típicamente 1-2% para monitoreo integral (red, proceso, archivo, perfilado)
- Uso de memoria: 50-200 MB por nodo para el agente, dependiendo de cardinalidad
- Overhead de red: Las métricas y eventos se envían a un servidor central; el uso de ancho de banda depende del tamaño del cluster y la actividad
- Almacenamiento: ClickHouse (usado por Coroot) o Prometheus (usado por muchas herramientas) requieren almacenamiento proporcional al número de servicios y período de retención
Para la mayoría de entornos, estos overheads son negligibles comparados con la visibilidad ganada. Sin embargo, sistemas de comercio de alta frecuencia, procesamiento de audio/video en tiempo real y otras cargas de trabajo críticas de latencia deberían hacer benchmark cuidadosamente de herramientas de eBPF antes de implementación en producción.
La convergencia de seguridad y observabilidad
La tendencia más significativa en el ecosistema eBPF es la convergencia de seguridad y observabilidad en plataformas unificadas. Históricamente, estas eran disciplinas separadas con herramientas separadas, equipos separados y presupuestos separados. eBPF borra el límite técnico.
Cuando un único agente a nivel de kernel captura conexiones de red, ejecución de proceso, acceso a archivos y patrones de llamadas del sistema, los mismos datos sirven ambos propósitos:
- Observabilidad: "La latencia del servicio A a la base de datos aumentó 200ms después de la última implementación"
- Seguridad: "Un proceso inesperado se generó en el contenedor del servicio A e hizo una conexión saliente a una IP desconocida"
Ambas observaciones vienen de la misma fuente de datos eBPF. La diferencia está en cómo se analizan los datos y qué acciones se desencadenan. Esta convergencia reduce sprawl de agentes (un agente en lugar de tres o cuatro), elimina duplicación de datos y habilita correlación que fue previamente imposible — como vincular un evento de seguridad a su impacto de rendimiento en tiempo real.
Herramientas como Coroot ya encarnan esta convergencia, proporcionando dashboards de observabilidad junto con seguimiento de SLO y detección de anomalías. Cilium y Tetragon juntos proporcionan networking, observabilidad y aplicación de seguridad desde una plataforma única. Espera que esta convergencia se acelere mientras el ecosistema madura.
Conclusión: La nueva capa de infraestructura
eBPF se ha movido de una característica del kernel de Linux a una capa de infraestructura fundamental. Es la tecnología detrás del networking en la mayoría de los servicios gestionados de Kubernetes de proveedores de nube principales. Impulsa las plataformas de observabilidad que reemplazaron agentes APM tradicionales. Aplica las políticas de seguridad que protegen contenedores en tiempo de ejecución.
Para equipos de ingeniería, la conclusión práctica es directa: si estás ejecutando cargas de trabajo de Linux — especialmente en Kubernetes — las herramientas basadas en eBPF deberían ser parte de tu stack de infraestructura. La observabilidad que ganas sin cambios de código es notable. La aplicación de seguridad que puedes agregar sin modificaciones de aplicación es transformador. Y la convergencia de ambas capacidades en plataformas unificadas simplifica operaciones de formas que stacks de herramientas separadas nunca podrían.
Comienza con observabilidad. Agrega aplicación de seguridad gradualmente. Deja que el kernel haga el trabajo que has estado pidiendo a tus aplicaciones que hagan. Los resultados valdrán la pena.