Service Mesh Field Report #6
Lokal erlauben, mesh-weit verhindern
Letzte Woche ging es um eine Lücke in Standard-Istio-Setups: Ein VirtualService mit der Option gateways: mesh wirkt auf alle Sidecars im Mesh, namespace-übergreifend. Ein Tenant kann damit fremden Traffic umleiten.
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.
Diskussion zu diesem Report auf LinkedIn
Aus der Praxis, für die Praxis
Hinter jedem Report stehen Muster aus echten Mesh-Setups. Wenn eines davon nach eurem Cluster klingt: Im Architekturgespräch schauen wir gemeinsam drauf.
Architekturgespräch anfragen