For years, the service mesh blueprint was undisputed: inject a sidecar proxy (typically Envoy) into every single pod. While this pattern revolutionized mutual TLS (mTLS) enforcement, traffic routing, and observability, it exacted a heavy toll in memory consumption, CPU overhead, and operational complexity. Every application container was chained to a helper container that had to be life-cycled, updated, and resources-provisioned.
In 2025, the cloud-native ecosystem has definitively crossed the chasm into sidecarless service meshes. This architectural paradigm shift decouples layer 4 (transport/identity) secure communication from layer 7 (application-level routing/policies) processing, dramatically reducing resource footprints while maintaining robust cryptographic identities.
In this deep-dive article, we will dissect the two titans of sidecarless mTLS: Istio Ambient Mesh and Cilium eBPF (with Cilium Service Mesh). We will analyze their architectures, compare their performance profiles under heavy workloads, map out their PKI integration patterns, and help you choose the right path for your Kubernetes clusters.
Sidecar vs. Sidecarless Architectural Evolution
How network interception has evolved from Pod-level Sidecars to Node-level Shared Agents.
Pod-level Interception
Every Pod runs its own Envoy proxy. High memory footprint, localized resource consumption, complex lifecycle management.
ZTUNNEL + Waypoint Proxy
Split architecture: Node-level HBONE daemon (ztunnel) handles L4/mTLS. Optional Waypoint Envoy proxies handle L7 policies per Namespace.
In-Kernel Cryptography & Shared Envoy
eBPF redirects socket data directly. SPIRE manages PKI identities. Node-level Envoy proxy handles L7, while IPSec/WireGuard or mTLS is processed dynamically.
Architectural Underpinnings: How They Work
1. Istio Ambient Mesh: The Dual-Layer Split Architecture
Istio Ambient Mesh abandons the pod injection model entirely, segmenting its data plane into two specialized, shared operational layers:
- Ztunnel (Zero Trust Tunnel): A highly optimized, Rust-based daemon running on every node. Ztunnel operates strictly at Layer 4 (L4). It intercepts outbound and inbound traffic for all mesh pods on the node, managing mTLS connection pooling, cryptographic identity validation, and telemetry. It encapsulates connections using HBONE (HTTP-Based Overlay Network Engine), which encapsulates standard TCP traffic inside HTTP/2 CONNECT tunnels secured via TLS 1.3.
- Waypoint Proxies: When application-layer (L7) rules, header-based routing, authorization policies, or retries are required, Ambient deploys a Waypoint Proxy. Waypoints are standard Envoy proxies deployed on a per-namespace or per-service-account basis, completely detached from the application pod’s lifecycle.
Because L4 security is decoupled from L7 processing, a malicious pod compromising its own application container cannot bypass the L4 security boundary—the node's ztunnel daemon remains isolated and secure outside the pod's boundary.
2. Cilium eBPF: Direct Kernel-Space Processing
Cilium leverages the Linux kernel’s native observability and manipulation capability via Extended Berkeley Packet Filter (eBPF). Instead of routing traffic through user-space loops or local network namespaces using iptables, Cilium attaches programs directly to kernel socket structures (such as sockmap) and network interface traffic control (TC) hooks.
In Cilium's sidecarless model:
- eBPF Socket Layer Interception: When application container A talks to container B on the same node, eBPF short-circuits the TCP/IP stack entirely, copying data directly from socket-to-socket in kernel space.
- mTLS Delegation & SPIFFE/SPIRE: Cilium integrates natively with SPIFFE/SPIRE to retrieve cryptographic node and workload identities. When mTLS is enforced, eBPF intercepts the socket flow and delegates the handshakes to a node-local Envoy proxy or relies on kernel-level IPsec/WireGuard for transport-layer encryption, using Envoy strictly for application identity handshakes.
🛡️ Istio Ambient Mesh
Ideal for enterprises seeking a familiar policy plane with zero application-pod intrusion.
Pros
- Maintains identical Istio CRD/API compatibility.
- Clear architectural separation between L4 (mTLS) and L7 (Routing).
- Zero changes required to existing K8s Pod templates.
- Low resource footprint when only L4 is active.
Cons
- HBONE encapsulation adds tunnel wrapper overhead.
- Requires provisioning dedicated Waypoint Proxies for L7 policy enforcement.
⚡ Cilium eBPF Service Mesh
Ideal for high-throughput, latency-critical clusters pushing the limits of Linux performance.
Pros
- Extremely fast socket redirection (bypasses TCP/IP stack locally).
- In-kernel crypto offloading (WireGuard/IPsec) runs at line-rate.
- Native SPIFFE/SPIRE architecture integration.
- Consolidated CNI and mesh plane in a single platform.
Cons
- Requires modern Linux kernels (v5.10+ recommended).
- Steep learning curve for custom eBPF debugging and observability.
Cryptographic Workload Identity and PKI Deep Dive
How do sidecarless models securely establish identity? Let's analyze how both systems bootstrap mutual TLS (mTLS) identities without inserting a proxy helper directly inside the application's network namespace.
Istio Ambient PKI & Ztunnel Bootstrapping
In Istio Ambient Mesh, workloads do not hold their own cryptographic material. Instead, the Ztunnel daemon running on the node requests, caches, and uses SPIFFE identities on behalf of all the pods on that node. It communicates with istiod (which acts as the Certificate Authority) using the istio_ca protocol.
When a pod starts on Node A, the local Ztunnel daemon notices the pod creation via the Kubernetes API server or local CRI monitoring. It verifies the pod's ServiceAccount token and calls istiod to perform a Certificate Signing Request (CSR) for that specific pod's identity:
# Ztunnel requests a cert for Pod 'payment-v1' running on ServiceAccount 'payments-sa' CSR request details: Subject Alternative Name (SAN): spiffe://cluster.local/ns/finance/sa/payments-sa Issuer: istio-ca (or HashiCorp Vault / cert-manager) Private Key: Kept securely within Ztunnel memory, never exposed to the application pod!
Cilium, SPIFFE, and Kernel-Assisted mTLS
Cilium takes a modular approach. Instead of managing its own CA, it decouples certificate issuance to standard, enterprise-grade identity systems like SPIRE (SPIFFE Runtime Environment). Through a SPIRE Agent running on each node, workloads are assigned a secure cryptographic identity based on a combination of container runtime attributes (e.g., UID, namespace, and labels).
When two pods on different nodes communicate using Cilium's mTLS engine:
- eBPF captures the initial connection handshake.
- It verifies if an L7 policy mandates mTLS.
- It delegates the handshake to the node's local Envoy instance, which mounts SPIFFE-issued SVIDs (X.509 Certificates) supplied by the local SPIRE agent.
- Once the mutual handshake completes, socket telemetry is mapped dynamically, allowing fast kernel-level encryption of the data stream.
The Core Architectural Comparison at a Glance
Network Interception
Istio Ambient: eBPF or iptables redirects traffic locally to ztunnel daemon.
Cilium: eBPF hooks direct at the socket level (tc/sockmap).
mTLS Protocols
Istio Ambient: TLS 1.3 encapsulated in HBONE (HTTP/2 CONNECT).
Cilium: SPIRE/SPIFFE managed TLS, or pure Kernel IPsec/WireGuard.
Resource Footprint
Istio Ambient: Shared ztunnel (< ~50MB per node). Waypoints optional.
Cilium: Shared agent + eBPF maps. Lowest overall overhead.
Configuration Deep Dive: Setting Up Sidecarless mTLS
Let's look at how to declare policy configurations for both meshes. Notice the total absence of sidecar annotation boilerplates in the application manifests.
1. Istio Ambient: Enforcing mTLS globally with PeerAuthentication
To enforce strict mutual TLS in an Istio Ambient-enabled namespace, you only need a single declarative resource. Ztunnel automatically manages the HBONE tunnels without needing any restarts or modifications to the application pods.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: e-commerce
spec:
# STRICT mode enforces that all connections must use HBONE/mTLS
mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-internal-only
namespace: e-commerce
spec:
selector:
matchLabels:
app: checkout
action: ALLOW
rules:
- from:
# Restricts incoming traffic to specifically trusted workloads
- source:
principals: ["cluster.local/ns/e-commerce/sa/frontend-sa"]
2. Cilium Service Mesh: CiliumClusterwideNetworkPolicy (Cilium L7 mTLS)
In Cilium, you define a network policy that explicitly binds authentication criteria to the transport handshake. SPIFFE identities are validated during packet transit in the cluster.
apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
name: "enforce-mtls-checkout"
spec:
description: "Enforce SPIFFE-validated mutual TLS between Frontend and Checkout"
endpointSelector:
matchLabels:
app: checkout
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
# Layer 7 verification delegates to local SPIFFE agent
http:
- method: "POST"
path: "/charge"
# Cilium delegates authentication check to SPIRE identity plane
authentication:
mode: "required"
spiffe:
trustDomain: "cluster.local"
identity: "spiffe://cluster.local/ns/production/sa/frontend-service-account"
---
Performance & Feature Matrix
The following table provides an analysis of the architectural trade-offs between legacy sidecars, Istio Ambient, and Cilium eBPF based on real-world engineering metrics in 2025.
| Feature / Metric | Legacy Istio (Sidecar) | Istio Ambient (Ztunnel) | Cilium Service Mesh |
|---|---|---|---|
| Network Hop Overhead | App ⇆ Sidecar (User) ⇆ Network | App ⇆ Node Ztunnel (Rust) | Direct Kernel-to-Kernel |
| Memory Usage (Per Pod) | 30MB - 100MB+ | 0 MB (Shared Ztunnel model) | 0 MB (Shared Agent model) |
| Pod Lifecycle Coupling | Strictly coupled (Requires restart) | Completely decoupled | Completely decoupled |
| Primary Encryption Engine | Envoy TLS 1.3 | Rustls (via HBONE) | Kernel WireGuard / IPsec / Envoy |
| PKI Integration | Istio Agent DNS/ALTS | Istiod CA Native Push | SPIRE/SPIFFE Workload APIs |
Performance Under the Hood: CPU, Latency, and Kernel Bypass
When selecting your sidecarless strategy, understanding performance realities under microservices traffic spikes is critical. Here is how they benchmark:
1. Latency Profiles (P99)
Traditional sidecars add ~1.5ms to 3.0ms of latency per hop because data leaves kernel space to enter the sidecar's network namespace twice (once on the client side, once on the server side).
Cilium eBPF minimizes this penalty. For local connections on the same node, eBPF completely bypasses the local TCP/IP stack (short-circuiting TCP ip_output pathways). When sending data across nodes, Cilium utilizing WireGuard in-kernel encryption achieves near-line-rate throughput with an added latency overhead of less than 0.1ms.
Istio Ambient Ztunnel, utilizing HBONE over HTTP/2, introduces minimal latency (~0.3ms to 0.7ms). This is slightly higher than Cilium due to user-space context switching into Ztunnel but represents an immense 75% reduction compared to sidecars.
2. Memory Consumption Scaling
In a cluster containing 500 pods, the legacy sidecar model consumes upwards of 25 GB of cluster memory purely to run Envoy processes (assuming a modest 50MB per sidecar proxy).
In Istio Ambient Mesh, only one Ztunnel daemon (~35-50MB RAM) runs per node. Across a 10-node cluster, the total memory overhead of the security layer drops to around 500MB total, a massive reduction in resource footprint that allows for higher container density and lower cloud bills.
---💡 Pro Tips for Sidecarless mTLS Deployments in 2025
Conclusion: Deciding Your Architectural Path
Both Istio Ambient Mesh and Cilium eBPF have declared an end to the "one-sidecar-per-pod" era. The decision of which architecture to adopt hinges on your existing infrastructure:
- Choose Istio Ambient Mesh if you are already invested in the Istio ecosystem, rely extensively on complex L7 traffic steering, custom WASM plugins, or enterprise VirtualService policies, and want to gain massive performance benefits without abandoning the native Istio control plane.
- Choose Cilium eBPF if you are building high-scale clusters from scratch, need the absolute lowest possible latency profile, want unified networking (CNI) and service mesh security under one roof, and have the administrative expertise to manage modern Linux kernel configurations.