Wenn ein Tenant den Traffic der anderen kapert
Wer Tenants eigene VirtualServices erlaubt, öffnet eine Tür für MITM im eigenen Mesh.
- Datum
- Thema
- Multi-Tenancy
- Quellen
- 1
- Lesezeit
- 2 Min.
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.
Abbildung als Text
Diagramm eines Man-in-the-Middle-Szenarios per VirtualService: Im Normalfall spricht Service A direkt und per mTLS authentifiziert mit Service B, mit einem mesh-weit wirkenden VirtualService kann ein dritter Tenant den Traffic auf einen Angreifer-Service umleiten. Möglich ist das, weil die Istio-CRDs stabilisiert wurden, bevor es namespace-basiertes RBAC in Kubernetes gab.
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.
