Lokaal toestaan, mesh-breed voorkomen
Het gat dichten zonder de tenant zijn autonomie af te nemen.
- Datum
- Onderwerp
- Multi-tenancy
- Leestijd
- 2 min
- Versie
- Vertaling
Vorige week ging het over een gat in standaard Istio-setups: een VirtualService met de optie gateways: mesh werkt door op alle sidecars in het mesh, over namespace-grenzen heen. Een tenant kan daarmee traffic van anderen omleiden.
Afbeelding als tekst
Bovenaan het principe: lokale werking hoort bij de tenant, mesh-brede werking bij het platformteam. Daaronder drie mechanismen (defaultExportTo, Sidecar Egress Scope, Admission Policy) en de Gateway API als doeltoestand, met bij Sidecar Scoping een badge voor het dubbele voordeel van performance en security.
De voor de hand liggende reactie zou zijn om de tenants hun rechten op Istio-resources af te pakken. Dat zou alleen het verkeerde middel zijn. Het sloopt precies de autonomie waar een goed ownership-model om draait. De tenant moet zijn VirtualServices, DestinationRules en ServiceEntries gewoon zelf kunnen blijven beheren.
De juiste scheidslijn loopt ergens anders: lokale werking is van de tenant, mesh-brede werking van het platformteam. In zijn eigen namespace mag de tenant alles bouwen. Wat hij niet mag, is zich mesh-breed met andere namespaces bemoeien.
Drie knoppen dwingen precies dat af:
defaultExportTo in de MeshConfig. Zet je die op de eigen namespace, dan zijn Istio-resources niet meer automatisch mesh-breed zichtbaar. De centrale knop op platformniveau die de default van open naar lokaal gedrag draait.
Sidecar Egress Scoping. Beperk je de egress van elke sidecar tot de namespaces die echt nodig zijn, dan reduceer je config-push en Envoy-geheugen aanzienlijk. Dat doe je meestal om performance-redenen. Het neveneffect: de mesh-brede werking van een VirtualService van een ander wordt ingeperkt. Eén ingreep, twee problemen opgelost.
Enforcement via admission policy. Met een policy engine zoals Kyverno kun je afdwingen dat een tenant-resource alleen de eigen namespace mag raken. Zo wordt de lokale begrenzing technisch afgedwongen, niet alleen gedocumenteerd.
En op de middellange termijn: de Gateway API. Die is ontworpen met veilige cross-namespace-support en heeft dit probleem structureel niet. Wie vandaag iets nieuws bouwt, geeft tenants beter de Gateway API dan de oude networking-CRD’s.
Het eerlijke verhaal: geen enkel bestaand systeem migreert van de ene op de andere dag. Tot de Gateway API overal staat, zijn deze drie knoppen wat het gat vandaag dicht, zonder de tenant zijn autonomie af te nemen.
Draai je een standaard setup en weet je niet zeker of jullie mesh geraakt wordt? Precies daar kijk ik naar in assessments. Stuur me gerust een bericht.
