Lokal erlauben, mesh-weit verhindern

Die naheliegende Reaktion wäre, den Tenants die Rechte auf Istio-Ressourcen wegzunehmen. Das wäre aber das falsche Mittel. Es zerstört genau die Autonomie, die ein sauberes Ownership-Modell ausmacht. Der Tenant soll seine VirtualServices, DestinationRules und ServiceEntries weiter selbst verwalten.

Der richtige Schnitt verläuft woanders: Lokale Wirkung gehört dem Tenant, mesh-weite Wirkung dem Plattform-Team. Der Tenant darf in seinem Namespace alles bauen. Was er nicht darf, ist mesh-weit hineinregieren.

Drei Stellschrauben setzen genau das durch:

defaultExportTo in der MeshConfig. Auf den eigenen Namespace gesetzt, sind Istio-Ressourcen nicht mehr automatisch mesh-weit sichtbar. Die zentrale Stellschraube auf Plattform-Ebene, die den Default vom offenen ins lokale Verhalten dreht.

Sidecar Egress Scoping. Wer den Egress jedes Sidecars auf die wirklich benötigten Namespaces begrenzt, reduziert Config-Push und Envoy-Speicher deutlich. Das macht man meistens aus Performance-Gründen. Der Nebeneffekt: Die mesh-weite Wirkung eines fremden VirtualService wird eingegrenzt. Ein Hebel, zwei Probleme gelöst.

Enforcement per Admission Policy. Mit einer Policy-Engine wie Kyverno lässt sich erzwingen, dass eine Tenant-Ressource nur den eigenen Namespace betreffen darf. Damit wird die lokale Begrenzung technisch durchgesetzt, nicht nur dokumentiert.

Und mittelfristig: die Gateway API. Sie wurde mit sicherem Cross-Namespace-Support entworfen und hat das Problem strukturell nicht. Wer heute neu baut, sollte Tenants die Gateway API geben statt der alten Networking-CRDs.

Der ehrliche Teil: Kein Bestandssystem migriert über Nacht. Bis die Gateway API überall steht, sind diese drei Stellschrauben das, was die Lücke heute schließt – ohne dem Tenant seine Autonomie zu nehmen.

Wer ein Standard-Setup fährt und unsicher ist, ob das eigene Mesh betroffen ist: Genau das schaue ich mir in Assessments an. Meldet euch gern.