When One Tenant Hijacks Everyone Else's Traffic

Quick note up front: this series used to be called “Istio Weekly”. Tetrate already runs an established format under that name, and I don’t want to duplicate it. “Field Report” fits what happens here better anyway: observations from real setups rather than a weekly recap.

Last week was about the ownership model: Istio networking resources belong in the hands of the platform team, not the tenants. Back then I argued from a tidiness angle. There is a second reason, and it is more serious.

Allow tenants to create their own VirtualServices, and in a standard setup you have opened a door to man-in-the-middle inside your own mesh.

The mechanism, in short: a VirtualService does not only take effect in its own namespace. As soon as the gateways section contains the value mesh, its routing rules apply to every sidecar in the mesh, regardless of namespace. A tenant can use this to create a VirtualService that redirects requests for hostnames they do not own to a service of their own. Other workloads’ traffic then flows through their service.

mTLS does not help here. The proxy treats the redirected service as the legitimate destination for the overridden hostname. End-to-end authentication between the source and the actual target is broken.

Why this is possible at all: the Istio CRDs were stabilized before namespace-based RBAC existed in Kubernetes. Multi-tenancy on a shared mesh was not part of the threat model back then. The resources carry that old model to this day.

The Istio project itself is very open about this, by the way: it does not claim hard namespace-based multi-tenancy. The tradeoff was a deliberate choice in favor of easy adoption. If you rely on it anyway, assessing and closing the risks is on you.

The security researchers at ERNW have described in detail, on the official Istio blog, how this can be exploited in a default setup. If you give tenants self-service on Istio resources and rely on namespaces being a hard boundary, read that post.

Next week brings the practical part: which knobs close the gap, from MeshConfig to Sidecar scoping to the Gateway API. And why some of them should be on your list anyway.