Cilium just put an explicit, operationally blunt note into the Istio integration docs: if you want Cilium's eBPF datapath and L7 policies to play nice with Istio's data plane, you must change Helm values and, in some cases, turn off parts of Istio.
That's not a small paragraph buried in architecture rationale — it's a precise checklist: configure Cilium's socket load balancer to operate only for host namespaces (so it doesn't intercept pod socket flows that expect Envoy first), enable CNI chaining rather than an exclusive CNI mode so other CNIs or overlays can coexist, exclude selected namespaces from Istio's ambient mesh (or apply a PeerAuthentication with mtls.mode=DISABLE in those namespaces), and disable Istio mTLS enforcement where you intentionally delegate L7 enforcement to Cilium. If you didn't expect to be asked to disable Istio mTLS in parts of your cluster, you're not the only one.
The runtime conflict nobody notices
The root cause is simple and painful: Cilium's eBPF datapath implements fast, sidecarless L7 capabilities using socket-level interception and an eBPF-based load balancer. Istio, whether deployed with sidecars or in ambient mode, expects to own identity, mTLS, and L7 routing at the data plane. Run both with default settings and you get two data-plane behaviors competing for the same packets — surprising latency regressions, duplicated or skipped policy enforcement, or silent mTLS handshake failures.
The recommendations in the docs are about avoiding those packet-level conflicts. Scoping the socket LB to host namespaces prevents Cilium from intercepting application sockets that should be handled by Envoy. Using CNI chaining (instead of forcing an exclusive CNI installation) preserves the ability for other CNIs or overlay behaviors to coexist. And where you want Cilium to enforce L7 policies, explicitly remove those namespaces from Istio's ambient mesh or apply a PeerAuthentication (spec.mtls.mode: DISABLE) so Istio does not break the delegated flows.
What this means in practice
- If you're using Cilium Service Mesh (sidecarless) for L7 policies and Istio for higher-level control, treat Istio as optional for data-plane functions in the namespaces where Cilium is authoritative. Expect to reverse some of Istio's defaults there.
- If you keep Istio sidecars everywhere and also enable Cilium's L7 features, audit traffic flows. You're likely to see either duplicated policy checks or missing telemetry because packets never hit the component that owns the policy.
This is overdue and correct. The ecosystem has been drifting toward hybrid deployments — CNI + eBPF mesh + legacy sidecars — and the documentation needed to stop being polite and start being prescriptive. Teams that keep both stacks fully enabled by default will spend days chasing "why did my policy not apply" bugs.
What to do (today)
-
Audit Cilium and Istio configuration. Set Cilium's socket LB to host-namespace-only mode and use CNI chaining (avoid exclusive-CNI installs) via your Cilium Helm/operator values or ConfigMap. For namespaces where Cilium will enforce L7, exclude them from Istio's ambient mesh or apply a PeerAuthentication with spec.mtls.mode: DISABLE.
-
Map ownership of L3/L4 vs L7 policies. Decide whether Istio will remain the identity/mTLS authority cluster-wide or whether you'll split responsibilities by namespace. Don't leave it ambiguous.
-
Validate observability paths. When delegating to Cilium, rely on Hubble and Cilium's L7 telemetry; don't assume Istio traces or Telemetry will appear unchanged unless you verify the flow.
If you want a short reference point on eBPF dataplane changes and sidecarless guidance, see our earlier coverage of Cilium's eBPF dataplane and sidecarless service-mesh guidance: Cilium eBPF dataplane and sidecarless mesh upgrade guidance.
Final take
This isn't a vendor land-grab; it's reality catching up to hybrid mesh deployments. The docs' explicit recommendations are the right move — platform teams need clear ownership boundaries when two high-performance data planes coexist. If your architecture still treats Istio as "always on" and assumes no one else touches packet handling, treat this update as a hard deadline: either carve responsibilities or expect subtle, intermittent outages and policy gaps.
Expect more of these operational clarifications as eBPF meshes move from experimental to default. The future of service mesh is hybrid control planes; the question is whether your team will define the seams or debug them in production.
Sources
- Cilium Documentation – Integration with Istio (updated July 13, 2026)
- Cilium Service Mesh – Overview of Sidecarless eBPF-based Mesh
- Isovalent Blog – Cilium Service Mesh: Everything You Need to Know
- Istio Blog – Scaling in the Clouds: Istio Ambient vs. Cilium
- Cilium GitHub – cilium/cilium Releases Feed