Observabilidad y Seguridad en el Kernel con eBPF

El problema: los logs de aplicación no ven todo lo que decide el kernel

Hasta aquí has usado capturas, reglas y objetos de Kubernetes para entender un flujo. Pero un paquete puede descartarse antes de llegar a la pila normal, y un proceso puede abrir un socket sin que una captura aislada te diga qué cgroup o workload lo originó. eBPF existe para observar o controlar puntos muy concretos del kernel con una semántica explícita. [1]

La pregunta no es “¿cómo escribo un programa eBPF?”. Primero es: ¿en qué momento del recorrido necesito evidencia o enforcement, y qué contexto todavía existe allí? Un XDP temprano puede descartar rápido; un hook posterior puede relacionar el flujo con un Pod o proceso.

Mapa mínimo: el mismo paquete cambia de contexto al avanzar

NIC recibe bytes
    │
    ▼
XDP ── decisión muy temprana: DROP / PASS / REDIRECT
    │ si pasa
    ▼
stack y conntrack ── red normal del kernel
    │
    ▼
TC en veth ── interfaz, Pod y política de tránsito
    │
    ▼
socket/cgroup/LSM ── proceso, identidad u operación

No memorices todos los tipos de programa. Aprende la consecuencia del punto de enganche: un paquete descartado por XDP no llegará a TC ni a un socket; un hook de socket da contexto de proceso que XDP no tiene. [2]

Ruta de estudio y conexión con el roadmap

1. Comprende por qué el verifier acepta o rechaza un programa.
2. Elige XDP, TC, socket, cgroup o LSM según la pregunta que quieres responder.
3. Diseña eventos que unan paquete, PID, cgroup, netns y política.
4. Inventaría programas, mapas y adjuntos antes de cambiar el datapath.

El último módulo lleva esta misma disciplina a cloud: el control no es sólo un hook local, sino rutas, perímetros, identidad y política distribuidos entre VPC y workloads.

Referencia técnica: modelo de ejecución eBPF

eBPF se carga vía bpf() como bytecode para VM de registros, helpers y mapas. Verifier valida control flow, contexto/memoria, punteros, límites y terminación antes de admitirlo. Mapas mantienen estado; pinning/enlaces gobiernan vida. BTF/CO-RE dan tipos/portabilidad, no capacidades iguales. [3]

XDP corre RX pre-stack y retorna DROP, PASS, TX, REDIRECT o ABORTED: filtrado temprano. TC corre en interfaz ingress/egress. Socket filter ve socket; cgroup hooks y BPF LSM aportan contexto/previsión. [1]

Evento útil incluye PID, cgroup, netns, identidad y 5-tupla. Syscall aislado no es intención; correlación con policy sí. [4]

Lo que el verifier está defendiendo

eBPF no carga C arbitrario: produce instrucciones para VM y verifier demuestra que memoria/contexto, punteros, límites y terminación son seguros. Un puntero a paquete sólo es válido tras probar que hdr+1 no supera data_end. El log del verifier describe un camino que kernel no puede demostrar seguro. [5]

data ───────── parsed header ───────── data_end
  └── comprobar hdr + 1 <= data_end antes de leer ──┘

El mismo paquete desde hooks distintos

XDP ve RX antes de socket/conntrack. DROP reduce trabajo y evita observación posterior. TC ve ingress/egress de veth; socket hooks correlacionan proceso. Elegir hook es semántica: descartar paquete malformado no equivale a autorizar proceso identificado. [2]

NIC RX → XDP (bytes/verdict) → stack/conntrack → TC veth → socket (PID/cgroup)

Telemetría que sirve para investigar

Un mapa src-IP sólo dice volumen. Evento accionable une timestamp, verdict, program-id, cgroup, PID, netns, 5-tupla y policy-id. Ring buffer debe monitorizar presión: perder eventos bajo carga puede ocultar incidente. [6]

evento: ts | verdict | program-id | cgroup | pid | src:port → dst:port | policy-id