Tetragon Explained: eBPF Runtime Security and Observability

By Taylor Thomas · 2026-09-02

Runtime security for containers has a hard requirement that traditional tooling struggles to meet: seeing what a workload does — the processes it spawns, the sensitive files policy watches — without deploying an agent into each container and without drowning the host in overhead. Tetragon answers this from inside the Linux kernel. It is an open-source eBPF-based security observability and runtime enforcement tool from the Cilium project family, and it earns its place on the SCAZT 300-740 blueprint by doing two jobs at once: telling you precisely what ran, and — where policy says so — stopping it in-kernel.

What Tetragon Sees

The foundation is process visibility with lineage. Tetragon records process executions with parent information — and, where ancestry tracking is configured, deeper ancestor chains — so an event is not just “a shell started” but “this shell, started by this process, in this container.” That lineage is a large part of what separates a routine health check from a webshell: whether the same binary is innocent or hostile often depends heavily on what spawned it, alongside its arguments, targets, and what it does next. Around that spine, policy can add file access, network activity, and other kernel events captured at their hook points.

The second half of the answer is context. On a Kubernetes node, Tetragon enriches events with workload identity — pod, namespace, container — so the event stream speaks the language of your cluster rather than the language of host PIDs. “Pod payment-api in namespace prod executed /bin/sh” is actionable; “PID 41172 executed /bin/sh” is homework. This is workload context doing the attribution work that workload identity does for authentication — related jobs, distinct mechanisms — and because the sensor lives in the shared kernel, one agent per covered Linux node observes the workloads sharing that node’s kernel: the vantage-point argument made in the eBPF guide, applied.

Policy as a Kubernetes Object

Operationally, Tetragon runs as a per-node agent — in Kubernetes, typically deployed so each supported Linux node carries the sensor — with the eBPF programs it loads doing the actual observation in the kernel. Process lifecycle visibility — the execution events and ancestry described above — is built-in; what the sensor watches beyond that is driven by TracingPolicy resources — Kubernetes custom resources that declare which kernel hook points to instrument, such as kprobes on specific kernel functions, what to match there, and what to do on a match. Policy can therefore live where the rest of your cluster configuration lives: versioned in Git, applied with the same tooling, reviewed like any other manifest. A policy might watch execution of anything under /tmp, reads of a credential path, or calls that change privileges — and the matching happens in-kernel, so unwanted events can be filtered before they are exported to user space. That in-kernel selection is a key design choice for keeping always-on monitoring affordable, though actual overhead scales with what policies watch and how much fires.

Enforcement, Carefully

Observation is Tetragon’s default posture; enforcement is an explicit policy decision, and its two main actions differ in what they promise. Sending SIGKILL terminates the offending process fast — but the operation that triggered the match may already have completed by the time the signal lands, so a kill is rapid containment, not guaranteed prevention. Overriding a call’s return value, available at supported hook points, is the preventive form: the operation is denied from the caller’s perspective. Both happen in-kernel, at the point of the event rather than seconds later when an alert reaches a responder. That immediacy is the appeal and the risk in equal measure. A wrong enforcement rule kills legitimate workloads exactly as fast as it kills attacks, so the operating discipline mirrors every enforcement technology worth deploying: run the policy without enforcement actions against real production traffic, study what it would have done, and enable the actions only when the answer is boring. Scope helps as much as patience — the first enforcement policies should guard a few unambiguous invariants on high-value workloads, the operations that are never legitimate there, rather than attempting a cluster-wide allowlist of everything normal. Events can be exported as structured JSON, so the observe phase feeds the logging and detection pipeline you already run, and enforcement earns trust one narrow policy at a time.

Where This Sits for Certification

SCAZT 300-740 objective 1.6 asks candidates to describe how eBPF-based tools — naming Cilium and Tetragon — provide runtime security observability and enforcement for containerized workloads. Within that pair, Cilium primarily supplies eBPF-based connectivity, network policy, and network observability; Tetragon focuses on runtime security, and this guide is the shape of the answer: kernel-resident visibility, workload-attributed events, policy as a cluster object, enforcement as a deliberate second step. The SCAZT course takes it hands-on in a cluster, and the course catalog shows where cloud and container security sits in the full CCNP Security track.

Frequently Asked Questions

How is Tetragon different from plain eBPF?

eBPF is the kernel facility — the ability to run verified programs at kernel hook points. Tetragon is an open-source project built on it: curated instrumentation for security-relevant events, Kubernetes enrichment so events name pods and containers rather than only PIDs, a policy language for choosing what to watch and what to act on, and structured event output. You could build all of that yourself from raw eBPF; Tetragon is that engineering already done.

Can Tetragon actually block an attack, or only record it?

Both, by policy. Its default posture is observation — rich events that can be collected into your logging pipeline. Policies can add in-kernel enforcement: killing a matching process quickly (containment — the triggering operation may already have completed), or overriding a call's return value at supported hooks so the operation is denied outright. Enforcement at that speed cuts both ways, so the operating pattern is to run a policy without enforcement against production traffic first and enable actions only after the alert stream proves clean.

Why does a Cisco exam blueprint name an open-source tool?

SCAZT objective 1.6 asks candidates to describe how eBPF-based tools — naming Cilium and Tetragon — provide runtime observability and enforcement for containerized workloads. Both are open-source, vendor-neutral projects; Isovalent, now part of Cisco, created Tetragon and has been a major contributor to both. Whatever the blueprint's authors intended, the practical effect is that the exam covers tools a candidate can install and study in a compatible Kubernetes test cluster today.