Wie het mesh bezit, bepaalt wat blijft

Ik schrijf dit vanuit Soltau, nog op CloudLand zelf. Woensdag sprak ik hier, en in de discussies kwam dezelfde vraag meerdere keren terug. Die sluit aan bij wat ik jullie vorige week heb beloofd.

In report #3 ging het erom dat niemand weet welke configuraties je weer mag weghalen. De vraag daarachter: wie is er eigenlijk verantwoordelijk?

In de meeste setups is er geen antwoord, omdat er nooit een beslissing is genomen. Ownership ontstaat niet uit sprints, maar uit een architectuurbeslissing die iemand bewust neemt en vastlegt.

Het model dat in production het beste standhoudt, is een harde scheiding in twee zones:

Het platform-team bouwt de guardrails in istio-system en mesh-breed. Control plane, MeshConfig, ingress gateway, PeerAuthentication STRICT, AuthorizationPolicy deny-all, outboundTrafficPolicy REGISTRY_ONLY. Deze objecten zijn niet onderhandelbaar en worden uitsluitend door het platform-team gewijzigd.

De tenants bewegen zich in hun eigen namespace, geïsoleerd. VirtualService, DestinationRule, ServiceEntry: via policy beperkt tot de eigen namespace. AuthorizationPolicy met een selector op de eigen workloads, die vastlegt wie ermee mag praten. Binnen de guardrails, zonder ruggespraak.

Geen shared contract, geen onderhandelbare zone ertussen. Met harde namespace-isolatie dwingt de grens zichzelf af. Wie in de verkeerde namespace wil deployen, wordt door het mesh geblokkeerd voordat iemand een discussie hoeft te beginnen.

Ownership zonder handhaving blijft theorie. De tweede helft van het model is GitOps. Flux en Helm zorgen ervoor dat de state van het cluster uit Git komt en niet uit de laatste kubectl apply waar niemand zich nog iets van herinnert.

Elke policy-wijziging loopt via hetzelfde pull-request-proces als applicatiecode. Wie iets wil veranderen in de platform-zone, gaat via de platform-repo. Wie iets aanmaakt in de tenant-namespace, gaat via de tenant-repo. Beide gescheiden, beide traceerbaar.

Drift wordt gedetecteerd door de reconciliation loop, niet door de volgende audit. Handmatige wijzigingen in het cluster vliegen bij de volgende sync terug naar de desired state. Rollbacks zijn git revert, geen Pager-Duty om 03:00.

En voor de vraag uit report #3, wat er verwijderd mag worden, is er nu een helder antwoord: wat niet in Git staat, hoort niet in het cluster. Opruimen wordt een reconciliation-probleem, geen audit-discussie.

Een observatie uit de discussies hier: de teams die het ownership-model en GitOps vanaf het begin hebben vastgelegd, zijn niet de teams die meer tijd hebben geïnvesteerd. Het zijn de teams die één keer hebben beslist en het daarna consequent hebben doorgevoerd.

Volgende week kijken we naar een concreet aspect: hoe je dit ownership-model technisch borgt, zodat tenants niet uit hun namespace kunnen ontsnappen, ook niet per ongeluk.