Allow locally, prevent mesh-wide
Closing the gap without taking away tenant autonomy.
- Date
- Topic
- Multi-tenancy
- Reading time
- 2 min
- Version
- Translation
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.
Figure as text
Diagram of the split between local effect, owned by the tenant, and mesh-wide effect, owned by the platform team, with three enforcement mechanisms: defaultExportTo, sidecar egress scoping, and admission policy. The Gateway API is shown as the target state, and sidecar scoping carries a badge marking its double benefit for performance and security.
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.
