Service Mesh Field Report #6
Allow locally, prevent mesh-wide
This is an English translation. The report was first published in German. Read the German original
Last week covered a gap in standard Istio setups: a VirtualService with the gateways: mesh option affects every sidecar in the mesh, across namespace boundaries. A tenant can use it to reroute traffic that isn’t theirs.
The obvious reaction would be to revoke tenants’ permissions on Istio resources. That would be the wrong fix. It destroys exactly the autonomy that a clean ownership model is built on. Tenants should keep managing their own VirtualServices, DestinationRules, and ServiceEntries.
The right boundary runs elsewhere: local effect belongs to the tenant, mesh-wide effect belongs to the platform team. A tenant can build anything inside their own namespace. What they can’t do is reach into the rest of the mesh.
Three levers enforce exactly that:
defaultExportTo in the MeshConfig. Set to the resource’s own namespace, Istio resources are no longer visible mesh-wide by default. This is the central platform-level lever that flips the default from open to local behavior.
Sidecar egress scoping. Limiting each sidecar’s egress to the namespaces it actually needs cuts config push and Envoy memory significantly. Most teams do this for performance. The side effect: it also contains the mesh-wide reach of someone else’s VirtualService. One lever, two problems solved.
Enforcement via admission policy. With a policy engine like Kyverno you can enforce that a tenant resource may only affect its own namespace. That makes the local boundary technically enforced, not just documented.
And in the medium term: the Gateway API. It was designed with safe cross-namespace support and structurally doesn’t have this problem. If you’re building fresh today, give your tenants the Gateway API instead of the old networking CRDs.
The honest part: no existing system migrates overnight. Until the Gateway API is in place everywhere, these three levers are what closes the gap today, without taking away tenant autonomy.
If you’re running a standard setup and aren’t sure whether your own mesh is affected: that’s exactly what I look at in assessments. Feel free to reach out.
Join the discussion on LinkedIn (in German)
From the field, for the field
Every report is built on patterns from real mesh setups. If one of them sounds like your cluster, an architecture call is the place to look at it together.
Request an architecture call