eBPFChirp FM

Interview with Henrik Rexed, CNCF Ambassador, Cloud Native Advocate at Dynatrace

This time I sat down with Henrik Rexed [https://www.linkedin.com/in/hrexed/], CNCF Ambassador and Staff Engineer at Dynatrace [https://www.dynatrace.com/]. Henrik is also the voice behind the popular blog Is It Observable [https://isitobservable.io/] and brings deep expertise from a career spent largely in performance engineering. Here’s what we covered: * What does a CNCF Ambassador actually do? It turns out the role is less about status and more about survival for open-source projects. The goal is simple: help the community navigate a landscape flooded with new tools and ensure worthy projects actually get adopted. * When “CPU Usage” tells you nothing From European League live streams to GPS trackers on police cars in the desert, simulating massive loads used to be the only way to understand system limits. But simply knowing a CPU is “waiting” isn’t enough. Is it waiting on disk? On the network? We discussed why traditional observability fail in modern architectures and how eBPF provides the missing context. * Is eBPF always the answer? It’s tempting to rewrite everything in eBPF, but is it always necessary? Dynatrace takes a “tactical” approach. Forcing eBPF onto legacy bare-metal systems with old kernels creates a maintenance nightmare. The argument here is for a hybrid model: use eBPF only where the environment (like Kubernetes) is controlled enough to support it safely. * The “Cross Your Fingers” Deployment We deploy network policies in Kubernetes or Istio, but do we actually know what they are doing? There is a frustrating gap in observability: when a connection fails, was it the policy or the network? Right now, most of us are just guessing. * Security: To block or to listen? If a process acts up, should you kill it immediately? Aggressive blocking often causes more problems than it solves, especially if dependencies break. We discuss the alternative: using “honeypots” and fake tokens to let attackers reveal themselves before you take action—learning the behavior rather than just stopping the process. I’ll leave it at that. Hope you enjoy it 🐝 Get full access to eBPFChirp at ebpfchirp.substack.com/subscribe [https://ebpfchirp.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]

Interview with Rafael David Tinoco, Senior Software Engineer at Garnet

This time I sat down with Rafael David Tinoco [https://www.linkedin.com/in/rafaeldtinoco/], Engineer at Garnet [https://www.linkedin.com/company/garnetlabs], where he’s developing Jibril — a runtime security engine. Rafael’s story spans from mainframes and operating system internals to maintaining Tracee at Aqua Security, and now, pushing eBPF to its architectural limits at Garnet. Here’s what we covered: * From CI/CD runtime security to Kubernetes Jibril started as a project focused on GitHub Actions runtime security, but as users began deploying it in Kubernetes clusters, the transition was natural. After all, GitHub runners are just virtual machines — Kubernetes simply scales that model across nodes. * The context-first vision From day one, Garnet’s founders had a clear thesis: whoever holds the best context wins. Jibril’s engine was built around this — capturing what’s happening at the system level without caring whether it’s running on GitHub, Kubernetes, or even a toaster. * A new/unique way to process kernel events Unlike traditional runtime security tools like Falco, Tetragon, or Datadog Agent, Jibril doesn’t stream events from kernel to user space. Instead, it uses an in-kernel data query model — treating eBPF maps like a database.Rather than flooding user space with raw events, Jibril stores, indexes, and exposes them on-demand through queries. The result: an order of magnitude reduction in CPU and memory usage while maintaining full observability. * Virtual maps and caching To make this model scale, Rafael built what he calls virtual maps — “maps made of maps” — enabling nested lookups and richer data structures entirely in-kernel.A userland caching layer further optimizes queries, ensuring repeated lookups don’t re-hit the kernel unless necessary. The outcome is a smooth balance between cadence and performance, with tunable refresh intervals depending on workload. * Beyond just detection Jibril already supports in-kernel enforcement, blocking domains or CIDRs at egress using eBPF — no proxy, no user-space hop.For broader cluster-wide blocking, it can also hand off to Cilium to enforce network policies, rather than competing with it. At the end, there’s a short demo of Jibril — aimed at a more technical audience — showcasing the concepts we discussed throughout our conversation. I’ll leave it at that — this was one of the most technical and insightful discussions I’ve had about eBPF architecture in a while. Jibril is shaping up to be a fascinating rethink of how we do runtime security — not by streaming data faster, but by rethinking where and how data lives. 🐝 Get full access to eBPFChirp at ebpfchirp.substack.com/subscribe [https://ebpfchirp.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]

Interview with Avi Lumelsky, AI Security Researcher at Oligo Security

This time I sat down with Avi Lumelsky [https://www.linkedin.com/in/avi-lumelsky-713111144/], AI Security Researcher at Oligo Security [https://www.oligo.security/], where he works at the intersection of AI and runtime protection. Avi’s story is a perfect example of how curiosity leads to innovation. Here are some of the topics we covered: * From inference to insightBefore Oligo, Avi worked at Deci AI, optimizing model inference speed. There, he realized something crucial — performance isn’t just about models; it’s also about how well you understand and leverage the system it runs on. * The confinement challengeImagine a Python model that should only do math, but could also spawn a subprocess or access the network. How do you confine it safely? * Discovering eBPFHis early experiments with DTrace were too slow and invasive for production, so when eBPF matured, he rebuilt his secimport [https://github.com/avilum/secimport] prototype — and found a scalable way to trace and enforce what code can (and can’t) do in real time. * Beyond observabilityAvi’s big insight: eBPF isn’t just for monitoring. Combined with Linux Security Modules (LSM) and KRSI, it can actively stop malicious behavior before it completes — for example, blocking a rogue pickle.load() before it spawns a shell. * Language-aware securityAt Oligo, Avi’s team extended this concept across languages — Python, Java, Node, .NET, PHP — extracting application-level context straight from production without user-space overhead. * From CVEs to contextInstead of flagging every potential vulnerability, Oligo maps which functions actually run in production, reducing noise and focusing developer effort where it matters most. * The AI connectionWe also discussed how AI agents could soon operate eBPF — dynamically tuning kernel parameters or deploying probes on demand, creating adaptive, self-healing systems. * Looking aheadAvi sees a future where security tooling merges with intelligence — where production data directly informs code fixes, and AI uses eBPF to keep systems resilient in real time. 🐝 I’ll leave it there — hope you enjoy the conversation. Get full access to eBPFChirp at ebpfchirp.substack.com/subscribe [https://ebpfchirp.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]

Runtime Security in GitHub Actions using eBPF

In this talk, I demonstrate how eBPF can bring runtime security into GitHub Actions — giving CI/CD pipelines the same level of network visibility and protection we expect from production systems. It’s a deep dive into how we can trace and enforce network policies to run workflows securely and in real time — all without slowing developers down. If you’re into eBPF or love pushing observability and security beyond servers, this one’s for you. What’s inside: * A quick eBPF intro * How companies like Cloudflare, Meta, Netflix, and Cisco use it * The problem with GitHub Actions today * An eBPF-based Network Policy Engine * A live demo in action 🚀 And yes — I’ve even designed myself an eBPFChirp shirt with a little joke on the back: “This shirt passed the verifier.” 😅 Thanks for reading eBPFChirp! This post is public so feel free to share it. Get full access to eBPFChirp at ebpfchirp.substack.com/subscribe [https://ebpfchirp.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]

Interview with Karim Traiaia, Co-Founder of Kerno

This time I sat down with Karim Traiaia [https://www.linkedin.com/in/karimtraiaia/], the Co-founder of Kerno [https://www.linkedin.com/company/kernoio/], a company that helps troubleshoot cloud applications. Here are some of the topics we discussed: * The sparkEvery startup starts with a pain point—how did Karim come up with Kerno, and what problem was he trying to solve at the beginning? * First customersLanding those early paying users is always tough. Did Kerno rely on free trials, community outreach, or partnerships to get started? * The eBPF foundationWas eBPF part of the plan from day one, or did the idea for Kerno evolve into it over time? And why eBPF specifically over other tooling? * What only eBPF can doWhere has eBPF been able to collect critical data that simply wasn’t available from user space or other observability tools? * Taming the telemetry floodObservability tools generate a LOT of events—from syscalls to protocol traces. How does Kerno decide what data to keep vs. what’s just noise, and how much is actually useful in practice? * The observer effectWhat about CPU and memory overhead—how does Kerno make sure the eBPF agent itself doesn’t impact the workloads? * Scaling upWhat’s the largest production environment Kerno has been tested in? What bottlenecks emerged at scale, and how were they solved? * Measuring impactKerno promises a “64% reduction in customer-facing production incidents” and a “3x increase in successful deployment attempts.” How are those numbers measured and validated? * Looking aheadWhat would Karim consider a home-run feature or capability for Kerno three years from now? * From visibility to autonomyWill we see a future where observability shifts from passive runtime visibility to autonomous systems that detect and act on issues—powered by eBPF-fed AI models? * Startup mindsetIf Karim were a fresh graduate looking at the industry, how would he approach finding and validating an idea that could grow into a startup? 🐝 I’ll leave it there—hope you enjoy the conversation. Get full access to eBPFChirp at ebpfchirp.substack.com/subscribe [https://ebpfchirp.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]