Moving Beyond CI/CD: Securing Kubernetes at Runtime with eBPF
Why pre-deployment container scans leave massive blind spots in production, and how kernel-native eBPF visibility stops zero-days in real-time.

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, or fileless memory injections.
Static security stops at the deployment line. Kubernetes runtime security picks up exactly where your CI/CD pipeline ends.
The Production Threat Model
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.
Once attackers bypass the perimeter, they typically target these primary vectors:
Container Escapes & Privilege Escalation: Breaking out of Linux namespaces to control the worker node.
Lateral Movement: Moving "east-west" across the cluster to probe backend databases.
Cryptomining: Silently hijacking CPU/memory resources.
Data Exfiltration: Using DNS tunneling to sneak sensitive data out of the cluster.
Supply Chain Attacks: Dormant malicious code in trusted images that only executes at runtime.
The Paradigm Shift: Kernel Level Security with eBPF
If a security tool lives entirely in user-space, it shares the same environment as the workloads it is trying to protect. If an attacker gains sufficient privileges, they can disable or blind these user-space security agents.
This is where Cilium Tetragon changes the game by leveraging eBPF (Extended Berkeley Packet Filter).
By leveraging eBPF, Tetragon shifts security monitoring out of user-space and directly into the Linux kernel. It attaches specific sensors—like kprobes (Kernel Probes) and tracepoints—to key execution points without modifying the core kernel source code. This turns the kernel into a powerful observability and enforcement layer that is significantly harder for attackers to evade.
Real-Time Process & Network Correlation
Simply knowing that a process is running is rarely enough. You need context. Tetragon provides real-time Process Ancestry and Network Correlation.
Consider this practical example:
If the
nginxbinary opens an outbound connection to serve a web request, it is normal behavior.But if
nginxsuddenly spawnsbash, and thatbashshell spawnscurlto initiate an outbound connection, you have a strong indicator of a compromised Reverse Shell.
By correlating process execution with network activity at the system-call level, eBPF allows you to distinguish routine application behavior from active compromises instantly.
Active Enforcement (Not Just Logging)
Tetragon doesn't just monitor; it enforces. Using a Kubernetes CRD called a TracingPolicy, you can instruct Tetragon to dynamically compile eBPF programs that actively block threats. If a malicious process triggers the policy, Tetragon can instantly terminate the offending process by sending a SIGKILL signal before the malicious behavior can complete.
Dive Deeper: See the Code & Architecture
Want to see exactly how to write a TracingPolicy to block network utilities like curl and wget inside your cluster?
We have published a comprehensive architectural guide that covers:
Full
TracingPolicyYAML configurations.How to detect fileless execution directly in RAM.
Achieving PCI-DSS (File Integrity Monitoring) and SOC 2 compliance using kernel-native visibility.
Scaling eBPF security on high-performance bare-metal dedicated servers.
👉 Read the Full Architectural Breakdown and Interactive Guide Here


