Tetragon: Extending eBPF and Cilium to runtime security

If you’re responsible for security, you’d better be good at context switching. Enterprise infrastructure has never been more distributed, and the software stack has never had more moving parts. The average application today has more than 150 dependencies, according to Sonatype, and major languages like Java release updates up to 10 times per year. 

No surprise, then, that modern security threats are increasingly of the software supply chain variety, entering through the most vulnerable components in our stacks. And troubleshooting scenarios have become exceptionally complicated. 

From determining the entry point of the threat (a backdoor in versions 5.6.0 and 5.6.1 in the case of XZ Utils), to discovering where in your environment you are running compromised software, to pinpointing exactly which files were touched or exfiltrated by malicious actors — chasing all of this down means unpacking a Russian doll of different domains.

Runtime security is missing context

A decade since the first commit was made to Kubernetes, security teams and developers are still adapting to the shift from virtual machines to containers. Not only did Kubernetes’ labels and pods (bundles of containers) break traditional IP-centric security approaches, but questions that were straightforward with virtual machines — where services were running, for how long, where they ingressed, where they egressed, and what else they touched along the way — became murky in container environments.

In the past, a systems administrator would log into SSH and walk through a well-established, scripted procedure to run these interrogations. Today’s cloud-native environments — huge pools of Kubernetes nodes running interconnected microservices at scale, with pods coming and going at high frequency — have outgrown any sort of scripted procedure or established mental model. The lifetimes of pods can vary widely, and when terminated they push IP addresses back into the pool.

Not only are the locations of services difficult to pin down in a Kubernetes cluster, but the abstraction layers that make these distributed systems possible — between namespaces, pods, containers, kernels, and network — create blind spots for security pros who need to investigate them at run time and block threats with policies.

In order to answer security questions in containerized environments, you need much more context, at a much lower level. The place to get that context is the Linux kernel. 

If you think about the Linux kernel as an API, opening any file or socket is like making an API call. The granularity of security data that is emitted to and from the kernel makes it the perfect collection point. Further, when a new packet comes into your server it needs to be processed — it needs to be routed, broken down and distributed and brought into user space. That makes the kernel the optimal point in the data path to enforce security policies. And we can do that using Tetragon.

Building on Cilium and eBPF

Created by Isovalent, the creators of Cilium, Tetragon is a Kubernetes-aware security observability and runtime enforcement tool that takes advantage of Cilium’s networking, security, and observability capabilities, which in turn rely on eBPF’s hooks into the Linux kernel. Like Cilium, Tetragon is free open source, available under the Apache 2.0 license.

One of the first widely adopted eBPF projects, Cilium has become the de facto container network interface (CNI) for Kubernetes environments, chosen by all three major public cloud providers for their managed Kubernetes services. Cilium was the first graduated project in the CNCF’s CNI category, and it’s one of the three most-contributed-to cloud-native open source projects, along with Kubernetes and OpenTelemetry. 

Cilium uses eBPF to provide advanced networking capabilities including multi-cluster and multi-cloud networking, advanced monitoring capabilities including network, service, and security observability, and extensive network security capabilities including traffic encryption, network policy enforcement, and runtime enforcement. Tetragon is the subproject that focuses on runtime enforcement, drawing on eBPF’s hooks into the Linux kernel’s data path to give runtime security the missing context and policy enforcement primitives that never shipped with the Kubernetes operating model. 

Detection and enforcement in the Linux kernel

Tetragon runs on any Linux machine and uses eBPF for observability and enforcement. It cares about “security significant” events, like process execution events, system call activities, high volume I/O activity including network and file access. By sitting in the kernel with eBPF, Tetragon can truly observe everything.

What sets Tetragon apart is its intelligent in-kernel filtering and aggregation capabilities. Rather than sending all events to user space for processing, Tetragon leverages eBPF to perform sophisticated filtering directly in the kernel. This approach enables real-time threat detection and policy enforcement with minimal impact on system performance.

Because of its lineage with parent-project Cilium, Tetragon brings powerful network-aware capabilities. It can correlate process-level activities with network flows, showing which specific processes within containers are establishing connections or attempting suspicious network activities. This network awareness extends across clusters and environments, with deep context about the originating processes and binaries.

Tetragon excels in use cases requiring deep security observability, such as detecting unauthorized process executions, monitoring sensitive file access, tracking privilege escalations, and identifying suspicious network patterns. 

From an enforcement perspective, Tetragon enables real-time policy controls over system calls, file operations, network communications, and process behaviors — all defined through Kubernetes-native policies. This combination of deep visibility and granular control makes Tetragon particularly valuable for implementing zero-trust security postures in cloud-native environments.

A new era of network observability and security

Most engineers tend to think of “system calls” when they think of observability in the Linux kernel. But when operating at the kernel level, we can look at file access, at specific namespaces or containers, and then tie them with identity metadata. We can also look much more closely at networking events. 

With the hooks of eBPF in the kernel and extension into the network, Tetragon promises much richer remediation workflows than are now possible. Traditional tools wait too long to act—they observe something happening in the kernel, move it into user space, and then decide whether to act on it or send an alert. Milliseconds matter. With Tetragon, policies are built to be enforced in real time within the kernel so malicious events never execute. So instead of just reacting to these security events we see over the network, with Tetragon we can actually block an action with a sigkill, or override a value so it never executes.

We’re at an interesting crossroads in security and networking today. Personas that were once completely separate—network administrators, virtual machine administrators, Kubernetes platform engineers, cloud engineers working on specific public cloud platforms—are melding into masters-of-all “platform engineering” teams. 

Similarly, we’re seeing the boundaries between layers of the enterprise stack starting to relax, and seeking common operating models for simplicity. With Tetragon, the rich contextualization of security events, and ability to enforce against them, across not just user space but the kernel and the network layer, will make powerful runtime security a generalized skill that platform engineers and developers alike can tap into, to stay ahead of the software supply chain threat domain. 

Jeremy Colvin is a senior engineer at Isovalent. Jeremy’s passion is digging into the bits and bytes of what makes good security. As one of the world’s leading experts on the eBPF program, Tetragon, Jeremy works with security engineers to create defense strategies for new threat types like XZ Utils, which require advanced contextualization across Kubernetes identities, network infrastructure, and namespace. Jeremy graduated from Princeton, focusing on policy around privacy and information security, and has a masters degree in information security from UC Berkeley. Outside of Isovalent, Jeremy enjoys playing soccer and volunteering with Best Buddies.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.