eBPF Beats Sidecars
For years, the “Sidecar” has been the darling of the Kubernetes world. It was the elegant solution to a messy problem: how do you add security and logging to an app without changing its code? You just sit a “helper” container right next to it.
But as our clusters have grown, the sidecar model has started to show its age. It’s heavy, it has blind spots, and it’s surprisingly easy to bypass.
The Sidecar Model:
In Kubernetes, a sidecar is an extra container that lives inside your pod. It’s like a personal assistant for your application, handling tasks like:
- Traffic Proxying: Deciding where requests go (Service Mesh).
- Observability: Sniffing logs and metrics.
- Security: Watching for suspicious activity within that specific pod.
It’s a great concept, but it relies on a critical assumption: that the assistant is actually in the room.
The Hidden Flaws of Sidecars
For a sidecar to work, it must be injected into every single pod. If a developer skips a namespace, or if an automated script fails, that workload is now invisible to your security team. In security, if coverage isn’t 100%, it might as well be 0%.
Every sidecar is an extra process. If you have 1,000 pods, you are running 1,000 extra containers. This eats up your CPU and RAM, inflates your cloud bill, and makes your lightweight microservices feel incredibly heavy.
Why eBPF is a Game-Changer
eBPF flips the script. Instead of putting a guard inside every single room (the pod), eBPF places the guard in the foundation of the building—the Linux Kernel.
Because the kernel sits underneath everything, an eBPF-based security tool can monitor:
- Every network packet.
- Every file opened.
- Every process started.
- Every system call.
The Crypto Miner Reality Check
Think about an attacker who manages to sneak a crypto-mining app into your cluster.
- With Sidecars: The attacker isn’t going to “inject” your security sidecar into their malicious pod. They’ll just run the miner as a bare container. Your sidecar-based security will never even know it exists.
- With eBPF: The kernel sees a new process start and sees it trying to connect to a mining pool. Because the miner must use the kernel to talk to the internet, eBPF catches it instantly. You can’t hide from the kernel.
Sidecar Architecture (Per-Workload)
In the sidecar model, each application pod gets an additional container that observes and controls traffic for that pod only.
+------------------------------------------------------+
| Kubernetes Node |
| |
| +------------------+ +--------------------------+ |
| | Pod A | | Pod B | |
| | | | | |
| | +------------+ | | +------------+ | |
| | | App A | | | | App B | | |
| | +------------+ | | +------------+ | |
| | | Sidecar | | | | Sidecar | | |
| | | (proxy/sec)| | | | (proxy/sec)| | |
| | +------------+ | | +------------+ | |
| +------------------+ +--------------------------+ |
| |
| Traffic control/visibility happens *inside* each pod |
+------------------------------------------------------+
Key idea: If a pod does not have a sidecar, it may not be monitored or controlled.
Sidecar Blind Spot (No Injection = No Control)
This is the core security weakness: anything that runs without a sidecar can escape sidecar-based enforcement.
+------------------------------------------------------+
| Kubernetes Node |
| |
| +------------------+ +--------------------------+ |
| | Pod A | | Pod C (no sidecar) | |
| | | | | |
| | +------------+ | | +--------------------+ | |
| | | App A | | | | Unknown/Malicious | | |
| | +------------+ | | | workload | | |
| | | Sidecar | | | +--------------------+ | |
| | +------------+ | | | |
| +------------------+ +--------------------------+ |
| |
| Sidecar tool sees Pod A traffic... |
| ...but Pod C traffic may be invisible/uncontrolled |
+------------------------------------------------------+
Example: A crypto miner deployed without sidecar injection can still make outbound connections.
eBPF Architecture (Host-Level Visibility + Control)
With eBPF, enforcement moves closer to the kernel. Instead of being attached per pod, policies apply across the entire node.
+------------------------------------------------------+
| Kubernetes Node |
| |
| +------------------+ +--------------------------+ |
| | Pod A | | Pod B | |
| | +------------+ | | +------------+ | |
| | | App A | | | | App B | | |
| | +------------+ | | +------------+ | |
| +------------------+ +--------------------------+ |
| |
| +------------------+ +--------------------------+ |
| | Unknown Process | | Host Services/Agents | |
| | (e.g. miner) | | (kubelet, containerd) | |
| +------------------+ +--------------------------+ |
| |
| ------------------- Linux Kernel ------------------ |
| eBPF Programs (network, syscalls, file access...) |
| - observe everything |
| - enforce policies (allow/deny/drop) |
| --------------------------------------------------- |
+------------------------------------------------------+
Key idea: Even unexpected processes still use the kernel, so eBPF can see and control them.
Sidecars vs. eBPF: The Quick Breakdown
| Problem | Sidecar Approach | eBPF Approach |
|---|---|---|
| Visibility | Only inside the Pod | Whole Host + All Pods |
| Bypassability | Easy (just don’t inject it) | Impossible (Kernel-level) |
| Performance | High (CPU/Memory per pod) | Tiny (Global efficiency) |
| Reliability | Depends on Pod Lifecycle | Independent of Pods |
The Security Guard Analogy
Imagine a large office building:
- Sidecars are like giving every employee a personal bodyguard. It works as long as everyone follows the rules. But if a stranger sneaks in through the back door, they won’t have a guard, and they can roam the halls freely.
- eBPF is like having a state-of-the-art security system built into the walls, floors, and doors. No matter who you are or how you got in, every step you take is monitored by the building itself.