Als een tenant de traffic van de anderen kaapt
Wie tenants eigen VirtualServices toestaat, zet de deur open voor MITM in het eigen mesh.
- Datum
- Onderwerp
- Multi-tenancy
- Bronnen
- 1
- Leestijd
- 2 min
- Versie
- Vertaling
Even vooraf: deze serie heette tot nu toe “Istio Weekly”. Tetrate heeft onder die naam al een gevestigd format, en dat wil ik niet dubbel doen. “Field Report” past sowieso beter bij wat hier staat: observaties uit echte setups, geen weekoverzicht.
Afbeelding als tekst
Diagram van een man-in-the-middle-scenario in een service mesh: bovenaan de bedoelde directe route tussen twee services (groen), onderaan dezelfde route in rood, omgeleid via de service van een aanvaller. De oorzaak is een VirtualService met gateways: mesh.
Vorige week ging het over het ownership-model: Istio-networking-resources horen in handen van het platformteam, niet van de tenants. Toen was mijn argument netheid. Er is alleen een tweede reden, en die is serieuzer.
Wie tenants toestaat om eigen VirtualServices aan te maken, zet in een standaard setup de deur open voor man-in-the-middle in het eigen mesh.
Het mechanisme, in het kort: een VirtualService werkt niet alleen in de eigen namespace. Zodra in de gateways-sectie de waarde mesh staat, gelden de routing-regels voor alle sidecars in het mesh, ongeacht de namespace. Een tenant kan daarmee een VirtualService aanmaken die requests voor andermans hostnames omleidt naar een eigen service. De traffic van andere workloads loopt dan door zijn service.
mTLS helpt hier niet. De proxy ziet de omgeleide service als het legitieme doel van de overschreven hostname. De end-to-end-authenticatie tussen bron en eigenlijk doel is gebroken.
Waarom dit überhaupt kan: de Istio-CRDs werden gestabiliseerd voordat Kubernetes namespace-based RBAC had. Multi-tenancy op een gedeeld mesh was toen geen onderdeel van het threat model. De resources dragen dat oude model tot vandaag mee.
Het Istio-project zegt dat zelf overigens heel open: het claimt geen harde namespace-based multi-tenancy. Die tradeoff is bewust gemaakt in het voordeel van eenvoudige adoptie. Wie er toch op bouwt, moet de risico’s zelf beoordelen en dichten.
De security-onderzoekers van ERNW hebben op de officiële Istio-blog in detail beschreven hoe dit in een default setup te misbruiken is. Wie tenants self-service op Istio-resources geeft en erop vertrouwt dat namespaces een harde grens zijn, moet die blogpost lezen.
Volgende week komt het praktische deel: welke knoppen het gat dichten, van de MeshConfig via Sidecar-scoping tot de Gateway API. En waarom sommige daarvan sowieso op jullie lijst zouden moeten staan.
