Why Tetragon Should Be Standard in Every Kubernetes Cluster: The Missing Runtime Security Layer
The Cloud Native Computing Foundation’s (CNCF) latest cloud native security whitepaper highlights that cloud native development can be modeled in four distinct phases that constitute the application lifecycle: “Develop,” “Distribute,” “Deploy,” and “Runtime.” The paradigm shift from traditional security to cloud native security entails treating security as an interdisciplinary field and embedding security directly into every phase of the application lifecycle.
In the ideal world, security checks and best practices during the development, distribution, and deployment phases would completely prevent any vulnerability from seeping into the runtime environment. However, in reality, this is far from the case. While pre-runtime security checks form a critical component of securing cloud native applications, the attack surface for typical Kubernetes clusters is vast and vulnerabilities still inevitably get past these checks. Securing the runtime environment forms the last line of defence against threats.
Just as we wouldn’t deploy a Kubernetes cluster without a CNI plugin or an ingress controller, we shouldn’t ship it without runtime security. This post makes the case that runtime security should be a default component of every Kubernetes deployment and that Tetragon is the best tool for the job.
Why Kubernetes Runtime Security Is Critical and How Tetragon Delivers It
The CNCF’s cloud native security whitepaper highlights that the cloud native runtime environment can be broken down into layers of interrelated components with distinct security concerns, e.g., hardware, host, operating system, network, storage, container image runtime, and orchestration. All these components interface at a single point—the kernel.
FIG 1: Runtime environment illustration from the CNCF security whitepaper.
Tetragon is built on eBPF, which operates from a unique vantage point within the kernel. This position allows Tetragon to collect security observability and enforce security policies at the deepest level of the system, covering the critical components that make up the runtime environment. With Tetragon, teams can monitor operating system integrity, observe network connections, track access to sensitive file paths and mount points, and more, all with minimal overhead and rich Kubernetes contextual awareness.
The CNCF cloud native security whitepaper also recommends that “the runtime environment of a container needs to be monitored and secured from a process, file, and network perspective”. Data from these components form what we define as the four golden signals of container security observability: process execution, network sockets, file access, and layer 7 network identity. Together, these four data points provide information throughout the lifecycle of containers, enabling operators to detect a breach, identify compromised systems, understand the impact of the breach, and remediate affected systems.
Tetragon monitors the four golden signals of container security observability and ties these data points to the Kubernetes metadata, providing full and contextual visibility into Kubernetes environments.
CLI: Sample compact Tetragon events for process, file access, and network monitoring.
Beyond visibility, Tetragon’s enforcement capabilities can be used to ensure only sanctioned processes operate within a container namespace, killing the defaulting process before any harm is done. In a survey from Red Hat’s State of Kubernetes Security Report 2024, more than half of the organizations surveyed found unauthorized process execution in their environments. The report highlights that “the top worry was unauthorized process execution, cited by 45% of respondents. However, 52% of respondents reported that their organization actually experienced some type of unauthorized process during the last 12 months alone. These findings underscore the importance of process visibility and monitoring in Kubernetes environments. Beyond just monitoring and observability, Tetragon’s enforcement capabilities can also be used to prevent unauthorized resource access attempts and malicious network activity, among other security use cases.
Organizations Are Losing Revenue and Customers Due to Security Incidents
The same State of Kubernetes Security Report notably highlights that 42% of organizations surveyed cite security as a top concern when it comes to container and Kubernetes strategies. Additionally, 46% of organizations reported losing revenue or customers due to a container or Kubernetes-related security incident. These findings emphasize how important it is to have robust Kubernetes security controls in place, not just for protecting workloads but also for safeguarding the wider health and reputation of the business. Without the proper security controls, organizations open themselves up to operational disruptions, compliance failures, and increased scrutiny from stakeholders and regulators.
The report also paints a broader picture of how security failures can ripple throughout an organization. That 46% figure isn’t just an abstract number; it represents real-world consequences like delayed product launches, stalled innovation, and reallocated resources away from growth and toward damage control. When security incidents happen, engineering teams often have to halt development to investigate, remediate, and fortify affected systems. Meanwhile, customer trust can quickly erode, especially in industries where data sensitivity and uptime are paramount. As trust declines, customers may seek alternatives, often choosing competitors perceived to take security more seriously. In this way, weak Kubernetes security doesn’t just affect technical teams; it becomes a barrier to business success and competitive differentiation.
Built for Kubernetes: How Tetragon Natively Secures the Runtime
Kubernetes has transformed how we deploy applications, but this dynamic nature makes the traditional perimeter security model impractical. Between ephemeral containers, auto-scaling workloads, and complex networking, security teams struggle to maintain visibility. Because containers share the host resources, a single vulnerability can affect the entire cluster. Similarly, a vulnerability in the host itself can leave its containers susceptible to attacks.
Tetragon is designed to help security teams detect and respond to runtime threats quickly and effectively in Kubernetes environments. By providing deep, real-time visibility into container activity with Kubernetes context, Tetragon enables teams to pinpoint threats, understand their scope, and take action before damage spreads. Tetragon empowers organizations to respond to security incidents with speed and precision.
This operational advantage is rooted in how Tetragon is designed. Security policies are defined using Kubernetes Custom Resource Definitions (CRDs), allowing teams to use the same declarative model they’re already familiar with. This not only simplifies policy creation and management but also ensures tight integration with Kubernetes itself. Tetragon supports CRI-O and containerd, the two dominant Kubernetes runtimes, making it compatible with a wide range of Kubernetes deployments. Security policies can be enforced with fine-grained Kubernetes context: from clusterwide rules to individual pods, workloads with specific labels, or even down to the specific container. These design decisions make Tetragon powerful and intuitive to operate in real-world Kubernetes deployments.
Tetragon in the Real World
While security controls like SELinux can significantly enhance security, they can be challenging to customize and integrate into operational environments. Traditional logging systems such as auditd fall short in cloud native environments because they lack container awareness. Network logs face a similar limitation since IP addresses in Kubernetes are ephemeral and workloads are in a constant flux. As a result, many teams try to repurpose traditional security tooling for Kubernetes environments. This often results in feature-limited and high-overhead results. In one case, deploying a variant of Osquery in Kubernetes led to resource contention that caused workload downtimes. These challenges highlight the need for a Kubernetes-native runtime security solution that is purpose-built for Kubernetes and cloud native platforms from the ground up.
Tetragon has become the standard for eBPF-based Kubernetes runtime security, with global organizations like Reddit adopting it as a default component in their Kubernetes clusters. In this KubeCon talk, Pratik Lotia, a security engineer at Reddit, shares how the team transitioned from Osquery to Tetragon and tailored its configuration to meet the unique challenges of monitoring large-scale Kubernetes environments like Reddit’s.
Runtime Is the Battleground, Tetragon Arms You to Win
The runtime environment is where real-world attacks unfold, often bypassing pre-runtime checks through zero-day exploits, misconfigurations, or insider threats. When Tetragon is deployed in your environment, if there is a compromise, a platform team will no longer be blind to an attacker exploiting the environment, escalating privileges, or moving laterally. Such malicious activity can be detected instantly and blocked, limiting the blast radius and buying precious time for incident response teams to act. Tetragon shifts the narrative from reactive to proactive, allowing operators to detect, understand, and respond to threats with the same agility, flexibility, and speed Kubernetes brings to application deployment. If security truly needs to be embedded throughout the entire application lifecycle, then the runtime must be a first-class citizen, and Tetragon makes that possible.
Just as Kubernetes brought standardization to application orchestration, Cilium brought standardization to container networking, and Tetragon brings a new standard to Kubernetes runtime security: one that is Kubernetes-native, highly performant, and built on the powerful foundation of eBPF. By delivering deep security visibility and enforcement in a Kubernetes-native design, Tetragon equips teams to secure their Kubernetes environments.
In the same way we wouldn’t deploy a Kubernetes cluster without a CNI or ingress controller, we shouldn’t deploy one without runtime security. Tetragon isn’t just another security tool. It’s the missing and last line of defense every Kubernetes cluster needs.
- Try Tetragon in a hands-on lab, earn a badge, and progress down the Security Engineer Track.
- Read more about the Tetragon 1.0 release – benchmarks, early use cases, and core principles behind the project.
- Keep up with the Tetragon community via the monthly community meetings.
- Join the Tetragon channel on the Cilium Slack.
Paul is a security-focused community builder at Isovalent – the company behind Cilium & Tetragon. Before joining Isovalent, Paul worked in the startup world as a backend and infrastructure-focused software engineer using various cloud-native technologies, including Kubernetes. Paul has also worked as a software engineering trainer, designing curriculum and content to train budding software engineers.
You can find Paul hanging out in various open-source communities and speaking at conferences like the Open Source Festival. Paul enjoys swimming, cycling, and mountain biking.
