Kubernetes on lo0 — Blog Técnico

Hubble: observabilidad de red en eBPF, estado del arte 2026 y la nueva frontera con los agentes IA

Tue, 19 May 2026 06:00:00 +0200

TL;DR

Hubble es la observabilidad de red nativa de Cilium, construida sobre los mismos programas eBPF que Cilium usa para enforcement. No duplica datapath ni instrumenta el kernel a su manera: escucha los hooks que Cilium ya tiene y produce flow logs estructurados con contexto Kubernetes incluido —pod, namespace, labels, service, verdict de policy, payload L7 cuando aplica—. Es lo que pasa cuando alguien decide que tcpdump con grep no escala a 10 000 pods y construye un sistema distribuido propio (Hubble server por nodo + Hubble Relay como agregador + CLI + UI) con overhead prácticamente cero porque la captura ya estaba ocurriendo. En 2026 está en versión 1.19.3 (abril 2026), con Cilium 1.19 marcando el décimo aniversario del proyecto; ha llegado el tracing por IP options, el filtrado por estado de cifrado, el drop event taggeado con la NetworkPolicy exacta que lo causó (atribución directa), el field mask API estabilizado, y la primera oleada de anomaly detection con ML aplicado a flows para predictive security en clusters IoT/5G. Y, lo más interesante para 2026: aparece una frontera nueva donde el mismo eBPF observa agentes de IA —Claude Code, Gemini CLI, agentes MCP— interceptando SSL/TLS y stdio sin instrumentar el código, lo que convierte el stack Cilium + Hubble + Tetragon + AgentSight en una pila completa para entender qué hace un sistema agentic dentro de un cluster.

Este artículo es la parte 3 de la serie sobre eBPF. Parte 1: eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP. Parte 2: Tetragon: el primo de seguridad de Cilium que ve cada syscall en el kernel. Aquí completamos el cuadrante de observabilidad: red con Hubble, proceso con Tetragon, agente IA con AgentSight.

La analogía: tcpdump que habla Kubernetes

Si has administrado redes los últimos veinte años, tcpdump y Wireshark han sido el pan nuestro de cada día. Capturan paquetes en una interfaz, los parsean, te dejan filtrar con tcp.port == 443 and host 10.0.0.5. Funcionan, llevan funcionando desde los 90, y son lo primero que abres cuando algo huele raro.

Ahora pega tcpdump a un cluster Kubernetes de 10 000 pods. Los problemas saltan en orden:

Una sesión tcpdump por nodo. Querías “ver el tráfico entre el frontend y la API”; necesitas SSH a cada nodo, tcpdump por cada NIC, sincronizar timestamps, agregar a mano.
No hay contexto K8s. Ves un paquete de 10.244.5.7 a 10.244.8.42. ¿Qué pod era? ¿Qué namespace? ¿Qué label? Te toca correlar con kubectl get pod -A -o wide cada vez.
Sin entender L7. Ves un POST a HTTPS, no puedes saber qué método y path porque está cifrado en el cable. Si hay mTLS entre pods, peor.
Coste alto: captura completa de paquetes con copia a userspace ralentiza el datapath. En tráfico denso, lo notas.

Hubble es tcpdump rediseñado para todo eso. Reutiliza los programas eBPF que ya están procesando cada paquete (Cilium los pone ahí para enforcement) y, mientras toman su decisión de allow/deny, emiten un evento de flow con todo el contexto: identidad del pod origen y destino, namespace, labels, protocolo, verdict, y —si Cilium ha hecho parsing L7 vía Envoy— método HTTP, path, status code, DNS query, Kafka topic. Ese evento viaja por un ringbuffer a userspace, lo recibe el Hubble server que vive dentro del agent Cilium del nodo, y lo expone vía gRPC. Un servicio aparte, Hubble Relay, agrega los streams de todos los nodos y te da una única API cluster-wide. Por encima de eso: una CLI (hubble) y una UI web con grafo de servicios en tiempo real.

Cero copia adicional. Cero parsing duplicado. Y el resultado lo entiende cualquiera que sepa qué es un Pod.

Arquitectura: cuatro piezas que se ven desde fuera

Hubble se compone de cuatro componentes lógicos, todos opcionales según lo que quieras hacer:

1. Hubble Server (embedded en cada agent Cilium)

Vive dentro del proceso del agent Cilium (no es un binario aparte). Cada nodo expone localmente un endpoint gRPC en el socket Unix /var/run/cilium/hubble.sock. El server escucha los eventos que los programas eBPF emiten al ringbuffer, los enriquece con metadata Kubernetes (que el agent ya tiene en memoria), y los pone disponibles para consumidores.

Activación: --set hubble.enabled=true en el chart Helm de Cilium. Por defecto, el server solo es accesible localmente; si quieres consumirlo desde otro nodo, hace falta exponerlo (lo que hace Hubble Relay).

2. Hubble Relay (agregador)

Es un Deployment aparte (típicamente 1 réplica, escalable) que se conecta a todos los Hubble servers del cluster y agrega sus streams en una única API. Cuando tu CLI o UI pide “los últimos 1000 flows del cluster”, la Relay los recoge en paralelo de todos los nodos y devuelve la unión.

Activación: --set hubble.relay.enabled=true. Sin la Relay, solo ves el tráfico del nodo donde estás conectado, lo que es útil para debug local pero no para visión cluster-wide.

3. Hubble CLI (`hubble`)

Un binario en Go que habla gRPC con la Relay (o con un Hubble server local). Soporta dos modos principales:

hubble observe: stream de flows en tiempo real, con filtros muy expresivos (por namespace, pod, port, verdict, protocolo, label).
hubble status: estado del cluster Hubble (cuántos nodos conectados, lag, flow rate).

Y el equivalente a tcpdump’s pcap dump: hubble observe --output jsonpb > flows.json para procesar a posteriori con jq u otras herramientas.

4. Hubble UI

Frontend web que se conecta a Hubble Relay y muestra:

Grafo de servicios en tiempo real (qué Pod habla con qué Service, qué protocolos usa, qué verdict).
Lista de flows filtrable.
Detalles L7 cuando los hay (HTTP method/path/status, DNS query/response).

Activación: --set hubble.ui.enabled=true. Útil para presentaciones a equipos no-CLI; no sustituye a la CLI para debug serio.

Qué se ve: el flow log de Hubble por dentro

Un flow de Hubble en formato JSON tiene aproximadamente esta forma (simplificado):

{
 "time": "2026-05-19T03:12:45.182Z",
 "verdict": "FORWARDED",
 "source": {
 "ID": 5482,
 "identity": 24871,
 "namespace": "prod-api",
 "labels": ["app=checkout", "team=payments"],
 "pod_name": "checkout-7c9f-x8j2",
 "workloads": [{"name": "checkout", "kind": "Deployment"}]
 },
 "destination": {
 "ID": 12041,
 "identity": 18356,
 "namespace": "prod-db",
 "labels": ["app=postgres", "tier=primary"],
 "pod_name": "postgres-0"
 },
 "Type": "L3_L4",
 "l4": {
 "TCP": {
 "source_port": 41982,
 "destination_port": 5432,
 "flags": {"SYN": true}
 }
 },
 "node_name": "rke2-worker-03",
 "Summary": "TCP Flags: SYN"
}

Cuando hay parsing L7 activo (vía Envoy embebido o el parser ligero de Hubble), el mismo flujo añade:

"l7": {
 "type": "REQUEST",
 "http": {
 "code": 200,
 "method": "GET",
 "url": "/api/v1/cart/items",
 "protocol": "HTTP/1.1",
 "headers": [{"key": "user-agent", "value": "checkout/1.4.2"}]
 }
}

Los protocolos soportados nativamente para parsing L7:

HTTP/1.1 y HTTP/2 (incluyendo gRPC sobre HTTP/2).
DNS (queries y responses, con domains, tipos, response codes).
Kafka (topics, API keys).
TLS handshake (SNI, no el payload cifrado por defecto).
MySQL, Cassandra (con módulos opcionales).

Para HTTP y gRPC, Cilium puede activar el proxy Envoy embebido para los flujos que quieras inspeccionar (no todos; selectivo via CiliumNetworkPolicy con reglas L7). Sin Envoy hay parsing ligero pero menos detallado.

Verdict y atribución de drops

Cada flow tiene un verdict: FORWARDED, DROPPED, ERROR, AUDIT, REDIRECTED, TRACED, TRANSLATED. Para el caso DROPPED, Hubble incluye una razón estructurada (drop_reason) y, desde Cilium 1.19, la NetworkPolicy exacta que lo causó.

Esto último cambia la operativa. Antes, cuando un pod no podía hablar con otro, el flujo de debug era:

Ver el flow dropeado en Hubble.
Mirar todas las CiliumNetworkPolicy del namespace.
Razonar a mano cuál de ellas, con cuáles labels, lo está bloqueando.

Con la atribución de Cilium 1.19, el campo policy_match_info te dice directamente “lo dropeó la policy frontend-egress, regla 3”. Pasas de “Sherlock Holmes durante 20 minutos” a “kubectl get -o yaml de esa policy concreta”.

Métricas Prometheus y dashboards Grafana

Hubble también expone métricas agregadas en formato Prometheus, separadas del stream gRPC de flows. Activación: --set hubble.metrics.enabled=true (Helm) y enumeración del set que quieres exportar.

Los grupos de métricas habituales:

flow: total flows por verdict, source/dest, protocolo.
http: requests por método, código de respuesta, latencia (histograma).
dns: queries, response codes, dominios top-N.
tcp: handshakes, retransmisiones, ventana congestion.
drop: drops por razón, con NetworkPolicy attribution.
port-distribution: histograma de ports activos.
policy: hits por policy y verdict.

Estas métricas tienen labels K8s ricos (source_workload, destination_workload, namespace, etc.) que las hacen pivotables en Grafana. Hay dashboards prebuilt en Grafana Labs que cubren los casos comunes; importar uno y tener visión inmediata cuesta cinco minutos.

Coste: las métricas con muchos labels K8s pueden explotar la cardinalidad en Prometheus. Para clusters grandes (>1 000 pods), conviene revisar qué set exportas y usar drop rules en Prometheus para limitar.

Despliegue: Helm en una pantalla

Instalación canónica de Cilium con Hubble completo:

# values.yaml
hubble:
 enabled: true
 metrics:
 enabled:
 - dns:query;ignoreAAAA
 - drop
 - tcp
 - flow
 - port-distribution
 - icmp
 - httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction
 serviceMonitor:
 enabled: true # auto-discover por kube-prometheus-stack
 relay:
 enabled: true
 rollOutPods: true
 ui:
 enabled: true
 rollOutPods: true
 ingress:
 enabled: true
 className: cilium
 hosts:
 - hubble.example.local

Y la instalación:

helm upgrade --install cilium cilium/cilium -n kube-system -f values.yaml

Tras la instalación, valida con cilium status (CLI de Cilium) que la sección Hubble muestra OK, y prueba el primer flow con:

cilium hubble observe --namespace prod-api --pod checkout-7c9f-x8j2

Estado del arte en 2026

Cilium 1.19 se publicó en febrero de 2026 marcando el décimo aniversario del proyecto. Hubble alcanzó la versión 1.19.3 el 22 de abril de 2026. Las novedades relevantes:

Atribución directa de drops a NetworkPolicy

Ya cubierta arriba; es probablemente el cambio operacional más valioso del release. Cualquier flow dropeado lleva el nombre, namespace y regla específica de la policy responsable. Aplicable también vía métricas Prometheus, lo que permite alertas tipo “policy X está dropping >N peticiones/segundo”.

Tracing con IP options

Hubble puede ahora trazar paquetes individuales con IP options activado. Es un mecanismo similar al traceroute pero a nivel L3: pones una marca en el paquete y Cilium la reporta cada vez que el paquete atraviesa un nodo o una decisión de eBPF. Útil para debug de paths multi-cluster, fabric mesh, o NetworkPolicy que se aplican en distintas capas.

Filtrado por estado de cifrado

Nuevo flag en CLI: hubble observe --encryption-status=encrypted (o unencrypted). Útil para validar despliegues con WireGuard o IPsec activado pod-a-pod: confirmas que el tráfico que debería estar cifrado lo está, y detectas regresiones rápidamente.

Hubble field mask API estabilizado

El field_mask permite pedir solo las partes del flow que te interesan, reduciendo enormemente el ancho de banda y el procesamiento cuando solo necesitas, por ejemplo, source/dest y verdict. Antes era experimental, ahora está estable y es default-on en la CLI.

AI-driven anomaly detection (predictive security)

Esta es la incorporación más comentada de 2026. Cilium 1.19 añade hooks para que un consumer externo —típicamente un sistema ML— procese los flows en streaming y detecte anomalías estadísticas: pods que de pronto hablan con destinos nuevos, picos de latencia en una API, secuencias raras de DNS. La parte de detección ocurre fuera del agent Cilium (no se quiere ML pesado en el datapath), pero Cilium expone los flows con las features pre-calculadas que el modelo necesita. Los casos de uso publicados se enfocan en IoT y 5G donde el tráfico es alto en volumen y bajo en variedad, condiciones ideales para anomaly detection.

Escala a 10 000+ pods

Cilium 1.19 ha hecho trabajo serio en escalabilidad: Hubble Relay puede ahora agregar streams de cientos de nodos sin saturar; el field_mask por defecto reduce el ancho de banda inter-nodo; y los flows pueden samplearse en alta carga si tu uso es análisis estadístico (no debug forense).

Cilium 1.20 en desarrollo

Cilium 1.20 está en branch de desarrollo. Lo más relevante para Hubble:

Unificación de preferIpv6: el flag hubble.preferIpv6 se deprecó en favor del global preferIpv6 aplicable a todos los componentes Cilium.
tetragon-python SDK: aunque es de Tetragon, no de Hubble, marca tendencia: políticas eBPF escritas en Python en lugar de YAML. Probablemente Hubble seguirá camino similar.

La nueva frontera: eBPF y los agentes de IA

Hasta aquí el contenido clásico de Hubble. Pero hay un giro 2026 que merece la pena cubrir porque cierra el círculo con la otra serie de este blog.

Cuando un cluster Kubernetes empieza a ejecutar agentes de IA —Claude Code, Gemini CLI, agentes basados en LangGraph que llaman APIs y MCP servers—, el problema de observabilidad cambia de forma. Ya no basta con saber “qué pod habló con qué pod” (eso es Hubble) ni “qué proceso ejecutó qué” (eso es Tetragon). Necesitas saber:

A qué APIs externas está llamando el agente y con qué prompts.
Qué herramientas MCP está invocando, con qué argumentos.
Cuántos tokens consume, qué modelo elige, cuánto cuesta.
Si el agente se desvía del comportamiento esperado (out-of-policy queries, intentos de jailbreak, leakage de secretos).

Las soluciones tradicionales —instrumentar el código del agente con OpenTelemetry, parsear logs estructurados— no funcionan bien cuando el agente es un binario de terceros (Claude Code de Anthropic, Gemini CLI de Google) o cuando los MCP servers viven en otros lenguajes con stdio como transport.

AgentSight: zero-instrumentation para agentes LLM

AgentSight (proyecto del grupo eunomia-bpf, mismo ecosistema de varios runtimes eBPF de alto perfil) ataca este problema con la misma filosofía que Hubble: no instrumentes; escucha. Pone hooks eBPF en dos puntos críticos:

uprobes en bibliotecas SSL/TLS (libssl, boringssl, rustls). Captura el plaintext antes del cifrado en send y después del descifrado en recv. Para una llamada HTTP a https://api.anthropic.com/v1/messages, AgentSight ve el JSON completo del prompt y la respuesta sin descifrar nada en transit, simplemente porque ha llegado al nivel del syscall antes de que la TLS layer haga su trabajo.
stdiocap BPF: captura read, write, dup sobre los file descriptors de stdin/stdout/stderr de un proceso. Esto es lo que permite observar MCP servers que hablan stdio con su cliente —el patrón habitual de los servers MCP locales—. Capturas el JSON-RPC que va y viene sin que ni el cliente ni el server lo sepan.

Sobrecarga reportada: <3% CPU, comparable a Hubble en su régimen.

Cómo encaja con Hubble y Tetragon

Los tres se complementan limpiamente:

Hubble te dice: “el pod del agente abrió conexión TCP a api.anthropic.com:443 con verdict ALLOW”.
Tetragon te dice: “el proceso claude-code con PID 1843 hizo connect() a esa IP” (más el binario, los argumentos, el namespace de pod).
AgentSight te dice: “el contenido HTTPS de esa conexión era un prompt messages=[{role:'user', content:'analyze this repo and modify the firewall config'}] y la respuesta incluyó una tool call a read_file con argument /etc/passwd”.

Es la diferencia entre flujo, proceso y semántica. Para un equipo de seguridad que quiera vigilar agentes de IA en producción, los tres son necesarios. Para alguien que quiera entender el coste, los tres son útiles (Hubble para latencia de red, Tetragon para uso de recursos, AgentSight para tokens y modelo elegido).

Casos de uso emergentes

Los patrones que se están consolidando en 2026:

Audit trail de agentes: registrar cada llamada a LLM y cada tool call para compliance (sobre todo en sectores regulados).
Detección de jailbreak y prompt injection: aplicar reglas sobre los prompts capturados por AgentSight (similar a las TracingPolicy de Tetragon, pero sobre contenido semántico).
Cost accountability: ver qué team/agente consume qué tokens, sin instrumentar.
Replay y debug: reproducir el reasoning de un agente en producción sin pedirle que vuelva a ejecutar (que es no-determinístico).

Es un campo joven —AgentSight tiene meses, no años— pero el patrón “eBPF como observabilidad zero-instrumentation” está clarísimamente extendiéndose más allá de red y proceso. El próximo año va a ver consolidación y, probablemente, integración nativa con Hubble.

Casos de uso habituales de Hubble

Volviendo a Hubble propiamente, los casos en los que cualquier organización lo despliega:

1. Debug de NetworkPolicy

El uso clásico: “este pod no llega a este Service”. Sin Hubble, tocaba SSH, tcpdump, comparar reglas. Con Hubble:

hubble observe --from-pod prod-api/checkout --to-pod prod-db/postgres --verdict DROPPED

Si hay drops, ves la policy responsable (Cilium 1.19+). Si no hay drops, el problema no es policy: es DNS, routing o el target service.

2. Audit de comunicación inter-namespace

Para compliance: validar que namespaces aislados no están comunicándose contra lo declarado.

hubble observe --from-namespace prod-payments --to-namespace 'NOT prod-db' --output json

3. Detección de exfiltración

Tráfico saliente a destinos públicos sospechosos. Hubble los detecta por IP/SNI, no por payload (que está cifrado):

hubble observe --to-fqdn 'NOT *.example.com' --to-fqdn 'NOT *.internal' --protocol tcp

Combinado con métricas Prometheus y alertas en Grafana, esto da un radar de exfiltración a coste cero.

4. SLO de servicio en tiempo real

Métricas hubble:http:response_time_seconds con labels source_workload, destination_workload, method, status_code permiten dashboards SLO sin necesidad de instrumentar las apps. El SRE ve la latencia p95 de checkout → catalog directamente.

5. Performance debugging

hubble:tcp:retransmissions_total y hubble:tcp:flags_total{flag="RST"} son señales tempranas de problemas de red. Una subida correlada con regresión de latencia te apunta a algo en infraestructura (NIC, switch, MTU) antes de bajar a investigar la app.

6. Forensics post-incidente

Configurar Hubble para exportar flows a almacenamiento persistente (vía OTLP a Tempo/Loki, o hubble observe --output jsonpb a S3) te da capacidad forense: si en T+30 días detectas que algo iba mal en T, puedes reconstruir el tráfico.

Hubble y el resto del stack de observabilidad

Hubble no reemplaza Prometheus, Loki, Tempo ni Jaeger; los complementa:

Prometheus: recibe las métricas agregadas de Hubble. Hubble exporta endpoint Prometheus nativo.
Loki: recibe los flow logs estructurados si los exportas como logs. Hubble no tiene exporter nativo a Loki, pero un Fluent Bit con plugin OTLP o uno custom hace el puente fácilmente.
Tempo / Jaeger: el Cilium Operator tiene exportador OTLP de flows en formato traces (cada flujo HTTP/gRPC es un span). Integra con Tempo o cualquier otro tracing backend OTLP.
Grafana: ya hay dashboards públicos de Hubble. Combinados con Prometheus, Loki y Tempo, te dan un panel unificado: métricas, logs, traces, todo correlado por labels K8s.

La pila full-stack que se ve en producción 2026 (descrita en Building a Production eBPF Observability & Security Stack for Kubernetes in 2026):

Datos: Cilium + Hubble (red), Tetragon (proceso), AgentSight (agente IA).
Pipeline: OTLP Collector como router único.
Almacenamiento: Prometheus (métricas), Loki (logs), Tempo (traces).
UI: Grafana con dashboards específicos por dominio.
Alerting: AlertManager con reglas sobre las métricas Hubble + Tetragon.

Comparativa con alternativas

Sistema	Capa	Foco	Modelo
Hubble	L3-L7 red	Cluster K8s con Cilium	eBPF, pull metrics, push flows gRPC
GKE Dataplane v2 obs	L3-L7 red	GKE managed	eBPF (Cilium-based, gestionado)
Tigera Calico Whisker	L3-L7 red	Cluster con Calico	eBPF + pcap, UI propia
Tetragon	Proceso/syscall	Cluster K8s	eBPF, push events gRPC
Falco	Proceso/syscall	Cluster K8s	eBPF en userspace o módulo kernel
AgentSight	Agente LLM	Sistemas agentic	eBPF (SSL uprobes + stdio)
Beyla (Grafana)	Aplicación	App L7 + tracing	eBPF (uprobes en libs)
Pixie	App + sistema	Visibilidad cluster amplia	eBPF + script PXL
Parca	Profiling CPU/mem	Performance	eBPF profile sampling

Si tu CNI es Cilium, Hubble es el punto de entrada natural y no compite con los demás: complementa. Para clusters Calico, Whisker es el equivalente. Para profiling, Parca. Para agentes IA, AgentSight. La era del “una herramienta para todo” está pasando: la pila moderna combina varias piezas especializadas, todas basadas en eBPF, expuestas vía OTLP.

Trampas operativas

Cardinalidad en Prometheus

Las métricas Hubble con todos los labels K8s pueden explotar Prometheus. Mide la cardinalidad antes de exportar todo. Las métricas más prolíficas son flow y httpV2; empieza por drop y port-distribution y añade el resto incrementalmente.

L7 visibility cuesta CPU

Activar parsing L7 vía Envoy embebido añade carga al agent (no al datapath base, pero sí al envoy proxy del nodo). Para tráfico HTTP intenso, mide. Para flujos donde solo necesitas L4, deja Envoy desactivado.

Hubble Relay sin HA

Una sola réplica de Relay es un single point of failure para CLI y UI (no para el agent local, que sigue funcionando). Para producción, deploy con replicas: 2+ y topologySpreadConstraints para que no caigan ambas.

Encryption status reporting depende de Cilium config

El nuevo filtro --encryption-status solo da datos reales si Cilium tiene encryption activado (WireGuard o IPsec). Sin esto, todo es unencrypted y el filtro no aporta.

UI expuesta sin auth

Hubble UI no tiene auth nativa. Si la expones por Ingress, delante tiene que haber autenticación: OIDC vía oauth2-proxy, mTLS, IP allowlist. No es opcional.

Storage no escalado

Si guardas flows durante días para forensics, el volumen es serio. Para un cluster de 100 pods activos, fácilmente 1-10 GB/día de flow logs. Plantea el ciclo de vida (compactación, retención, cold storage) antes de habilitarlo.

Lo que no hemos cubierto

Mesh / multi-cluster Hubble: agregar flows de varios clusters Cilium en una sola Relay. Caso de uso: visión cross-cluster, debug de service mesh distribuido.
hubble export: persistencia local en disco del agent para forensics con baja retención.
Anomaly detection con modelos propios: cómo conectar el stream gRPC a un consumer ML personalizado.
AgentSight en profundidad: el proyecto merece su propio artículo. Próxima entrega.
eBPF para profiling de LLM serving: cómo medir TTFT, TPOT y throughput de vLLM sin instrumentar, usando uprobes en libcudart.

Referencias

Hubble y Cilium:

Hubble GitHub — repo principal.
Hubble — Network Observability (Cilium docs) — referencia oficial.
Cilium 1.19 release notes (InfoQ, feb 2026) — décimo aniversario y novedades 1.19.
Cilium releases — todos los releases.
Hubble L7 HTTP Metrics — Grafana dashboard 19423 — listo para importar.
End‑to‑end L7 Visibility with Cilium Hubble (cloud-cod.com, mar 2026).
Cilium Hubble Observability Platform Internal Analysis (Young-ju).
CiliumNetworkPolicy Python Hubble: L7 Visibility 2026 — uno de los hilos del SDK Python.

Estado del arte 2026 y stack completo:

eBPF + agentes IA:

AgentSight (GitHub eunomia-bpf) — el proyecto referenciado.
Harnessing eBPF for High‑Performance LLM Workloads (Klizo Solutions).

Cross-references:

Parte 1: eBPF de cero a Cilium.
Parte 2: Tetragon: el primo de seguridad de Cilium.
Serie de inferencia LLM: KV cache, vLLM en K8s, PagedAttention, Operators LLM K8s — donde el tráfico que Hubble observa lleva los prompts que AgentSight inspecciona.

Tetragon: el primo de seguridad de Cilium que ve cada syscall en el kernel

Tue, 19 May 2026 05:00:00 +0200

TL;DR

Tetragon es el motor de seguridad y observabilidad de runtime que el proyecto Cilium publicó como complemento al CNI. Su trabajo no es enrutar paquetes —para eso ya está Cilium— sino observar lo que pasa dentro de los procesos del nodo en tiempo real: qué binario se ejecuta en cada pod, qué archivos abre, qué syscalls invoca, qué capabilities pide, qué conexiones de red establece, qué módulos del kernel se cargan. Lo hace cargando programas eBPF en los hook points del kernel (kprobes, tracepoints, uprobes, LSM hooks) y filtrando los eventos relevantes dentro del propio kernel con un lenguaje declarativo expresado como CRD (TracingPolicy y TracingPolicyNamespaced). El resultado es un flujo de eventos enriquecidos con metadata Kubernetes (pod, namespace, labels) que cuesta menos del 1% de CPU y, lo que diferencia a Tetragon de la competencia, puede bloquear acciones dentro del kernel —matar el proceso con SIGKILL o sobrescribir el retorno de un syscall— antes de que terminen de ejecutarse, sin race conditions. Frente a Falco (que parsea syscalls en userspace, 5-10% overhead, detection-only), Tetragon es “más barato y con enforcement”; frente al kernel desnudo, es “una capa declarativa que tu compañero de operaciones puede leer”. Este artículo es la introducción extensa que necesitas para abordarlo en serio: arquitectura, todos los hooks y selectors, los modos de operación, una guía de casos de uso (auditoría de exec, acceso a archivos sensibles, container escape, cryptomining, detección de rootkits, observabilidad de red) y las trampas que se ven en producción.

Este artículo es la parte 2 de la serie sobre eBPF. La parte 1 —eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP— cubrió eBPF básico, los hooks de networking (XDP, TC, sock_ops), cómo Cilium implementa el datapath y los CRDs del BGP Control Plane v2. Aquí cogemos esos mismos hooks de eBPF y los usamos para algo distinto: observar y, si hace falta, frenar lo que hacen los procesos del cluster.

La analogía: auditd con esteroides en eBPF

Quien lleve unos años administrando Linux ha usado auditd. Es el subsistema clásico del kernel para auditar syscalls: configuras una regla con auditctl (por ejemplo, “monitoriza cualquier open sobre /etc/shadow”) y el kernel envía eventos a un daemon en userspace que los persiste. Funciona, pero tiene dos limitaciones que pesan en clusters Kubernetes modernos:

Sin contexto Kubernetes. auditd reporta procesos por PID y UID. Saber qué pod, qué namespace, qué imagen, qué labels —la información que de verdad importa para responder a un incidente— requiere correlar a posteriori con datos de cri-o o containerd. Es operacionalmente miserable.
Sin enforcement granular. auditd puede generar eventos, pero no puede tomar la decisión de matar el proceso ofensor antes de que termine la syscall. Eso lo dejas a una capa superior que lee los eventos, los procesa y mata el proceso… si llega a tiempo. Carrera por design.

Tetragon es auditd con esteroides: las mismas ideas conceptuales —hooks en syscalls, eventos a userspace— pero implementadas con eBPF moderno, con filtrado dentro del kernel para no pagar el coste de despertar el daemon por cada syscall irrelevante, con metadata Kubernetes inyectada por un agente que conoce el cluster, y con acciones que se ejecutan dentro del propio kernel sin esperar a que userspace decida. Si la regla dice “mata cualquier proceso que abra /etc/shadow desde el namespace prod”, la decisión se toma en el kprobe del kernel y SIGKILL se entrega antes de que el open se complete. No hay race; no hay ventana entre detección y acción.

Qué es Tetragon, arquitectónicamente

Tetragon es un agent que se despliega como DaemonSet (un pod por nodo) y un conjunto de CRDs que definen las políticas a aplicar. El agent tiene cuatro responsabilidades:

Cargar programas eBPF en los hook points que las TracingPolicies activas demanden.
Mantener un cache de metadata Kubernetes (pods, namespaces, labels) leyendo el API server, para poder enriquecer cada evento con el contexto correcto.
Recolectar los eventos que los programas eBPF emiten (vía ring buffers) y serializarlos.
Exportar los eventos a destinos configurables: stdout JSON (típico en sidecars o agentes log-collection), gRPC streaming (para consumirlos desde Hubble u otro consumer), archivo, o Fluentd/Loki/SIEM.

Los programas eBPF no son escritos por el usuario. Tetragon genera el bytecode a partir de las TracingPolicies: lee la política declarativa, decide qué hooks atacar, qué argumentos leer del kernel, qué filtros aplicar en línea y qué acciones ejecutar. El usuario solo escribe YAML.

Esta separación policy declarativa → bytecode eBPF generado es lo que hace a Tetragon usable. Escribir programas eBPF a mano es trabajo de un especialista; escribir una TracingPolicy es trabajo de un SRE con un buen ejemplo a la vista.

Los dos CRDs: TracingPolicy y TracingPolicyNamespaced

Tetragon expone exactamente dos CRDs principales:

TracingPolicy (cluster-scoped, cilium.io/v1alpha1): se aplica a todo el cluster, todos los nodos, todos los pods. Adecuada para políticas de plataforma (todo el cluster debe ser auditado igual): por ejemplo, “registra todo execve en todos los pods” o “mata cualquier proceso que intente cargar un módulo del kernel”.
TracingPolicyNamespaced (namespaced, mismo grupo y versión): se define dentro de un namespace y solo se aplica a los pods de ese namespace. Adecuada para políticas con autonomía por tenant: por ejemplo, “en el namespace prod-payments, mata cualquier connect saliente a una IP fuera del rango corporativo”.

Ambos CRDs tienen exactamente la misma estructura interna. La diferencia es de scope. La distinción se introdujo precisamente para permitir multi-tenancy: que el equipo de seguridad central defina políticas TracingPolicy cluster-wide y que cada tenant pueda añadir las suyas con TracingPolicyNamespaced sin necesitar permisos cluster-admin.

Anatomía de una TracingPolicy

Una política se compone de:

Hook points: qué eventos del kernel observar.
Argumentos: qué datos leer cuando el hook se dispara.
Selectors: filtros que se evalúan dentro del kernel para descartar eventos no relevantes y, opcionalmente, ejecutar acciones cuando coinciden.

Hook points soportados

La documentación oficial enumera cinco familias de hook points:

kprobes: hookean una función del kernel. Las syscalls son un caso particular (cuando syscall: true) porque su ABI es distinta del de las funciones internas. Ejemplos típicos: sys_open, sys_openat, sys_connect, tcp_connect, do_mount, commit_creds. Es el hook más versátil y el que se usa el 80% del tiempo.
tracepoints: hookean tracepoints estáticos compilados en el kernel. Más estables entre versiones de kernel que los kprobes (no dependen de nombres de funciones que pueden cambiar). Ejemplos: syscalls/sys_enter_openat, sched/sched_process_exec.
uprobes: hookean funciones de bibliotecas o binarios en userspace. Sirven para observar primitivas de runtime como funciones de libssl, libc, Go runtime, JVM.
tracepoints USDT (User Statically Defined Tracepoints): tracepoints estáticos definidos en binarios userspace (como los que MySQL, PostgreSQL, OpenJDK exponen). Útiles para observabilidad de aplicaciones.
lsmHooks (LSM, Linux Security Module): hooks del subsistema LSM, donde se enchufa SELinux/AppArmor. Permiten políticas de seguridad muy similares a las de MAC tradicional pero programables con eBPF. Ejemplo: file_open, inode_unlink, socket_bind.

Argumentos

Cada hook puede leer los argumentos de la función a la que está atado. Los tipos soportados cubren los primitivos (int, uint64, bool, string, char_buf) y abstracciones más altas (file, path, sock, linux_binprm, capability, bpf_attr, cred). Los tipos altos son punteros a estructuras del kernel que Tetragon sabe parsear; en lugar de tener que leer un offset, escribes type: file y Tetragon te da el path completo del archivo del descriptor.

Hay un detalle importante de capacidad: en kernels ≥ 5.4, Tetragon puede leer hasta 327 360 bytes de un argumento si se activa el flag de buffers grandes. Es la diferencia entre poder auditar execve con todos sus argv largos completos vs truncarlos a 256 bytes y perder contexto.

Selectors: filtrado en el kernel

Los selectors son lo que hace a Tetragon barato. Sin ellos, cada syscall del nodo dispararía un evento que viajaría kernel → ring buffer → agent → procesado → filtrado → descartado. Con selectors, el filtrado ocurre dentro del propio programa eBPF, en el kernel, y solo los eventos que importan llegan al userspace.

Los selectors disponibles incluyen:

matchArgs: filtra por el valor de un argumento. Operadores: Equal, NotEqual, Prefix, Postfix, GreaterThan, LessThan, Mask, SPort (source port), DPort (dest port), Family (AF_INET vs AF_INET6), State (estado del socket).
matchPIDs: filtra por PID; útil para targeted observation.
matchBinaries: filtra por el binario que ejecuta el syscall (path absoluto), con Operator: In, NotIn, Prefix. Imprescindible para evitar el ruido de procesos legítimos del sistema.
matchNamespaces: filtra por namespace Linux (Pid, Mnt, Net, Ipc, Cgroup, User). Permite políticas específicas para procesos en contenedores vs el host.
matchCapabilities: filtra por capabilities efectivas del proceso. Bloquear acciones que requieran CAP_SYS_ADMIN que se ejecuten en pods que no deberían tenerlas.
matchNamespaceChanges: detecta cambios de namespace (típico de container escape).
matchCapabilityChanges: detecta cambios de capabilities (escalada de privilegios).
matchActions: las acciones que se ejecutan cuando todos los matchers anteriores aciertan.

Acciones: del simple Post al Sigkill

Cuando un selector matchea, se ejecuta una action. Tetragon define varias:

Post: emite un evento al userspace (el caso de observability). Soporta rateLimit para evitar inundar el agent si la condición se dispara mil veces por segundo. La sintaxis acepta 5 para 5 segundos, 5m para 5 minutos, 1h para 1 hora.
Sigkill: envía SIGKILL al proceso ofensor desde dentro del kernel, antes de que la syscall complete. Esto es lo único que garantiza enforcement sin race.
Override: sobrescribe el valor de retorno del syscall. Útil para hacer creer al proceso que el syscall falló (Override -EPERM) sin matarlo. Mejor experiencia para apps que pueden manejar errores; peor para apps que asumen éxito.
Signal: envía cualquier señal arbitraria (no solo SIGKILL).
NoPost: no emite evento, útil cuando se combina con otro selector que sí emite y solo quieres acción sin telemetría duplicada.
FollowFD y UnfollowFD: marcan un file descriptor para seguir su ciclo de vida y enriquecer eventos siguientes con el path original. Útil para audit de “qué proceso leyó este archivo después de abrirlo”.
TrackSock y UntrackSock: idem para sockets.
GetUrl y DnsLookup: hacen peticiones HTTP o resoluciones DNS desde el kernel. Pensado para integraciones con sistemas externos (webhooks de seguridad, lookups de reputación de IP).
NotifyEnforcer y CleanupEnforcerNotification: comunicación con el subsistema de enforcement de Tetragon para acciones complejas.

Modos: detection vs enforcement

Una política se puede declarar en uno de dos modos explícitos:

enforce: las acciones de enforcement (Sigkill, Override, Signal) están activas. Esto es producción.
monitoring: las acciones de enforcement son ignoradas; solo se emiten eventos Post. Esto es el modo “vamos a ver qué pasaría si esto estuviese activado”, crítico para probar políticas sin romper aplicaciones.

El control se hace con el campo spec.options[].name: policy-mode y value: monitoring o enforce. Es la mejor práctica: empezar en monitoring, recolectar eventos durante días, ajustar los selectors hasta que no salgan falsos positivos, y entonces cambiar a enforce.

Ejemplo completo: bloquear escrituras a `/etc/passwd` en namespace prod

Una política realista, comentada línea a línea:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: block-passwd-write
 namespace: prod
spec:
 kprobes:
 - call: "fd_install"
 syscall: false # función del kernel, no syscall
 args:
 - index: 0
 type: int  # file descriptor
 - index: 1
 type: "file" # struct file*
 selectors:
 - matchArgs:
 - index: 1
 operator: "Equal"
 values:
 - "/etc/passwd"
 matchActions:
 - action: Sigkill  # mata el proceso
 rateLimit: "1m" # max una vez por minuto
 options:
 - name: policy-mode
 value: enforce  # modo enforcement activo

fd_install se ejecuta cada vez que un proceso obtiene un nuevo file descriptor; el segundo argumento es la struct file del archivo. Tetragon sabe resolverla a su path absoluto. El matchArgs compara ese path con /etc/passwd. Si matchea, Sigkill mata el proceso antes de que el descriptor llegue siquiera a ser usable. rateLimit: 1m impide que el agent se sature si una aplicación malintencionada lo intenta en bucle.

Casos de uso habituales

Vamos al uso real. Estos son los seis casos que aparecen en cualquier despliegue serio de Tetragon en 2026.

1. Auditoría de ejecución (`execve`)

El caso de uso más básico y, sin embargo, el más valioso. ¿Qué binarios se están ejecutando en cada pod? En un container que se supone que corre solo nginx, ver de pronto un sh o un wget es bandera roja casi siempre.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: audit-execve
spec:
 tracepoints:
 - subsystem: "sched"
 event: "sched_process_exec"
 args:
 - index: 4
 type: linux_binprm  # struct linux_binprm*
 selectors:
 - matchActions:
 - action: Post  # solo eventos, no enforcement

Sin filtros: cada execve del cluster genera un evento. Con metadata K8s, el evento incluye pod, namespace, container, imagen, labels. Lo conviertes en flujo de eventos hacia tu SIEM y montas reglas: “alerta si veo sh, bash, nc, curl, wget, python ejecutándose en cualquier pod del namespace prod-api”.

Variación con enforcement: en lugar de Post, usar matchBinaries con Operator: NotIn y una whitelist, y Sigkill si el binario no está en la lista. Caja muy rígida pero efectiva en pods que son “single-binary” (como un microservicio Go).

2. Acceso a archivos sensibles

Detectar (o bloquear) lecturas y escrituras a archivos críticos: /etc/shadow, /etc/kubernetes/, montajes de Secrets, /var/run/docker.sock, /proc/*/cmdline.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: sensitive-file-access
spec:
 kprobes:
 - call: "security_file_open" # LSM-ish via kprobe
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Prefix"
 values:
 - "/etc/shadow"
 - "/var/run/secrets/"
 - "/var/run/docker.sock"
 matchBinaries:
 - operator: "NotIn"
 values:
 - "/usr/bin/kubelet" # acceso legítimo de kubelet
 matchActions:
 - action: Post

El matchBinaries: NotIn es importante: kubelet y otros agentes legítimos del nodo acceden a estos paths constantemente y generarían ruido. Filtramos esos en el kernel.

En enforcement: cambiar Post por Override con argError: -1 (EPERM), de modo que la apertura falle pero el proceso ofensor siga vivo y produzca el error para que las herramientas de tracing lo recojan.

3. Conexiones de red salientes no autorizadas

Detectar conexiones outbound a destinos fuera del rango corporativo. Útil para detectar exfiltración de datos o command-and-control de malware.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: block-external-egress
 namespace: prod
spec:
 kprobes:
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchArgs:
 - index: 0
 operator: "NotDAddr" # destino NO en estos CIDRs
 values:
 - "10.0.0.0/8"
 - "192.168.0.0/16"
 - "172.16.0.0/12"
 matchActions:
 - action: Sigkill
 options:
 - name: policy-mode
 value: enforce

Esto mata cualquier intento de conexión TCP a una IP que no esté en los CIDRs corporativos, en namespace prod. Cilium ya hace esto con NetworkPolicy, pero Tetragon tiene dos ventajas complementarias:

Te da el proceso que intentó la conexión, no solo “el pod X intentó conectar a Y”.
Funciona también para protocolos exóticos donde NetworkPolicy es menos expresiva.

4. Detección de container escape

Container escape es la pesadilla operacional: un proceso dentro de un contenedor consigue romper el aislamiento (vía un kernel exploit, una capability mal puesta, un mount hostPath mal configurado) y obtener acceso al host. Tres señales típicas:

Cambio de namespace del proceso (sale del namespace pid del contenedor).
setns o unshare en procesos no-init.
Acceso a /proc/1/root o /dev/ desde un contenedor.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: detect-container-escape
spec:
 kprobes:
 - call: "__x64_sys_setns"
 syscall: true
 args:
 - index: 0
 type: int
 - index: 1
 type: int
 selectors:
 - matchNamespaces:
 - namespace: Pid
 operator: NotIn
 values: ["host_ns"] # solo procesos NO en pid namespace del host
 matchActions:
 - action: Sigkill
 - call: "__x64_sys_unshare"
 syscall: true
 args:
 - index: 0
 type: int
 selectors:
 - matchNamespaceChanges:
 - unshare: true
 matchActions:
 - action: Post

__x64_sys_setns con destino el namespace del host desde un proceso en contenedor es prácticamente siempre malicioso (los containers legítimos no necesitan esto en runtime).

5. Cryptomining

Los procesos de minería tienen perfiles bastante reconocibles:

Procesos con nombres como xmrig, minerd, cgminer, o procesos legítimos como python ejecutando scripts con uso intensivo de CPU.
Conexiones outbound a pools de minería conocidas (lista pública de IPs y dominios).
Uso anómalo de /dev/cpu_dma_latency para evitar throttling.

Una política combinada:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: detect-cryptomining
spec:
 tracepoints:
 - subsystem: "sched"
 event: "sched_process_exec"
 args:
 - index: 4
 type: linux_binprm
 selectors:
 - matchArgs:
 - index: 4
 operator: "Postfix"
 values:
 - "/xmrig"
 - "/minerd"
 - "/cgminer"
 matchActions:
 - action: Sigkill
 kprobes:
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchArgs:
 - index: 0
 operator: "DPort"
 values: ["3333", "5555", "7777", "14444"] # puertos comunes de pools
 matchActions:
 - action: Post  # solo registra

La doble política: matar binarios con nombres clásicos (cinturón) y registrar conexiones a puertos de pools (tirantes), para alertar también cuando alguien renombre xmrig a nginx-helper o use puertos exóticos.

6. Detección de rootkits y módulos del kernel sospechosos

Los rootkits modernos cargan módulos del kernel para parchear funciones (hide procesos, hide conexiones de red, esconder archivos). Detectarlos:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: kernel-module-load
spec:
 kprobes:
 - call: "do_init_module"
 syscall: false
 args:
 - index: 0
 type: "string"
 selectors:
 - matchActions:
 - action: Post
 - call: "security_kernel_read_file"
 syscall: false
 args:
 - index: 0
 type: "file"
 - index: 1
 type: int
 selectors:
 - matchArgs:
 - index: 1
 operator: "Equal"
 values: ["READING_MODULE"]
 matchActions:
 - action: Post

En un cluster Kubernetes “bien configurado” no se cargan módulos nuevos del kernel en runtime; cualquier evento aquí es altamente sospechoso. Combina con enforcement para máquinas donde los módulos deberían estar fijos: Sigkill al que intenta cargar uno.

Bonus: detección de modificación de eBPF maps por terceros

Como tendencia 2025-2026: cargar programas eBPF maliciosos para esconder presencia. Tetragon puede observar el bpf syscall:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: audit-bpf-syscalls
spec:
 kprobes:
 - call: "__x64_sys_bpf"
 syscall: true
 args:
 - index: 0
 type: int  # bpf cmd
 - index: 1
 type: bpf_attr
 selectors:
 - matchBinaries:
 - operator: "NotIn"
 values:
 - "/usr/bin/cilium-agent"
 - "/usr/bin/tetragon"
 - "/usr/bin/bpftool"
 matchActions:
 - action: Post

Cualquier proceso que no sea uno de los agentes legítimos cargando programas eBPF: te interesa saberlo.

Comparativa con Falco

Falco es el competidor más cercano: también es runtime security para Kubernetes, también basado originalmente en eBPF (y antes en kernel modules), también con políticas declarativas. Tres años atrás eran funcionalmente parecidos. En 2026 la divergencia es clara:

Dimensión	Tetragon	Falco
Filosofía	Cilium-native, integrado	Standalone, genérico
Filtrado	En el kernel (eBPF)	Parsing en userspace
Overhead típico	<1% CPU	5-10% CPU
Enforcement	Sí, in-kernel (Sigkill, Override)	No nativo (depende de plugins)
Race conditions	No (acción atómica con syscall)	Sí en enforcement vía plugins
Detección de falsos positivos	Baja (contexto K8s en kernel)	Más alta (parsing posterior)
Latencia de detección	5-26 ms	~10 ms (más constante)
Madurez del ecosistema	Joven, en crecimiento	Maduro, mucho material
Comunidad	Cilium / CNCF Incubating	CNCF Graduated
Integraciones	Hubble nativo	Falcosidekick, muchas
CRDs por política	TracingPolicy / Namespaced	Sin CRDs; reglas en YAML

Cuándo elegir cada uno:

Tetragon si ya usas Cilium, si necesitas enforcement en el kernel (no detection-only), si el overhead te importa (cargas con muchas syscalls), y si valoras la integración con Hubble. Detección de container escape y cryptomining es donde más se mide su ventaja sobre Falco.
Falco si quieres una herramienta independiente del CNI, si necesitas el catálogo de reglas pre-hechas y la comunidad amplia, si tu cluster no es Cilium, o si la integración con SIEMs y notificadores ya hechos (Falcosidekick) te ahorra trabajo.
Los dos si la organización es grande: Falco para amplitud de detección, Tetragon para enforcement quirúrgico en cargas críticas. Es lo que más se ve en empresas que llevan años con Falco y añaden Tetragon para casos específicos.

Hubble + Tetragon: observabilidad unificada

Hubble es el componente de observabilidad de tráfico de Cilium: muestra flow logs L3-L7 con cero impacto en latencia. Tetragon expone sus eventos por gRPC con el mismo formato y vocabulario que Hubble, lo que permite:

Verlos en la misma UI (Hubble UI muestra eventos Tetragon como una “capa” más).
Correlar eventos de red (Hubble) con eventos de proceso (Tetragon) en el mismo timeline.
Exportarlos juntos a Loki/Tempo/SIEM como un flujo único.

La sinergia clave: Hubble te dice “este pod hizo una conexión TCP a 1.2.3.4:80”. Tetragon te dice “este pod ejecutó curl 1.2.3.4 desde un binario bash lanzado por pid 1234”. Juntos te dan la historia completa.

Despliegue y operación

Helm

Instalación canónica con Helm:

helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon \
 --namespace kube-system \
 --set tetragon.exportFilename=/var/log/tetragon/tetragon.log \
 --set tetragon.exportFileMaxSizeMB=50 \
 --set tetragon.exportFileRotationInterval=24h

Tetragon despliega su DaemonSet, sus CRDs y un service para Hubble. Por defecto, expone los eventos en stdout del pod del agent (los recoge cualquier log aggregator del cluster).

CLI `tetra`

Tetragon trae una CLI llamada tetra para investigación interactiva:

# stream en tiempo real de eventos del nodo
tetra getevents -o compact --pods <pod-name>

# events JSON estructurado para procesar con jq
tetra getevents -o json --since 5m --namespace prod

# ver políticas cargadas
tetra tracingpolicy list

Es la mejor herramienta para depurar políticas en monitoring antes de pasarlas a enforce.

Exportar a SIEM

Tres rutas habituales:

stdout + log aggregator: el agent escribe JSON al stdout, Fluent Bit/Vector lo recoge y lo envía a Splunk/Datadog/Elastic. Simple, funciona con cualquier infraestructura de logging.
gRPC streaming: para integraciones de baja latencia. Un consumer gRPC propio o Hubble Relay.
Archivo + rotación: para entornos air-gapped o auditorías regulatorias que exigen logs persistentes con rotación controlada.

Performance

Los benchmarks publicados consistentemente sitúan a Tetragon en <1% de CPU del nodo en cargas reales, comparado con 5-10% de Falco en las mismas cargas. La razón es la separación arquitectónica: Tetragon filtra en el kernel y solo lleva a userspace los eventos que realmente importan; Falco lleva todos los syscalls a userspace y los filtra allí. En clusters con miles de pods haciendo cientos de miles de syscalls por segundo, la diferencia se nota en la factura.

Trampas operativas comunes

`monitoring` permanente

La mayor trampa es no llegar nunca a enforce: empezar bien con políticas en monitoring, recolectar eventos, ajustar selectors, y luego nunca conmutar. Resultado: tienes detection sin prevention, exactamente lo que Falco te daba sin pagar la complejidad de Tetragon. Si vas a usar Tetragon, planifica el camino a enforce de las políticas críticas.

Selectors demasiado laxos

Una política con un único matchActions: Post sin selectors específicos genera eventos por cada syscall del hook elegido. En un nodo serio son decenas de miles por segundo, que llenan logs, saturan exporters y esconden la señal en el ruido. Empieza siempre con filtros estrictos (matchBinaries, matchNamespaces, matchPIDs) y abre cuando sepas qué buscas.

Kernel demasiado viejo

Tetragon necesita features de eBPF modernas. Kernels < 5.4 no tienen el soporte de buffers grandes (necesario para execve con argv completos). Kernels < 5.10 no tienen muchos de los hooks LSM. Kernel 5.15+ es el mínimo recomendado para producción y 6.1+ para tener todas las features.

Hooks en funciones del kernel renombradas

Los kprobes están atados a nombres de funciones del kernel que pueden cambiar entre versiones. Una política que use __x64_sys_setns puede fallar silenciosamente en un kernel donde la función se llama __do_sys_setns. Soluciones: usar tracepoints estáticos cuando estén disponibles (más estables), o tener políticas alternativas con varios call por compatibilidad.

`Sigkill` en namespaces críticos

Aplicar Sigkill a procesos en kube-system o cilium-system puede romper el cluster. Las políticas de enforcement deben excluir explícitamente los namespaces de plataforma con matchNamespaces Operator: NotIn, o limitar el scope con TracingPolicyNamespaced para asegurar que no acciona en sistemas que no debe.

`rateLimit` ausente

Una política sin rateLimit en Post puede sufrir un fan-out catastrófico si la condición se cumple millones de veces en un instante (típico en bucles de ataque o en bugs de aplicación). El agent se satura, los eventos se pierden, los logs se desbordan. Pon siempre rateLimit sensato en políticas de detección, especialmente en hooks de alta frecuencia como tcp_connect o execve.

Lo que no hemos cubierto (próximos artículos)

eBPF LSM hooks en profundidad: cómo se relacionan con SELinux/AppArmor y cuándo Tetragon es la herramienta correcta vs MAC clásico.
Hubble UI con Tetragon overlay: configuración de la UI para mostrar la observabilidad de proceso y la de red en el mismo timeline.
Integración con OPA/Kyverno: cómo Tetragon complementa policy engines de admission (Kyverno valida en admission; Tetragon valida en runtime).
Forensics con eBPF: combinando Tetragon con herramientas como Beyla u OpenTelemetry para trazar la cadena completa de un incidente desde la conexión inicial hasta la syscall final.

Referencias

Documentación oficial (mayo 2026):

Tetragon — sitio oficial — punto de entrada.
Tetragon docs — Tracing Policy — referencia conceptual.
Tetragon docs — Hook points — kprobes, tracepoints, uprobes, LSM, USDT.
Tetragon docs — Selectors — referencia completa de filtros.
Tetragon docs — Enforcement Mode.
Tetragon docs — Kubernetes Identity Aware Policies — TracingPolicyNamespaced.
Tetragon GitHub.

Comparativas y análisis:

Comparative Analysis of eBPF-Based Runtime Security Monitoring (paper SciTePress 2025) — benchmark con números independientes.
Best eBPF Security Solutions for Kubernetes (ARMO, 2026) — comparativa Falco vs Tetragon vs KubeArmor.
Falco vs. Tetragon (Asim Mirza, Medium) — análisis con casos de uso.
Deep Dive into Tetragon (A Security Engineer) — recorrido por dentro del agente.
Tetragon Series, Part 2: Enforcing Sensitive File Access (Medium).

Ecosistema:

Cilium Hubble — observabilidad de red.
Falco — sitio oficial — el otro grande del campo.
KubeArmor — la tercera opción, con AppArmor + eBPF.

Cross-references:

Parte 1 de la serie: eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP — los fundamentos de eBPF que aquí damos por leídos.
Kubernetes con Cilium BGP: servicios accesibles sin Ingress — punto de partida del ecosistema Cilium en este blog.

eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP

Tue, 19 May 2026 04:30:00 +0200

TL;DR

eBPF es una máquina virtual sandboxed dentro del kernel Linux que ejecuta código verificado en hooks bien definidos: kprobes, tracepoints, socket events, drivers de red. Antes de eBPF, modificar el comportamiento del kernel era recompilarlo o cargar un módulo arbitrario; con eBPF, cargas un programa pequeño que pasa un verificador formal y se ejecuta a velocidad nativa con seguridad de memoria. En networking, esto se traduce en que el paquete no tiene que recorrer la pila TCP/IP tradicional: un programa eBPF en el driver de la NIC (XDP) puede dropear, reenviar o reescribir el paquete antes de que el kernel haya hecho su primer alloc; un programa en cgroup hooks (sock_ops) puede redirigir conexiones a otro socket sin que el paquete llegue siquiera a salir de la máquina. Cilium es el CNI que ha llevado esto a su conclusión lógica: reemplaza kube-proxy por eBPF puro (O(1) en lugar de O(N) de iptables), enruta pod-a-pod sin VXLAN cuando puede, evalúa Network Policies con BPF maps, y desde 1.16 ha rehecho su control plane de BGP con un set nuevo de CRDs —CiliumBGPClusterConfig, CiliumBGPPeerConfig, CiliumBGPAdvertisement, CiliumBGPNodeConfigOverride— que sustituyen al monolítico CiliumBGPPeeringPolicy que ya está deprecado. Este artículo baja por las tres capas (eBPF básico → eBPF networking → Cilium) y termina con los CRDs operativos.

La analogía: plugins firmados para el kernel

Imagina el navegador. Hace 20 años, extender un navegador significaba compilar un binario nativo y cargarlo: cualquier extensión podía estrellarlo, corromper memoria, leer cookies del banco. Hoy, las extensiones son JavaScript en una sandbox con un manifest que declara permisos, un runtime que aplica el aislamiento y una tienda que firma el código. La extensión no toca el binario del navegador; vive en un mundo controlado y solo puede hablar con el navegador a través de APIs definidas. Resultado: extensibilidad masiva con superficie de ataque acotada.

eBPF es exactamente eso para el kernel Linux. Cargar un módulo .ko clásico es cargar código nativo con acceso total a memoria del kernel: un bug y se va el sistema. eBPF es una VM bytecode con verificador estático, allocator controlado, JIT al hardware nativo después de pasar el verificador, y un set de “helpers” del kernel a los que puede llamar. El programa eBPF puede leer la memoria del kernel donde el verificador le permite leer, y solo eso. No puede entrar en loops infinitos (el verificador exige que termine). No puede saltar a direcciones arbitrarias. No puede dereferenciar punteros sin haberlos validado primero. Y, lo más importante: es código de usuario, cargado en runtime, que ejecuta dentro del kernel a velocidad nativa.

Las consecuencias se notan a kilómetros. Antes, observar tráfico en producción significaba parchear el kernel o cargar un módulo de riesgo. Hoy, bpftrace -e 'tracepoint:net:net_dev_xmit { @[args->dev->name] = count(); }' te da un histograma de paquetes por interfaz en tres líneas y cero downtime. Antes, sustituir iptables por algo más rápido implicaba reescribir el subsistema de netfilter. Hoy, Cilium carga 60 KB de bytecode eBPF en XDP y desbanca a iptables con un map de hashes.

eBPF básico: qué es y qué no es

El origen y el alcance

El nombre viene de Berkeley Packet Filter, una idea de 1992 (McCanne y Jacobson) para filtrar paquetes con un mini-bytecode que tcpdump usaba internamente. En 2014, Alexei Starovoitov lo rebautizó como eBPF y lo extendió enormemente: 11 registros de 64 bits en lugar de 2 de 32, stack de 512 bytes, mapas como estructuras compartidas con userspace, JIT al hardware nativo, y un verificador formal mucho más sofisticado. De ser un filtro de paquetes, pasó a ser un mecanismo de extensibilidad genérico del kernel.

Hoy eBPF se usa para cuatro cosas:

Networking: XDP, TC, cgroup hooks, socket ops, lightweight tunnels.
Observabilidad: kprobes, uprobes, tracepoints, USDT. La base de proyectos como bpftrace, bcc, Pixie, Parca.
Seguridad: BPF LSM (Linux Security Module en eBPF), bloqueos de syscall con seccomp-bpf. Falco, Tetragon, Tracee.
Scheduling: sched_ext (kernel 6.12+), schedulers de procesos completamente en eBPF. Aún en fase muy temprana.

La VM

Un programa eBPF se compila desde C (o Rust, Go con cilium/ebpf) a bytecode eBPF, no a x86/arm64 directamente. El loader del kernel (vía syscall bpf()) pasa ese bytecode por el verificador:

Reconstruye el grafo de control de flujo.
Hace análisis estático de cada path posible: cada instrucción tiene que ser alcanzable, cada acceso a memoria tiene que estar dentro de bounds conocidos, cada puntero tiene que haber sido validado.
Rechaza loops sin un upper bound conocido. Los kernels recientes admiten loops acotados (bpf_loop helper), pero el contador siempre es finito.
Rechaza llamadas a helpers o kfuncs que el program type del hook no permita.

Si el verificador acepta el programa, el JIT lo traduce a código nativo del host (x86, arm64, etc.) y queda atado a su hook. A partir de ahí se ejecuta cada vez que el evento del hook ocurre, sin context switch a userspace, sin coste de syscall. Latencias del orden de cientos de nanosegundos por invocación.

Maps: el puente con userspace

Un programa eBPF aislado no sirve de mucho. Lo que lo hace útil son los maps: estructuras de datos compartidas entre el programa kernel y el espacio de usuario. Hay varios tipos:

BPF_MAP_TYPE_HASH, BPF_MAP_TYPE_LRU_HASH: hash tables con o sin desalojo LRU.
BPF_MAP_TYPE_ARRAY, BPF_MAP_TYPE_PERCPU_ARRAY: arrays, opcionalmente per-CPU para evitar contención.
BPF_MAP_TYPE_RINGBUF, BPF_MAP_TYPE_PERF_EVENT_ARRAY: canales para enviar eventos a userspace en streaming.
BPF_MAP_TYPE_PROG_ARRAY: arrays de programas eBPF para tail calls (encadenamiento de programas sin volver al kernel base).

Userspace lee y escribe estos maps vía syscalls bpf(); el programa kernel los lee y escribe directamente. Es la base de cualquier sistema eBPF: el programa kernel recoge datos en un map, el daemon en userspace los lee. Cilium hace exactamente esto: el agente userland (Go) gestiona la política y la traduce a entradas en maps; los programas eBPF que viven en XDP/TC leen los maps y aplican las decisiones.

CO-RE: compila una vez, corre en cualquier kernel

Una pesadilla clásica de los módulos de kernel: están atados a la versión exacta del kernel donde se compilaron. Distribuir un módulo precompilado para un parque de máquinas con distintas distros era imposible.

eBPF resuelve esto con CO-RE (Compile Once, Run Everywhere): el bytecode incluye relocaciones que el loader resuelve en cada kernel concreto consultando BTF (BPF Type Format), una representación del layout de las structs del kernel que el propio kernel publica. Resultado: un único binario eBPF funciona en kernels 5.10, 5.15, 6.1 y 6.8 sin recompilar, porque el loader ajusta los offsets de acceso a structs en runtime.

Esto es lo que ha permitido que distribuciones eBPF productivas existan. Sin CO-RE, cada kernel sería un proyecto de portado.

eBPF en networking: los hooks que importan

Dentro del subsistema de red de Linux, eBPF tiene varios hooks. Los relevantes para CNIs:

XDP — eXpress Data Path

XDP es el hook más temprano: se ejecuta en el driver de la NIC, antes de que el paquete entre en el kernel propiamente. No hay sk_buff (la struct que el resto del kernel usa para representar paquetes); solo hay un puntero a un buffer de RAM con los bytes recibidos.

Las acciones que un programa XDP puede devolver:

XDP_DROP: tirar el paquete inmediatamente. El driver lo deja caer y libera el buffer. Coste: nanosegundos. Caso de uso: DDoS mitigation. Cloudflare procesó más de 8 millones de paquetes/segundo por CPU con XDP para drop de SYN floods.
XDP_PASS: dejar que el paquete siga al kernel normal. Pasa a sk_buff y entra en el stack tradicional.
XDP_TX: reenviar por la misma interfaz tras posibles modificaciones. Útil para load balancers L4 que reescriben destino y devuelven.
XDP_REDIRECT: enviar el paquete a otra interfaz o a un map (para forward a userspace via AF_XDP, o a otra NIC, o a un veth de un pod).
XDP_ABORTED: error (incrementa un contador, dropea).

Casos de uso reales:

Cloudflare L3 DDoS protection: reglas XDP que drop millones de paquetes/s.
Facebook Katran: L4 load balancer que reescribe destino IP y devuelve por la misma interfaz. Maneja 10× más conexiones por servidor que IPVS clásico.
Cilium XDP acceleration: load balancing de Services en la capa más baja posible.

TC (Traffic Control) — clsact con BPF

XDP es muy rápido pero limitado: el paquete aún no tiene sk_buff y muchas decisiones (conntrack, NAT, encapsulación con metadatos) son más fáciles cuando sí lo tiene. El hook TC clsact con BPF se ejecuta después de construir el sk_buff pero antes de las decisiones de routing y netfilter. Acciones:

TC_ACT_OK: el paquete sigue por el stack.
TC_ACT_SHOT: drop.
TC_ACT_REDIRECT: redirigir a otra interfaz.
TC_ACT_PIPE, TC_ACT_STOLEN: control de pipeline para combinarse con otros qdiscs.

Casos de uso:

Network policy stateful: Cilium evalúa políticas L3-L7 en TC con sk_buff completo y conntrack disponible.
Marcado y QoS: marcado de tráfico para que el scheduler aplique prioridades.
Encapsulación overlay: añadir headers VXLAN/Geneve cuando el modo es tunnel.

XDP y TC se combinan: XDP para lo barato y temprano (DDoS, LB simple), TC para lo que necesita skb y stateful.

Cgroup hooks: sock_ops y CGROUP_SOCK_ADDR

El paso conceptual más radical: hooks que no están en la capa de red sino en la capa de socket. Tipos relevantes:

BPF_PROG_TYPE_CGROUP_SOCK_ADDR: se invoca cuando un proceso de un cgroup hace connect(), bind(), sendto(). El programa eBPF puede reescribir la dirección de destino antes de que la conexión salga. Es lo que permite a Cilium hacer load balancing de Services sin que el paquete entre en la pila de red: si el cliente intenta conectar a 10.96.0.1:443 (ClusterIP), un programa eBPF en este hook reescribe el destino a la IP real del pod backend antes de que el syscall continúe.
BPF_PROG_TYPE_SOCK_OPS: se invoca en eventos TCP (creación, establecido, retransmisión). Permite ajustar parámetros del socket en runtime y, lo más importante, emparejar sockets locales vía bpf_sk_assign para shortcut sin que el paquete viaje por la red.

Esta es la “tercera capa” del bypass: no es solo más rápido, es conceptualmente distinto. El paquete no se construye, no se serializa, no recorre IP layer ni TCP layer. Es la diferencia entre acelerar una carretera y descubrir que para algunos viajes no hace falta tomar el coche.

El camino largo: cómo es la pila TCP/IP tradicional

Para apreciar lo que eBPF ahorra, vale la pena trazar el recorrido completo de un paquete por la pila Linux. Tomemos el caso “paquete entra por una NIC, va a un proceso local”:

NIC (DMA al ring buffer del driver)
↓
driver: napi_schedule, poll, asigna sk_buff
↓
[XDP hook] ← si hay programa XDP, se decide aquí
↓
netif_receive_skb
↓
__netif_receive_skb_core
↓
[TC ingress clsact + BPF] ← si hay programa TC ingress
↓
packet_type handlers (IP, ARP...)
↓
ip_rcv → ip_rcv_core
↓
[netfilter NF_INET_PRE_ROUTING] ← iptables PREROUTING
↓
routing decision (FIB lookup)
↓
[netfilter NF_INET_LOCAL_IN] o [NF_INET_FORWARD]
↓
tcp_v4_rcv → tcp_v4_do_rcv
↓
tcp_rcv_established
↓
sk_data_ready
↓
proceso lee con recv()/read()

Cada flecha es una llamada de función con coste medible. Cada netfilter hook recorre todas las reglas iptables/nftables registradas. Con kube-proxy en modo iptables y 5 000 Services × 10 endpoints cada uno, hay del orden de 150 000 reglas que se evalúan secuencialmente en NF_INET_PRE_ROUTING. Los benchmarks publicados muestran latencias de decenas de microsegundos por paquete en clusters Kubernetes grandes solo en el paso de netfilter, antes de que la aplicación reciba nada.

Y eso es el camino normal. En el camino de salida pasa lo mismo pero en sentido inverso: tcp_sendmsg → ip_output → NF_INET_LOCAL_OUT → routing → NF_INET_POSTROUTING → dev_queue_xmit → driver → NIC.

Cómo Cilium se salta esta pila

Cilium no elimina la pila TCP/IP; sigue ahí para los casos que la necesitan. Lo que hace es shortcuts en los puntos donde duele.

Shortcut 1 — XDP para el datapath de Service

Para un cluster con 5 000 Services, kube-proxy iptables tiene un coste O(N) en evaluar reglas (incluso con iptables-restore --noflush y trucos, sigue siendo lineal en el número de chains que el paquete atraviesa).

Cilium lo sustituye así:

Cada Service y sus endpoints viven en un eBPF hash map.
Cuando entra un paquete con destino a una ClusterIP, el programa XDP de Cilium hace un lookup O(1) en ese map y obtiene el endpoint backend.
Reescribe el destino y XDP_TX (devuelve por la misma interfaz hacia el backend) o XDP_REDIRECT (lo envía a la veth del pod local correspondiente).

Esto significa que el coste no crece con el número de Services. 100 Services o 100 000, lookup constante en el map. Benchmarks publicados muestran reducciones de latencia de 30-50% en clusters con muchos Services frente a kube-proxy iptables, y de orden de magnitud frente a IPVS en algunos casos.

Shortcut 2 — socket-LB: el paquete no se llega a construir

Cilium 1.6+ introdujo el socket-level load balancing, basado en cgroup hooks. Funciona así:

Cuando un pod hace connect(10.96.0.1:443) (ClusterIP de un Service), el syscall entra en el kernel.
Antes de que el kernel construya nada de red, un programa eBPF en CGROUP_SOCK_ADDR/connect4 intercepta y reescribe la dirección de destino a la IP real del pod backend.
El kernel continúa con el connect como si el cliente hubiera escrito directamente 10.0.0.42:8080.

¿Por qué importa? Porque cuando el pod backend está en el mismo nodo, este shortcut convierte una llamada que habría implicado:

syscall connect → kernel stack → veth → bridge → veth → kernel stack → syscall accept

en:

syscall connect (con destino reescrito) → loopback directo

La pila TCP/IP se evita literalmente. No hay paquete encapsulado, no hay viaje por veth pairs, no hay netfilter. Latencias L7 de pod-a-pod en el mismo nodo bajan a niveles de comunicación local (~5-15 µs en lugar de ~30-50 µs para servicios con kube-proxy iptables y veth tradicional).

Shortcut 3 — direct routing pod-a-pod

El modo overlay tradicional (Flannel, Calico VXLAN) encapsula cada paquete pod-a-pod en VXLAN/Geneve. Cada paquete carga un header extra de 50 bytes, requiere encap/decap, y consume MTU.

Cilium soporta direct routing: los pod CIDRs se anuncian a la fabric subyacente (con BGP, ahí entra el control plane que veremos) y los routers físicos enrutan los paquetes pod-a-pod sin encapsular. El paquete sale de un pod con su IP original como source y la IP del pod destino como dest, la NIC del nodo lo entrega a la red, la red lo enruta, llega al nodo destino y se entrega al pod. Cero encap, MTU completo, latencia mínima.

Cilium hace esto vía programas eBPF en TC que reescriben las cabeceras necesarias y deciden si el paquete va por encap o direct según la política configurada por nodo.

Shortcut 4 — Network Policy en TC con maps

Las Network Policies en CNIs clásicos suelen traducirse a reglas iptables, otro factor que explota linealmente. Cilium las evalúa en programas eBPF que leen maps de identity: cada workload tiene un identifier numérico calculado desde sus labels, y la policy es un map (src_identity, dst_identity, port, proto) → allow|deny. Un lookup en hash map por paquete.

Esto también permite las L7 policies de Cilium (filtrado HTTP, gRPC, Kafka): el programa eBPF reconoce el handshake L7, redirige selectivamente al proxy Envoy embebido (que vive como sidecar del datapath, no como sidecar de pod) y solo en ese subset paga el coste del proxy L7. Todo el tráfico L3/L4 sigue por el fast path eBPF.

Cilium: la arquitectura

Cilium combina dos planos:

Agent (Go): vive como DaemonSet en cada nodo. Es lo “lento”: traduce el deseo expresado en CRDs (CiliumNetworkPolicy, CiliumBGPClusterConfig, etc.) en entradas en eBPF maps. Habla con el API server de Kubernetes para descubrir endpoints, services, pods. Embebe un GoBGP para el control plane de BGP. Embebe un Envoy para L7 policies.
Datapath (eBPF): los programas cargados en XDP, TC, cgroup hooks. Son lo “rápido”: ven cada paquete, leen los maps que el agent mantiene, deciden en nanosegundos.

Esta separación es lo que hace operacionalmente cómodo a Cilium: el deseo se expresa en YAML, el agent lo materializa en maps, los maps son leídos por el datapath. Si el agent se cae temporalmente, el datapath sigue funcionando con la última configuración cargada. Como en cualquier sistema de control/data plane bien hecho.

El BGP Control Plane v2: los CRDs que tienes que conocer

Cilium ha tenido soporte de BGP varios años. La primera versión usaba un único CRD monolítico, CiliumBGPPeeringPolicy, que mezclaba en un solo objeto la configuración del nodo, los peers, los timers y los anuncios. Desde Cilium 1.16 existe el BGP Control Plane v2, que descompone esa configuración en CRDs separados con responsabilidades claras. El CiliumBGPPeeringPolicy (API cilium.io/v2alpha1) está deprecated y los avisos de migración aparecen en los logs del operator si todavía lo usas.

Los CRDs nuevos (API cilium.io/v2):

1. `CiliumBGPClusterConfig`

Define instancias BGP y los peers a los que se conectan, desde la perspectiva del cluster. Se selecciona qué nodos aplican esta configuración con un nodeSelector.

apiVersion: cilium.io/v2
kind: CiliumBGPClusterConfig
metadata:
 name: cilium-bgp-cluster
spec:
 nodeSelector:
 matchLabels:
 bgp-policy: rack-1  # solo nodos con esta label
 bgpInstances:
 - name: instance-65000
 localASN: 65000
 peers:
 - name: top-of-rack-1a
 peerASN: 64512
 peerAddress: 10.0.1.1
 peerConfigRef:
 name: tor-shared-config  # → referencia a CiliumBGPPeerConfig
 - name: top-of-rack-1b
 peerASN: 64512
 peerAddress: 10.0.1.2
 peerConfigRef:
 name: tor-shared-config

Una instancia BGP es la abstracción “este nodo participa en BGP con este ASN local y estos peers”. Pueden coexistir varias en un mismo nodo (multi-instancia para multi-VRF).

2. `CiliumBGPPeerConfig`

Define los parámetros compartidos del peering: timers, address families, transport, password MD5, graceful restart, etc. Se referencia desde CiliumBGPClusterConfig via peerConfigRef. Esto evita repetir la misma configuración para cada peer cuando hay decenas de ellos.

apiVersion: cilium.io/v2
kind: CiliumBGPPeerConfig
metadata:
 name: tor-shared-config
spec:
 timers:
 holdTimeSeconds: 30
 keepAliveTimeSeconds: 10
 connectRetryTimeSeconds: 5
 gracefulRestart:
 enabled: true
 restartTimeSeconds: 120
 families:
 - afi: ipv4
 safi: unicast
 advertisements:
 matchLabels:
 advertise: bgp  # → liga a CiliumBGPAdvertisement
 - afi: ipv6
 safi: unicast
 advertisements:
 matchLabels:
 advertise: bgp
 authentication:
 password:
 name: bgp-md5-secret  # Secret con la password MD5
 key: password

Una sola CiliumBGPPeerConfig puede ser referenciada por muchos peers distintos. Cambias timers o families en un sitio.

3. `CiliumBGPAdvertisement`

Declara qué prefijos se anuncian: los pod CIDRs del nodo, los ClusterIPs y ExternalIPs de Services, las IPs asignadas por CiliumLoadBalancerIPPool para Services type=LoadBalancer. Se vinculan a CiliumBGPPeerConfig via labels.

apiVersion: cilium.io/v2
kind: CiliumBGPAdvertisement
metadata:
 name: services-and-pods
 labels:
 advertise: bgp  # ← la label que el PeerConfig matchea
spec:
 advertisements:
 - advertisementType: PodCIDR  # anuncia el pod CIDR del nodo
 attributes:
 communities:
 standard:
 - "65000:100"
 - advertisementType: Service  # anuncia ClusterIPs / LoadBalancer IPs
 service:
 addresses:
 - LoadBalancerIP
 - ClusterIP
 - ExternalIP
 selector:
 matchLabels:
 bgp-advertise: "true" # solo Services con esta label
 attributes:
 communities:
 standard:
 - "65000:200"
 localPreference: 200

La granularidad es muy fina: puedes anunciar diferentes tipos de prefijos con diferentes communities BGP, diferentes local-preference, diferentes path attributes, y filtrar Services con label selectors. Esto era literalmente imposible con CiliumBGPPeeringPolicy v1.

4. `CiliumBGPNodeConfig` (auto-generado)

Este CRD no se configura a mano. El operator de Cilium lo genera por cada nodo a partir de la CiliumBGPClusterConfig que aplica a ese nodo. Es el estado materializado per-node que el agente de cada nodo lee para arrancar sus peerings. Si quieres ver qué configuración BGP está corriendo realmente en un nodo, kubectl get ciliumbgpnodeconfig <nodename> -o yaml te lo enseña.

5. `CiliumBGPNodeConfigOverride`

Opcional. Permite sobrescribir la configuración generada para un nodo concreto cuando necesitas algo no-estándar. Casos de uso:

Anclar el router-id BGP a una IP específica (útil cuando el nodo tiene varias interfaces).
Especificar la dirección local del peer cuando hay varias interfaces de salida.
Cambiar timers solo para un nodo problemático.

apiVersion: cilium.io/v2
kind: CiliumBGPNodeConfigOverride
metadata:
 name: node-rack1-master01  # nombre debe coincidir con el del nodo
spec:
 bgpInstances:
 - name: instance-65000
 routerID: 10.0.1.10 # override del router-id
 peers:
 - name: top-of-rack-1a
 localAddress: 10.0.1.10 # interface local concreta

Diagrama de relaciones

CiliumLoadBalancerIPPool: complementa, no es BGP

Aunque no es un CRD BGP estrictamente, conviene mencionarlo: CiliumLoadBalancerIPPool es el CRD que provee IPs a Services type=LoadBalancer. Define un rango (10.20.0.0/24, por ejemplo) que Cilium asigna automáticamente a Services LoadBalancer. Combinado con CiliumBGPAdvertisement que anuncia LoadBalancerIP, da el ciclo completo: Service nuevo → IP asignada del pool → anuncio BGP a los routers → IP routable desde la red corporativa, sin balanceador externo.

apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
 name: lb-pool-rack1
spec:
 blocks:
 - start: "10.20.0.10"
 stop: "10.20.0.250"
 serviceSelector:
 matchLabels:
 lb-pool: rack1

Manifest completo: pod CIDRs + LoadBalancer Services anunciados a un par ToR redundante

Ejemplo realista de un cluster con dos top-of-rack switches como peers BGP, ambos en el mismo AS (64512), Cilium en AS 65000:

# 1. CiliumBGPPeerConfig — config compartida para los dos ToR
---
apiVersion: cilium.io/v2
kind: CiliumBGPPeerConfig
metadata:
 name: tor-peers
spec:
 timers:
 holdTimeSeconds: 30
 keepAliveTimeSeconds: 10
 gracefulRestart:
 enabled: true
 restartTimeSeconds: 120
 families:
 - afi: ipv4
 safi: unicast
 advertisements:
 matchLabels:
 advertise: bgp

# 2. CiliumBGPAdvertisement — qué se anuncia
---
apiVersion: cilium.io/v2
kind: CiliumBGPAdvertisement
metadata:
 name: pods-and-lb
 labels:
 advertise: bgp
spec:
 advertisements:
 - advertisementType: PodCIDR
 - advertisementType: Service
 service:
 addresses: [LoadBalancerIP]
 selector:
 matchExpressions:
 - { key: io.kubernetes.service.namespace, operator: NotIn, values: [kube-system] }

# 3. CiliumBGPClusterConfig — qué nodos hablan con qué peers
---
apiVersion: cilium.io/v2
kind: CiliumBGPClusterConfig
metadata:
 name: cluster-bgp
spec:
 nodeSelector:
 matchLabels:
 bgp: enabled
 bgpInstances:
 - name: instance-65000
 localASN: 65000
 peers:
 - name: tor-a
 peerASN: 64512
 peerAddress: 10.0.1.1
 peerConfigRef: { name: tor-peers }
 - name: tor-b
 peerASN: 64512
 peerAddress: 10.0.1.2
 peerConfigRef: { name: tor-peers }

# 4. CiliumLoadBalancerIPPool — rango de LB IPs
---
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
 name: lb-corporate
spec:
 blocks:
 - cidr: "10.20.0.0/24"

Cuatro objetos. Antes, en v1, era un único CiliumBGPPeeringPolicy que mezclaba todo y resultaba difícil de mantener en clusters de más de 5 nodos con configuración heterogénea. La nueva separación es más larga pero claramente factorizable: un PeerConfig por tipo de peer, una Advertisement por política de anuncio, un ClusterConfig que conecta nodos con peers.

Trampas operativas comunes

Modo `routingMode: tunnel` con BGP

BGP solo tiene sentido con direct routing (routingMode: native). Si tienes el modo tunnel (VXLAN/Geneve) y configuras BGP, anunciarás pod CIDRs pero los paquetes seguirán saliendo encapsulados, generando un comportamiento confuso (a veces vía túnel, a veces directo según rutas). Configura routingMode: native y desactiva túnel.

eBPF host routing vs `kube-proxy replacement`

Son dos cosas distintas. kubeProxyReplacement: true habilita el reemplazo de kube-proxy (los Services). bpf.hostRouting: true habilita el bypass de iptables del host (las decisiones de routing del nodo se hacen con eBPF en lugar de FIB tradicional). El segundo necesita kernel 5.10+ con todas las features bpf habilitadas; si no tienes ese kernel, queda en modo legacy y el rendimiento es solo “casi tan bueno”.

BGP timers agresivos sobre NICs flapping

Con holdTimeSeconds: 9 / keepAliveSeconds: 3, una NIC que parpadee 5 segundos rompe la sesión BGP y todas las rutas anunciadas desaparecen del fabric. Los pods de ese nodo se vuelven inalcanzables hasta que la sesión se restablece. Para clusters en hardware con NICs sospechosas, usa los valores conservadores (holdTime: 30, keepAlive: 10) y considera graceful restart explícitamente (ya viene en el ejemplo de arriba).

Anunciar ClusterIP a la red corporativa

Anunciar ClusterIP a routers externos es rara vez lo que quieres: son IPs de Service interno, no diseñadas para alcanzarse desde fuera del cluster. Para exposición externa, usa LoadBalancerIP desde un CiliumLoadBalancerIPPool. Anunciar ClusterIP solo tiene sentido en topologías muy específicas (multi-cluster mesh con shared service discovery).

Mezclar v2alpha1 (`CiliumBGPPeeringPolicy`) y v2 (`CiliumBGPClusterConfig`)

No funciona bien. El operator emite warnings en los logs sobre el uso de la API deprecated, y los conflictos entre lo que define la peering policy vs la cluster config pueden producir estados raros. Migra de una a la otra en una sola pasada; no convivas.

MD5 password y MTU

Si configuras MD5 password en CiliumBGPPeerConfig.authentication, el header TCP es más grande. En links con MTU justa (1500 - 50 VXLAN del fabric upstream, por ejemplo), el handshake BGP puede fragmentar y morir silenciosamente. O usa MTU 9000 entre nodos y ToR, o asegura que los MSS están negociados correctamente.

Lo que no hemos cubierto

Cilium Cluster Mesh: federación de varios clusters Cilium para que sus Services se vean entre sí. Encaja con BGP cuando se quiere routing nativo entre clusters; tiene CRDs propios.
L7 Policies y Envoy embebido: política HTTP/gRPC/Kafka. Otra capa de eBPF + proxy que merece artículo propio.
Hubble: observabilidad de tráfico basada en eBPF que Cilium expone. Dashboards de flow logs con cero impacto en latencia.
Wireguard transparente: encryption pod-a-pod sin sidecars, controlado por Cilium via eBPF redirect a un dataplane WireGuard del kernel.
Gateway API en Cilium: el sucesor de Ingress, con soporte de primera clase desde Cilium 1.16+.
eBPF para LLM serving: la conexión natural con la serie anterior de inferencia. Hay trabajos recientes que usan eBPF para fairness multi-tenant en GPUs y para tracking de tokens; territorio de papers, aún no production.

Es decir, queda material para otros tres artículos de la serie de hoy. Vamos en orden.

Referencias

Conceptuales y de proyecto:

eBPF.io — documentación canónica del ecosistema eBPF.
The BPF Compiler Collection (bcc) y bpftrace — herramientas para empezar.
eBPF en 2026: How Extended Berkeley Packet Filter Became the Engine of Linux Observability and Networking — estado del arte.

XDP, TC y firewalling:

Getting started with XDP and eBPF (Red Hat docs).
Full Guide to BPF Firewalls: XDP, tc, and eBPF Integration (Medium, 2025).
Cloudflare blog: XDP for DDoS mitigation.
Facebook Katran (GitHub) — L4 LB con XDP, código y paper.

Cilium:

Cilium documentation — siempre el primer puerto.
Kubernetes Without kube-proxy — la guía oficial del replacement.
Cilium BGP Control Plane Resources (docs) — referencia de los CRDs v2.
Configuring Cilium BGP Control Plane (OneUptime blog, mar 2026) — walkthrough.
A Guide to BGP Control Plane and Cluster Mesh in Cilium Networking (Sigrid Jin, Medium) — artículo más profundo con casos de uso.

Cross-references:

Artículo previo en este blog: Kubernetes con Cilium BGP: servicios accesibles sin Ingress — el primer paso, con la versión v1 (que ya hay que migrar).
Series sobre inferencia LLM: KV cache, vLLM en Kubernetes, PagedAttention deep dive, Operators LLM K8s — donde la red rápida (que veremos en los siguientes posts de esta serie) determina el rendimiento real.

Kubernetes con Cilium BGP: servicios accesibles sin Ingress

Sun, 08 Mar 2026 00:00:00 +0000

Una de las ventajas de usar Cilium como CNI en Kubernetes es su soporte nativo de BGP. Esto permite anunciar los ClusterIPs y LoadBalancer IPs directamente al router de la LAN, haciendo los servicios accesibles sin necesidad de Ingress o NodePort.

El problema

En un clúster Kubernetes estándar, los pods y servicios viven en redes internas no alcanzables desde fuera del clúster. Para acceder a ellos se necesitan NodePort, Ingress o un LoadBalancer externo.

Con Cilium BGP, los pod CIDRs y service CIDRs se anuncian vía BGP al router upstream, haciendo toda la red del clúster routable desde la LAN.

Artículo en desarrollo — próximamente con configuraciones completas para RKE2 + CRS327.

Kubernetes on lo0 — Blog Técnico

Hubble: observabilidad de red en eBPF, estado del arte 2026 y la nueva frontera con los agentes IA

TL;DR

La analogía: tcpdump que habla Kubernetes

Arquitectura: cuatro piezas que se ven desde fuera

1. Hubble Server (embedded en cada agent Cilium)

2. Hubble Relay (agregador)

3. Hubble CLI (hubble)

4. Hubble UI

Qué se ve: el flow log de Hubble por dentro

Verdict y atribución de drops

Métricas Prometheus y dashboards Grafana

Despliegue: Helm en una pantalla

Estado del arte en 2026

Atribución directa de drops a NetworkPolicy

Tracing con IP options

Filtrado por estado de cifrado

Hubble field mask API estabilizado

AI-driven anomaly detection (predictive security)

Escala a 10 000+ pods

Cilium 1.20 en desarrollo

La nueva frontera: eBPF y los agentes de IA

AgentSight: zero-instrumentation para agentes LLM

Cómo encaja con Hubble y Tetragon

Casos de uso emergentes

Casos de uso habituales de Hubble

1. Debug de NetworkPolicy

2. Audit de comunicación inter-namespace

3. Detección de exfiltración

4. SLO de servicio en tiempo real

5. Performance debugging

6. Forensics post-incidente

Hubble y el resto del stack de observabilidad

Comparativa con alternativas

Trampas operativas

Cardinalidad en Prometheus

L7 visibility cuesta CPU

Hubble Relay sin HA

Encryption status reporting depende de Cilium config

UI expuesta sin auth

Storage no escalado

Lo que no hemos cubierto

Referencias

Tetragon: el primo de seguridad de Cilium que ve cada syscall en el kernel

TL;DR

La analogía: auditd con esteroides en eBPF

Qué es Tetragon, arquitectónicamente

Los dos CRDs: TracingPolicy y TracingPolicyNamespaced

Anatomía de una TracingPolicy

Hook points soportados

Argumentos

Selectors: filtrado en el kernel

Acciones: del simple Post al Sigkill

Modos: detection vs enforcement

Ejemplo completo: bloquear escrituras a /etc/passwd en namespace prod

Casos de uso habituales

1. Auditoría de ejecución (execve)

2. Acceso a archivos sensibles

3. Conexiones de red salientes no autorizadas

4. Detección de container escape

5. Cryptomining

6. Detección de rootkits y módulos del kernel sospechosos

Bonus: detección de modificación de eBPF maps por terceros

Comparativa con Falco

Hubble + Tetragon: observabilidad unificada

Despliegue y operación

Helm

CLI tetra

Exportar a SIEM

Performance

Trampas operativas comunes

monitoring permanente

Selectors demasiado laxos

Kernel demasiado viejo

Hooks en funciones del kernel renombradas

Sigkill en namespaces críticos

rateLimit ausente

Lo que no hemos cubierto (próximos artículos)

Referencias

eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP

3. Hubble CLI (`hubble`)

Ejemplo completo: bloquear escrituras a `/etc/passwd` en namespace prod

1. Auditoría de ejecución (`execve`)

CLI `tetra`

`monitoring` permanente

`Sigkill` en namespaces críticos

`rateLimit` ausente

1. `CiliumBGPClusterConfig`

2. `CiliumBGPPeerConfig`

3. `CiliumBGPAdvertisement`

4. `CiliumBGPNodeConfig` (auto-generado)

5. `CiliumBGPNodeConfigOverride`

Modo `routingMode: tunnel` con BGP

eBPF host routing vs `kube-proxy replacement`

Mezclar v2alpha1 (`CiliumBGPPeeringPolicy`) y v2 (`CiliumBGPClusterConfig`)