If your container passes a CI/CD vulnerability scan, is it safe to run in production? Many engineering teams assume the answer is yes. But a clean image scan is just a green light to deploy—it is not a lifetime guarantee.
Pre-deployment gates, like static configuration checks and vulnerability scanning, are entirely predictive. They are designed to catch known risks (published CVEs) before your code goes live. However, they leave a massive blind spot once the container is actively running. A static scan cannot protect you from a zero-day exploit, a compromised third-party dependency executing malicious behavior at runtime, or an attacker leveraging legitimate tools to move laterally across your network.
Static security stops at the deployment line. Kubernetes runtime security picks up exactly where your CI/CD pipeline ends.
Instead of just checking the blueprint, runtime security is the continuous, active surveillance of your live environment. It monitors system calls, file integrity, and network connections as the code executes. In this guide, we will break down the modern Kubernetes threat model and show you why traditional K8s container security falls short in production. More importantly, we will explore how Cilium Tetragon leverages eBPF threat detection to provide kernel-native visibility, detecting and responding to attacks in real time.
As a dedicated infrastructure provider at Servers99, we see firsthand that true security requires moving from passive scanning to active enforcement. Here is exactly how to secure your Kubernetes workloads at runtime.
Why Traditional Container Security is Failing in Production
For years, the gold standard for cloud-native security has focused heavily on "shifting left"—securing the blueprint before deployment. While vulnerability scanning is a critical checkpoint in your CI/CD pipeline, it is essentially predictive
Relying exclusively on pre-deployment checks leaves massive blind spots in your overall Kubernetes threat model. A clean container image is not a shield against active, in-progress attacks. Here is exactly why traditional methods fall short once your workloads enter production:
- The Zero-Day Blind Spot: Traditional scanning tools compare your container's filesystem against known threats cataloged in public CVE databases. They are powerless against zero-day exploits or vulnerabilities in proprietary code that have not yet been discovered by the broader security community.
- Configuration Drift and Memory Injections: An image might be perfectly secure when it passes through the CI/CD pipeline, but the runtime environment is highly dynamic. Attackers can exploit misconfigured Kubernetes APIs or vulnerable environment variables to inject malicious payloads, modify binaries, or execute unauthorized code directly into memory—bypassing static file checks entirely.
- Insider Threats and Credential Theft: Perimeter defenses provide zero protection if an attacker already holds the keys. If a malicious actor steals valid credentials or exploits a trusted supply chain dependency, they walk right past your initial security gates. Without active runtime monitoring, their lateral movement and post-exploitation behaviors may go unnoticed by traditional container security controls.
Containers do not provide a hard security boundary. Because every pod on a worker node shares the same underlying host operating system, an exploit in the shared Linux kernel can compromise the entire node. This is why a reactive approach is no longer viable for modern infrastructure.
The Kubernetes Runtime Threat Model (What Attackers Actually Do)
To defend a Kubernetes cluster effectively, you must understand how attackers operate once they bypass your perimeter defenses. In a modern cloud-native environment, the perimeter is highly porous. An attacker might exploit a vulnerability in a public-facing application or activate malicious code embedded within a compromised dependency.
Once inside the cluster, the threat model unfolds across five primary attack vectors:
Container Escape & Privilege Escalation
It is crucial to remember that containers are not virtual machines; they are simply isolated processes. They primarily rely on Linux namespaces for isolation and cgroups for resource control, all enforced by the shared Linux kernel.
If an attacker compromises a pod, their immediate goal is to
break out of this isolation. By exploiting a vulnerability in that shared kernel or
abusing K8s misconfigurations (such as pods running with
privileged: true or mounting host filesystems), the attacker can escape
the namespace boundary. This may allow an attacker to escalate privileges and
potentially gain control of the underlying worker node.
Lateral Movement (East-West Traffic)
Once a foothold is established, attackers attempt to map the internal network and move "east-west" across your cluster. In many Kubernetes deployments without restrictive network policies, pods can communicate freely with one another. This means a compromised frontend container can directly probe a backend database or internal API. Because traditional firewalls focus on north-south (ingress/egress) traffic, this internal lateral movement requires identity-aware runtime network monitoring to detect and stop.
Cryptomining & Resource Abuse
Not all attacks are designed to steal sensitive data; many simply aim to hijack your compute infrastructure. Cryptomining is one of the most common runtime threats. Attackers silently deploy malicious payloads that aggressively consume your cluster's CPU and memory. Without strict runtime monitoring, these unauthorized processes can starve your legitimate applications of resources and drive up your infrastructure bills.
Data Exfiltration
For breaches targeting proprietary code, customer databases, or API keys, the final step is getting the data out. At runtime, data exfiltration often looks like a legitimate pod suddenly initiating outbound TCP connections to an unknown external IP address. Advanced attackers may also use DNS tunneling—encoding stolen data into standard DNS queries—knowing that many Kubernetes environments permit outbound DNS traffic by default, making DNS tunneling difficult to detect without runtime visibility.
Supply Chain Attacks
Sometimes, the threat originates from inside the house. Supply chain attacks occur when malicious code is injected into a trusted open-source dependency or a widely used base image. These payloads may evade traditional CI/CD vulnerability scans and only reveal malicious behavior once deployed. These payloads may remain dormant during deployment and only exhibit malicious behavior at runtime to spawn unauthorized processes, download secondary malware, or phone home to Command and Control (C2) servers.
Enter Cilium Tetragon: eBPF-Powered Kernel-Level Visibility
If a security tool lives entirely in user-space, it shares the same environment as the workloads it is trying to protect. This creates a critical architectural vulnerability: if an attacker gains sufficient privileges on the host, they may be able to disable, blind, or interfere with user-space security agents before executing their primary payload.
Cilium Tetragon changes this paradigm by shifting security monitoring out of user-space and directly into the operating system using eBPF (Extended Berkeley Packet Filter).
Why User-Space Security Falls Short
In any Linux-based system, the kernel is ground zero.
Applications and containers cannot independently access the network, read a file, or
spawn a new process. They must request the kernel to execute these actions on their
behalf via system calls (syscalls).
Because traditional user-space tools sit outside this stream, they rely on
asynchronous log parsing or interception methods that can be bypassed if the
user-space environment is compromised.
How eBPF Moves Security into the Kernel
By leveraging eBPF, Tetragon compiles and executes security
logic directly within the Linux kernel. This turns the kernel into a powerful
observability and enforcement layer that remains significantly harder for
compromised workloads to evade.
To achieve this deep, system-wide visibility without modifying the core kernel
source code, Tetragon attaches specific eBPF sensors to key execution points:
- kprobes (Kernel Probes): These are dynamic sensors that allow Tetragon to attach an eBPF program to internal functions inside the Linux kernel. For example, if you need to monitor exactly when the kernel function responsible for opening files is triggered, a kprobe intercepts the execution, records the system context, and safely returns control.
- tracepoints: Unlike dynamic kprobes, tracepoints are static, hardcoded markers intentionally placed within the source code by Linux kernel developers. They are highly stable across different kernel versions, making them incredibly reliable for observing standard, high-volume behaviors like system call execution and network packet transmission.
- Huprobes (User Probes): While kprobes and tracepoints monitor the kernel, uprobes watch user-space applications. Tetragon can use uprobes to hook directly into the functions of a running application or shared library. A highly effective use case is attaching a uprobe to an SSL/TLS library (like OpenSSL) to inspect data before it gets encrypted and sent over the network.
Performance at Scale
Some traditional monitoring approaches can introduce noticeable
overhead at scale, particularly when collecting large volumes of system events. eBPF
minimizes this overhead by executing logic directly inside the kernel and using
efficient BPF maps for event collection and filtering, drastically reducing
expensive context switching between kernel-space and user-space.
When running production Kubernetes clusters on [Servers99 Dedicated Servers],
kernel-level visibility helps maintain strong runtime security without sacrificing
bare-metal performance, allowing you to scale rigorous security policies without
introducing application latency.
Real-Time Process & Network Monitoring
The most fundamental signal in runtime security is the execution of processes. Every attack—whether it is a sophisticated data exfiltration campaign or a simple lateral movement script—must eventually execute code. However, simply knowing that a process is running is rarely enough to determine malicious intent. You need context.
This is where Process Ancestry and Network Correlation become critical.
In a Linux system, processes create a parent-child relationship. Understanding the execution chain (who started what) is the key to reducing false positives. Furthermore, network security in a cloud-native environment requires connecting the runtime process identity to network behavior. A traditional firewall tells you that "Pod A connected to IP B." Tetragon’s process-to-network correlation identifies which binary and process lineage opened the socket.
To put it in practical terms: If the nginx binary
opens an outbound connection to serve a web request, it's normal. But if
nginx spawns bash, and that bash shell spawns
curl to initiate an outbound connection, you have a strong indicator of
suspicious activity. By correlating process execution with network activity at
the kernel level, security teams can instantly distinguish routine application behavior
from active compromises.
Detecting Reverse Shells & Fileless Execution
A reverse shell is a common post-exploitation technique where a
compromised container initiates an outbound connection back to an
attacker-controlled Command and Control (C2) server. Because many Kubernetes
environments allow outbound traffic by default, these outbound connections often
succeed. Tetragon’s ability to map network sockets back to unusual process trees
(like sh or netcat initiating a connection) significantly
improves the detection of reverse shell activity.
Attackers also know that traditional antivirus and security scanners monitor the
disk for malicious files. To bypass this, they increasingly rely on fileless
execution. By using Linux utilities like memfd_create, attackers can
download payloads directly into RAM and execute them without ever writing a file to
the physical disk. Because eBPF hooks into the process execution system calls (like
execve) inside the kernel, it detects and logs the execution regardless
of whether the file exists on disk or only in memory.
Stopping DNS Exfiltration
Data exfiltration does not always happen over obvious HTTP or
TCP connections. Attackers frequently use DNS tunneling to sneak sensitive data out
of a cluster. They encode stolen data, such as API keys or hashed passwords, into
standard DNS queries (e.g., user-password-hash.malicious-domain.com).
Since legitimate applications need DNS resolution to function, many K8s environments
permit outbound DNS traffic by default, creating a massive blind spot. Tetragon can
correlate DNS-related network activity with the originating process, providing
visibility into which workloads are generating DNS requests. This allows
infrastructure teams to enforce policies that restrict which specific processes are
allowed to make DNS queries, or to identify unexpected DNS activity originating from
unusual processes, effectively neutralizing a stealthy exfiltration vector.
Writing Tetragon Tracing Policies (With Examples)
Moving from theory to practice, Tetragon defines its security rules
using a Kubernetes Custom Resource Definition (CRD) called a TracingPolicy.
When you deploy a TracingPolicy, you are not just writing a standard
firewall rule; you are instructing Tetragon to dynamically compile eBPF programs and
attach them directly to the Linux kernel's execution path.
A well-structured TracingPolicy consists of three core components: Hook Points, Selectors, and Actions.
Hook Points
The hook point defines where in the kernel Tetragon should attach its sensors. This is the entry point of your policy. Depending on the behavior you want to observe or block, you can attach to a system call, an LSM (Linux Security Module) internal function, or a raw tracepoint. By explicitly defining the hook point, Tetragon knows exactly which kernel function triggers the policy evaluation.
Selectors
Hooking into a high-volume system call without filtering can generate a large volume of events and degrade system performance. Selectors solve this by applying strict, in-kernel filters. They dictate when the policy should trigger. Instead of sending every event to user-space for evaluation, eBPF allows selectors to evaluate conditions directly inside the kernel. You can filter by:
-
matchBinaries: Triggers only if the executing binary matches a specific
path (e.g.,
/usr/bin/curl). - matchArgs: Triggers based on the arguments passed to the kernel function (e.g., a specific file path or network socket).
- matchCapabilities: Triggers based on the Linux capabilities held by the process.
Actions (Post, Sigkill, Override)
Once a hook point is triggered and the selector conditions are met, Tetragon executes the matchAction. This defines what happens next. Common enforcement and observability actions include:
- Post: The default observability action. It generates an event and sends it to user-space for logging, SIEM ingestion, or alerting, without disrupting the running process..
- Sigkill:
A strong enforcement action. It instantly terminates the offending process by sending a
SIGKILLsignal before the malicious behavior can complete. -
Override: A less disruptive enforcement mechanism. Instead of killing the process, Tetragon can override the kernel function's return value. For example, it can return an
-EPERM(Operation not permitted) error code. To the application, it simply appears as a standard permission denial, which prevents the action without unexpectedly crashing the entire container.
Actionable Example: Blocking Network Utilities
Attackers frequently use legitimate tools like curl or wget to download secondary payloads or exfiltrate data. The following sample TracingPolicy uses a kprobe to hook directly into the kernel's execution check function (security_bprm_check), filters for specific binaries, and instantly kills the process upon detection.
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "block-network-utilities"
annotations:
description: "Terminate curl and wget to prevent lateral movement"
spec:
kprobes:
- call: "security_bprm_check"
syscall: false
args:
- index: 0
type: "linux_binprm"
selectors:
- matchBinaries:
- operator: "In"
values:
- "/usr/bin/curl"
- "/usr/bin/wget"
matchActions:
- action: Sigkill
By applying this policy via standard Kubernetes tooling (kubectl apply -f policy.yaml), the policy is distributed through Kubernetes and enforced by Tetragon on the relevant cluster nodes.
Achieving Security Compliance in K8s (PCI-DSS & SOC 2)
While security engineers focus on threat models and exploit mitigation, leadership and governance teams are primarily concerned with risk management and compliance. Integrating robust K8s container security measures at runtime is essential for businesses operating environments that handle credit card data, healthcare records, or sensitive user information. You must prove to auditors that your environment is continuously monitored and secure.
Modern compliance standards, including NIST SP 800-190 (Application Container Security Guide), strongly recommend runtime monitoring and behavioral visibility for containerized environments. A clean CI/CD pipeline scan is not enough to pass a rigorous audit. This is where eBPF-powered tools bridge the gap between technical security and business compliance.
File Integrity Monitoring (FIM) for PCI-DSS
PCI-DSS requires organizations to implement file integrity monitoring (FIM) controls capable of detecting unauthorized modifications to critical system files, configuration files, and content. In traditional VM environments, FIM is relatively straightforward. In ephemeral Kubernetes environments, it is notoriously difficult.
Older user-space FIM tools rely on Linux features like inotify, but large-scale inotify-based monitoring can become challenging in dense, highly dynamic container environments. By observing relevant filesystem operations at the kernel level, eBPF-based monitoring provides highly detailed visibility into file access and modification activity. This provides auditors with a high-fidelity audit trail of exactly which process and container modified a sensitive file, without the performance penalty of traditional FIM agents.
Process-Level Egress Security for SOC 2
To achieve SOC 2 compliance, particularly the Confidentiality and Privacy trust service criteria, organizations must demonstrate appropriate controls to detect and reduce the risk of unauthorized data exfiltration.
Traditional network security relies on IP-based firewalls, which lose their meaning in Kubernetes where pod IPs change constantly. While K8s NetworkPolicies help, they only restrict traffic at the pod level. eBPF enhances egress security by providing process-level network visibility. If an auditor asks, "How do you ensure your database pods only communicate with authorized endpoints?", Tetragon allows you to definitively prove not just that a pod initiated the connection, but that the specific, authorized database binary made the request. Policies can be configured to log or block anomalous outbound connections from unexpected binaries, providing the stringent egress controls required for SOC 2 audits.
Conclusion & Next Steps for Your Infrastructure
A strong Kubernetes security strategy increasingly benefits from a Zero-Trust approach—one that doesn't simply trust a container because it passed an initial CI/CD scan, but actively verifies behavior as code executes. Effective Kubernetes runtime security requires visibility into process execution, network activity, and file access across every workload.
As cloud-native architectures continue to evolve and traditional network perimeters dissolve, kernel-native visibility is becoming a foundational component of modern cloud-native architectures. Leveraging eBPF to monitor process execution, file access, and network correlations directly within the Linux kernel provides one of the most effective approaches for detecting and responding to advanced runtime threats, with significantly lower overhead than many traditional monitoring approaches.
However, running continuous kernel-level monitoring alongside high-traffic microservices requires a solid hardware foundation. Deploying your Kubernetes workloads on Servers99 dedicated servers provides the reliable, bare-metal compute power needed to enforce these rigorous security policies seamlessly. It ensures that your infrastructure can handle advanced observability and threat protection while maintaining the performance characteristics expected from dedicated bare-metal infrastructure.
