Cilium Gateway API: The eBPF and Envoy Reality Pass

Most platform teams installing Cilium for Gateway API think they’re pulling off a slick architectural heist.

The pitch sounds irresistible: sweep out the legacy kube-proxy iptables mess, delete your standalone ingress deployment, and let eBPF handle your edge routing directly inside the Linux kernel. Zero sidecars, zero extra hops, maximum throughput.

Except that’s not how Layer 7 routing works.

An eBPF program attached to a socket or TC hook cannot parse an HTTP Host header, evaluate a complex path rewrite, or execute a TLS handshake directly inside kernel space without killing the node. To handle actual Gateway API spec requirements, Cilium relies on a dirty secret: it seamlessly punt packets out of eBPF and into an embedded, node-level Envoy proxy.

If you don't understand where eBPF stops and Envoy starts, your "optimized" cluster networking is an architectural landmine.

Here is the real execution model of Cilium’s Gateway API controller, how to wire production CRDs without getting burned by cross-namespace permissions, and why your network policy rules might be silently ignoring your gateway traffic.

The Architecture: Kernel Fast Path vs. The Envoy Pitstop

When traffic hits a Cilium-managed cluster via a Gateway resource, the packet execution path splits into two distinct operational modes.

The L4 Fast Path (eBPF): If your Gateway only handles raw L4 traffic (TCP/UDP), Cilium handles connection tracking, NAT, and BPF map lookups directly in kernel space using eBPF hooks. kube-proxy is dead, and iptables rules are never touched.

The L7 Trapdoor (Envoy): The moment you declare an HTTPRoute with path prefixes, header manipulations, or TLS termination, eBPF redirects the TCP socket to a node-level Envoy daemon running inside the cilium-agent.

You didn't eliminate the proxy. You just embedded it into your CNI daemonset.

The Prerequisites: Prerequisites Everyone Omits

If you try to apply a Gateway API spec to a default Cilium installation, nothing happens. Cilium will ignore the CRDs completely unless you boot cilium-agent with explicit flags.

Your Helm value override file must enforce full kube-proxy replacement and explicitly enable the L7 engine:

If kubeProxyReplacement isn't set to true, eBPF socket-layer load balancing fails, and Cilium falls back to legacy iptables hooks for backend pod routing—defeating the entire purpose.

The Blueprint: Multi-Namespace Production Setup

In a real environment, cluster operators own the Gateway, and app teams own the HTTPRoute.

Here is the exact declarative pattern required to run a shared Cilium Gateway with strict cross-namespace security boundaries.

The Gateway Infrastructure (Operator Domain)

Cross-Namespace Secret Permission (ReferenceGrant)

By default, the Gateway in gateway-system cannot read a TLS Secret or attach an HTTPRoute residing in another namespace. If cert-manager drops the TLS certificate into a core infrastructure namespace, you must explicitly allow the Gateway to reference it:

The Application Route (Developer Domain)

The Trap: CiliumNetworkPolicy vs. Gateway API

This is where platform engineers break production.

Because Cilium processes ingress traffic through its embedded Envoy instance, the source IP of the packet hitting your target application Pod is not the external client IP. It is the IP of the local Cilium Envoy proxy.

If you write a standard CiliumNetworkPolicy expecting to filter traffic by external client IP CIDRs at the backend application Pod, it will silently fail or lock out valid traffic:

The Fix:

To apply security policies to Gateway API routes, you must target the identity of the ingress gateway itself, or use Cilium's L7 request-aware matchers:

The Verdict

Cilium's implementation of the Gateway API is easily the highest-performing option on the market for Kubernetes platforms—if your primary goal is kernel-level L4 efficiency and tool consolidation.

By running Gateway API inside the CNI, you drop kube-proxy, strip out NGINX sidecars, and get out-of-the-box Hubble telemetry for every single HTTP route.

Just don't fall for the marketing hype that Envoy vanished. It just moved into the kernel's passenger seat.

-----

For details regarding how Cilium routes Layer 7 traffic through its embedded or standalone Envoy proxy, as well as the prerequisites for configuring low-port host network capability bindings (NET_BIND_SERVICE), refer to the official documentation:

• Cilium Service Mesh Guide: Cilium Gateway API Support Documentation
• Cilium Proxy Runtime Specifications: Cilium Envoy Proxy Deployment Architecture

For verification on how the CNI masks client source IPs via Envoy and why security boundaries must rely on the reserved ingress identity rather than standard backend IP blocks, consult the security and policy configuration sheets:

• Ingress Telemetry & Policy Rules: Kubernetes Ingress Support — Cilium Core Documentation
• Custom Policy Constructs: Cilium Network Policy Specifications