Whoever Owns the Mesh Decides What Stays
From Soltau, live at CloudLand: who’s actually responsible in the mesh?
- Date
- Topic
- Ownership
- Reading time
- 3 min
- Version
- Translation
I’m writing this from Soltau, still at CloudLand. I spoke here on Wednesday, and the same question kept coming up in the discussions. It ties into what I promised you last week.
Figure as text
Diagram of a two-zone ownership model: a platform area and a tenant area, separated by a hard namespace isolation boundary, with a GitOps layer underneath. The caption reads 'Not in Git = not in the cluster'.
Report #3 was about the fact that nobody knows which configurations are safe to remove. The question underneath: who’s actually responsible?
In most setups there is no answer, because there never was a decision. Ownership doesn’t come out of sprints, it comes from an architecture decision that someone makes deliberately and writes down.
The model that holds up best in production is a hard split into two zones:
The platform team builds the guardrails in istio-system and mesh-wide. Control plane, MeshConfig, ingress gateway, PeerAuthentication STRICT, AuthorizationPolicy deny-all, outboundTrafficPolicy REGISTRY_ONLY. These objects are non-negotiable, and only the platform team changes them.
Tenants operate in their own namespace, isolated. VirtualService, DestinationRule, ServiceEntry: restricted to their own namespace by policy. AuthorizationPolicy with a selector on their own workloads, defining who is allowed to talk to them. Inside the guardrails, no sign-off needed.
No shared contract, no negotiable zone in between. With hard namespace isolation, the boundary enforces itself. Anyone who tries to deploy into the wrong namespace gets blocked by the mesh before anyone has to start a discussion.
Ownership without enforcement stays theoretical. The second half of the model is GitOps. Flux and Helm make sure the cluster state comes out of Git rather than out of the last kubectl apply that nobody remembers anymore.
Every policy change goes through the same pull request process as application code. If you want a change in the platform zone, you go through the platform repo. If you create something in a tenant namespace, you go through the tenant repo. Both separate, both traceable.
Drift gets caught by the reconciliation loop instead of the next audit. Manual changes in the cluster snap back to the desired state on the next sync. A rollback is git revert, no pager duty at 3:00 a.m.
And the question from report #3, what’s safe to delete, now has a clear answer: whatever isn’t in Git doesn’t belong in the cluster. Cleanup stops being an audit debate and becomes a reconciliation problem.
One observation from the discussions here: the teams that locked in the ownership model and GitOps from day one didn’t spend more time than anyone else. They decided once and then followed through.
Next week we’ll look at one concrete aspect: how to secure this ownership model technically, so tenants can’t break out of their namespace, not even by accident.
