Wenn ein Tenant den Traffic der anderen kapert

Kurze Sache vorweg: Diese Serie hieß bisher “Istio Weekly”. Tetrate betreibt unter dem Namen schon ein etabliertes Format, das will ich nicht doppeln. “Field Report” passt ohnehin besser zu dem, was hier steht: Beobachtungen aus echten Setups, kein Wochenrückblick.

Letzte Woche ging es um das Ownership-Modell: Istio-Networking-Ressourcen gehören in die Hand des Plattform-Teams, nicht der Tenants. Damals habe ich das mit Ordnung begründet. Es gibt aber einen zweiten Grund, und der ist ernster.

Wer Tenants erlaubt, eigene VirtualServices anzulegen, öffnet in einem Standard-Setup eine Tür für Man-in-the-Middle im eigenen Mesh.

Der Mechanismus, kurz: Ein VirtualService wirkt nicht nur im eigenen Namespace. Sobald in der gateways-Sektion der Wert mesh gesetzt ist, gelten die Routing-Regeln für alle Sidecars im Mesh, unabhängig vom Namespace. Ein Tenant kann damit einen VirtualService anlegen, der Requests für fremde Hostnamen auf einen eigenen Service umleitet. Der Traffic anderer Workloads läuft dann durch seinen Service.

mTLS hilft hier nicht. Der Proxy hält den umgeleiteten Service für das legitime Ziel des überschriebenen Hostnamens. Die Ende-zu-Ende-Authentifizierung zwischen Quelle und eigentlichem Ziel ist gebrochen.

Warum das überhaupt geht: Die Istio-CRDs wurden stabilisiert, bevor es namespace-basiertes RBAC in Kubernetes gab. Multi-Tenancy auf einem geteilten Mesh war damals kein Teil des Bedrohungsmodells. Die Resourcen tragen dieses alte Modell bis heute.

Das Istio-Projekt sagt das übrigens selbst sehr offen: Es beansprucht keine harte namespace-basierte Multi-Tenancy. Der Tradeoff wurde bewusst zugunsten einfacher Adoption gewählt. Wer trotzdem darauf setzt, muss die Risiken selbst bewerten und schließen.

Die Sicherheitsforscher von ERNW haben im offiziellen Istio-Blog im Detail beschrieben, wie sich das in einem Default-Setup ausnutzen lässt. Wer Tenants Self-Service auf Istio-Ressourcen gibt und sich darauf verlässt, dass Namespaces eine harte Grenze sind, sollte den Beitrag lesen.

Nächste Woche kommt der praktische Teil: Welche Stellschrauben die Lücke schließen, von der MeshConfig über Sidecar-Scoping bis zur Gateway API. Und warum manche davon ohnehin auf eurer Liste stehen sollten.