Mi experiencia como Speaker en el KCD Lima 2025: eBPF y detección de ataques en Kubernetes
¿Cómo empezó todo?
Hace unos meses, un colega me dijo: “oye, ¿y si nos presentamos como speakers en el KCD Lima?” Mi primera reacción fue la típica: “no sé si estoy listo para eso”. Síndrome del impostor en su máxima expresión.
Pero la verdad es que llevaba tiempo queriendo salir de mi zona de confort. Trabajo con Kubernetes todos los días, me fascina la observabilidad y tenía curiosidad por eBPF desde que vi una charla de Brendan Gregg. Así que dije: “¿sabes qué? Vamos.”
Y hace unas semanas, ahí estábamos: parados frente a una sala llena de gente en el Kubernetes Community Days Lima 2025, hablando sobre cómo eBPF puede detectar ataques y monitorear tráfico en tiempo real dentro de un cluster de Kubernetes.
¿Qué es el KCD?
Para quienes no lo conocen, los Kubernetes Community Days (KCD) son eventos organizados por la comunidad de Kubernetes a nivel mundial. Son como los hermanos menores de KubeCon — más íntimos, más locales, pero igual de intensos en contenido técnico.
El KCD Lima 2025 fue la edición peruana, y la energía fue increíble. Developers, SREs, DevOps engineers, todos reunidos para compartir conocimiento sobre cloud native. Y ahí estaba yo, como co-speaker, con los nervios a mil pero con muchas ganas de compartir lo que habíamos preparado.
Nuestra charla: eBPF para detección de ataques en Kubernetes
¿Qué es eBPF?
Si no has oído hablar de eBPF, te lo explico con una analogía: imagina que pudieras poner “cámaras de vigilancia” dentro del kernel de Linux, pero sin tener que modificar el kernel ni reiniciar nada. Eso es eBPF.
eBPF (extended Berkeley Packet Filter) es una tecnología que permite ejecutar programas en un sandbox dentro del kernel de Linux. Esto te da superpoderes para:
- Observar todo lo que pasa en el sistema (llamadas al sistema, tráfico de red, operaciones de archivos).
- Filtrar paquetes de red a velocidades brutales.
- Detectar comportamientos anómalos en tiempo real.
- Proteger sin el overhead de soluciones tradicionales.
Lo que lo hace especial es que corre dentro del kernel, no en userspace. Eso significa que tiene acceso directo a todo lo que pasa en el sistema con una latencia mínima. No estás capturando paquetes con tcpdump y analizándolos después — estás viendo todo en el momento exacto en que sucede.
¿Y por qué importa en Kubernetes?
Porque en Kubernetes todo es efímero. Los pods aparecen y desaparecen, el tráfico viaja entre namespaces, y las herramientas tradicionales de monitoreo de red muchas veces no tienen la visibilidad que necesitas.
Con eBPF puedes:
- Ver qué pod está haciendo qué conexión en tiempo real.
- Detectar si un pod está siendo víctima de un ataque DDoS.
- Monitorear tráfico HTTP/HTTPS sin modificar las aplicaciones.
- Implementar políticas de red más granulares con Cilium.
La demo: nuestro repo en acción
Para la charla, preparamos un repositorio con todo lo necesario para replicar lo que mostramos en vivo: kcd-2025-vagrant-k3s.
La idea era que cualquier asistente pudiera llegar a su casa después de la charla y reproducir cada demo en su propia máquina. El repo tiene cuatro módulos:
Módulo 1: Cluster K3s con Vagrant
Creamos un cluster de 3 nodos (1 master + 2 workers) usando Vagrant y VirtualBox, con Cilium como CNI. ¿Por qué Cilium? Porque está construido sobre eBPF y nos daba la base perfecta para las demos.
cd 01-vm
vagrant up
export KUBECONFIG=$(pwd)/kube.config
kubectl get nodesEn unos minutos tenías un cluster de Kubernetes funcional con eBPF listo para usar.
Módulo 2: Probes de eBPF
Aquí es donde empezó la parte divertida. Creamos tres tipos de probes:
1. Simple Kprobe — Monitoreo de operaciones de archivos a nivel del kernel. Cada vez que un proceso abría, leía o escribía un archivo, nuestra probe lo capturaba. Esto puede sonar simple, pero imagina detectar en tiempo real que un pod sospechoso está leyendo /etc/shadow.
2. HTTP eBPF — Monitoreo de tráfico HTTP en tiempo real. Sin sidecar proxies, sin modificar la aplicación. El eBPF intercepta los paquetes directamente en el kernel y extrae los headers HTTP.
3. SSL eBPF — Esta fue la que más impresionó al público. Usando uprobes sobre las funciones de OpenSSL, podíamos ver el tráfico antes de que se encriptara y después de que se desencriptara. Básicamente, visibilidad del tráfico HTTPS sin romper el cifrado y sin certificados adicionales.
Módulo 3: Simulación y detección de DDoS
La parte más espectacular de la demo. Simulamos un ataque DDoS contra un servicio corriendo en el cluster y mostramos cómo un programa eBPF podía:
- Detectar el patrón de ataque (muchas conexiones desde pocas IPs).
- Mitigar el ataque dropeando paquetes directamente en el kernel, antes de que llegaran al stack de red del pod.
- Reportar estadísticas en tiempo real del ataque.
La diferencia de rendimiento entre mitigar un DDoS en userspace vs en el kernel con eBPF fue brutal. En el kernel, los paquetes maliciosos se descartaban en microsegundos.
Módulo 4: Cilium y Hubble
Finalmente, mostramos cómo Cilium usa eBPF por debajo para implementar network policies y cómo Hubble (la capa de observabilidad de Cilium) te da una vista de todo el tráfico del cluster en una UI.
Lo que aprendí como speaker
Los nervios son normales
No voy a mentir: los primeros 5 minutos sentí que el corazón se me salía. Pero una vez que empezamos la demo y vi que la gente estaba enganchada, los nervios se transformaron en adrenalina. Cuando alguien del público dijo “wow” al ver la probe de SSL capturando tráfico HTTPS en texto plano, supe que habíamos elegido bien el tema.
Preparar la demo es el 80% del trabajo
La charla en sí duraba 40 minutos. La preparación tomó semanas. Montar el ambiente con Vagrant, hacer que todo fuera reproducible, probar cada demo 20 veces para asegurarnos de que no fallara en vivo, preparar un plan B por si algo salía mal… La demo en vivo es el 20% que el público ve, pero el 80% está en la preparación.
La comunidad es increíble
Lo mejor del KCD no fue nuestra charla — fue todo lo que pasó alrededor. Las conversaciones en los pasillos, las preguntas después de la charla, la gente que se acercó a decir “oye, ¿puedo contribuir a tu repo?”. La comunidad de Kubernetes en Perú es chica pero muy apasionada, y eventos como este son los que la hacen crecer.
Co-speaking funciona
Dar la charla con un compañero fue clave. Nos dividimos los temas, nos complementamos en las explicaciones y cuando uno se trababa, el otro tomaba el hilo. Si estás pensando en dar tu primera charla, busca un co-speaker. Se siente menos solo y el resultado es mejor.
¿Qué viene?
Esta experiencia me dejó con muchas ganas de más. Ya estoy pensando en temas para el KCD 2026 — quizás algo de observabilidad con OpenTelemetry, o IA en Kubernetes (que es algo que estoy explorando en este blog).
Pero más allá de eso, el KCD me recordó algo que a veces olvidamos cuando estamos metidos en el día a día del trabajo: compartir lo que sabes es una de las mejores formas de aprender. Preparar esta charla me obligó a entender eBPF a un nivel que nunca habría alcanzado solo leyendo documentación. Tener que explicarle a otros te fuerza a realmente entender.
Si estás leyendo esto y alguna vez has pensado “debería dar una charla pero no sé si estoy listo” — te digo lo que me dijeron a mí: nadie se siente listo, pero hazlo igual. La comunidad no espera que seas un experto mundial. Espera que compartas tu experiencia con honestidad.