My Experience as a Speaker at KCD Lima 2025: eBPF and Attack Detection in Kubernetes
How it all started
A few months ago, a colleague told me: “hey, what if we submit as speakers at KCD Lima?” My first reaction was the classic: “I don’t know if I’m ready for that.” Impostor syndrome at its finest.
But the truth is I’d been wanting to step out of my comfort zone for a while. I work with Kubernetes every day, I’m fascinated by observability, and I’d been curious about eBPF ever since I watched a Brendan Gregg talk. So I said: “you know what? Let’s do it.”
And a few weeks ago, there we were: standing in front of a packed room at Kubernetes Community Days Lima 2025, talking about how eBPF can detect attacks and monitor traffic in real time inside a Kubernetes cluster.
What is KCD?
For those who don’t know, Kubernetes Community Days (KCD) are community-organized Kubernetes events worldwide. They’re like KubeCon’s younger siblings — more intimate, more local, but equally intense in technical content.
KCD Lima 2025 was the Peruvian edition, and the energy was incredible. Developers, SREs, DevOps engineers, all gathered to share cloud native knowledge. And there I was, as a co-speaker, nervous as hell but eager to share what we’d prepared.
Our talk: eBPF for attack detection in Kubernetes
What is eBPF?
If you haven’t heard of eBPF, let me explain with an analogy: imagine you could place “security cameras” inside the Linux kernel, without modifying the kernel or restarting anything. That’s eBPF.
eBPF (extended Berkeley Packet Filter) is a technology that lets you run programs in a sandbox inside the Linux kernel. This gives you superpowers to:
- Observe everything happening in the system (system calls, network traffic, file operations).
- Filter network packets at brutal speeds.
- Detect anomalous behavior in real time.
- Protect without the overhead of traditional solutions.
What makes it special is that it runs inside the kernel, not in userspace. That means it has direct access to everything happening in the system with minimal latency. You’re not capturing packets with tcpdump and analyzing them later — you’re seeing everything at the exact moment it happens.
Why does it matter in Kubernetes?
Because in Kubernetes everything is ephemeral. Pods appear and disappear, traffic flows between namespaces, and traditional network monitoring tools often lack the visibility you need.
With eBPF you can:
- See which pod is making which connection in real time.
- Detect if a pod is being hit by a DDoS attack.
- Monitor HTTP/HTTPS traffic without modifying applications.
- Implement more granular network policies with Cilium.
The demo: our repo in action
For the talk, we prepared a repository with everything needed to replicate what we showed live: kcd-2025-vagrant-k3s.
The idea was that any attendee could go home after the talk and reproduce every demo on their own machine. The repo has four modules:
Module 1: K3s Cluster with Vagrant
We created a 3-node cluster (1 master + 2 workers) using Vagrant and VirtualBox, with Cilium as the CNI. Why Cilium? Because it’s built on eBPF and gave us the perfect foundation for the demos.
cd 01-vm
vagrant up
export KUBECONFIG=$(pwd)/kube.config
kubectl get nodesIn a few minutes you had a functional Kubernetes cluster with eBPF ready to use.
Module 2: eBPF Probes
This is where the fun began. We created three types of probes:
1. Simple Kprobe — Monitoring file operations at the kernel level. Every time a process opened, read or wrote a file, our probe captured it. This might sound simple, but imagine detecting in real time that a suspicious pod is reading /etc/shadow.
2. HTTP eBPF — Real-time HTTP traffic monitoring. No sidecar proxies, no application modification. eBPF intercepts packets directly in the kernel and extracts HTTP headers.
3. SSL eBPF — This one impressed the audience the most. Using uprobes on OpenSSL functions, we could see traffic before encryption and after decryption. Basically, HTTPS traffic visibility without breaking encryption and without additional certificates.
Module 3: DDoS Simulation and Detection
The most spectacular part of the demo. We simulated a DDoS attack against a service running in the cluster and showed how an eBPF program could:
- Detect the attack pattern (many connections from few IPs).
- Mitigate the attack by dropping packets directly in the kernel, before they reached the pod’s network stack.
- Report real-time attack statistics.
The performance difference between mitigating a DDoS in userspace vs in the kernel with eBPF was brutal. In the kernel, malicious packets were discarded in microseconds.
Module 4: Cilium and Hubble
Finally, we showed how Cilium uses eBPF under the hood to implement network policies and how Hubble (Cilium’s observability layer) gives you a view of all cluster traffic in a UI.
What I learned as a speaker
Nerves are normal
I won’t lie: the first 5 minutes I felt like my heart was going to jump out of my chest. But once we started the demo and I saw people were hooked, the nerves turned into adrenaline. When someone in the audience said “wow” after seeing the SSL probe capturing HTTPS traffic in plain text, I knew we’d chosen the right topic.
Preparing the demo is 80% of the work
The talk itself was 40 minutes. Preparation took weeks. Setting up the Vagrant environment, making everything reproducible, testing each demo 20 times to make sure it wouldn’t fail live, preparing a backup plan in case something went wrong… The live demo is the 20% the audience sees, but 80% is in the preparation.
The community is amazing
The best part of KCD wasn’t our talk — it was everything around it. Hallway conversations, questions after the talk, people coming up to say “hey, can I contribute to your repo?” The Kubernetes community in Peru is small but very passionate, and events like this are what make it grow.
Co-speaking works
Giving the talk with a partner was key. We split the topics, complemented each other’s explanations, and when one of us stumbled, the other picked up the thread. If you’re thinking about giving your first talk, find a co-speaker. It feels less lonely and the result is better.
What’s next?
This experience left me wanting more. I’m already thinking about topics for KCD 2026 — maybe something about observability with OpenTelemetry, or AI on Kubernetes (which is something I’m exploring on this blog).
But beyond that, KCD reminded me of something we sometimes forget when we’re deep in day-to-day work: sharing what you know is one of the best ways to learn. Preparing this talk forced me to understand eBPF at a level I never would have reached just reading documentation. Having to explain it to others forces you to truly understand.
If you’re reading this and have ever thought “I should give a talk but I don’t know if I’m ready” — let me tell you what someone told me: nobody feels ready, but do it anyway. The community doesn’t expect you to be a world expert. They expect you to share your experience with honesty.