ServiceMesh

Geltungsbereich: Cluster (Singleton) · Lizenziert — derzeit in der Vorschau (nutzbar mit dem Feature preview oder service-mesh)

Vorschau-Funktion

Das Service Mesh wird ausgeliefert, ist aber noch nicht GA — auf manchen Plattformen kann es mehr Reibung als Nutzen verursachen (Zusammenspiel von Ambient/Cilium, Sonderfälle beim Abbau). Es ist hinter dem Opt-in preview abgesichert, sodass nur eine Testgruppe es aktiviert. Eine Lizenz ohne service-mesh oder preview lässt es abgelehnt (PreviewLocked) und die Plattform läuft normal ohne mTLS.

ServiceMesh bringt mTLS und Mandantenisolation mit Istio auf die Plattform, auf Operator-Art: Es installiert Istio, wenn es fehlt, und übernimmt es, wenn es bereits vorhanden ist (insbesondere bei OpenShift Service Mesh 3), und konfiguriert anschließend die Komponenten-Namespaces der Plattform — ohne manuelle istioctl/helm-Schritte.

Es wird über den Sail Operator gesteuert (den GA-Nachfolger des entfernten In-Cluster-IstioOperator und die Grundlage von OpenShift Service Mesh 3), sodass der verwaltete Pfad (Vanilla Kubernetes) und der Adopt-Pfad (OpenShift / vorhandenes Istio) auf einer API zusammenlaufen.

apiVersion: core.navique.com/v1alpha1
kind: ServiceMesh
metadata:
  name: cluster        # Singleton
spec:
  mode: managed        # managed | adopt | external
  provider: auto       # auto | sail | openshift | istio
  dataPlane: ambient   # ambient | sidecar
  version: "1.30"
  mtls:
    mode: strict       # strict | permissive (Notausstieg)
  isolation: namespace # off | namespace | strict
  enrollNamespaces: [] # zusätzlich aufgenommen: jeder Namespace mit dem Mesh-Enroll-Label

Opt-in & ausfallsicher

Das Mesh ist eine Erweiterung, niemals eine harte Abhängigkeit:

• Keine ServiceMesh-CR → es passiert nichts. Komponenten laufen im Klartext; die Plattform ist nicht betroffen. Lizenzbeschränkt: ohne Lizenz dasselbe No-op.
• STRICT-mTLS wird erst angewendet, nachdem die Control Plane bereit ist — eine fehlgeschlagene oder inkompatible Installation kann den Workload-Verkehr niemals unterbrechen. Schlimmstenfalls „kein mTLS“, niemals „kaputte Plattform“.
• Bei Cilium + ambient (eine bekannte Problemstelle) gibt der Operator eine PreconditionNotMet-Warnung aus und empfiehlt dataPlane: sidecar, statt still zu scheitern.

Wie ein Namespace aufgenommen wird

Ein Namespace tritt dem Mesh bei, wenn er das Label core.navique.com/mesh=enabled trägt. Drei Wege, es zu setzen:

• spec.enrollNamespaces am ServiceMesh.
• das Namespace-Label direkt.
• spec.mesh.mode an einem Stack oder Workload (Gateway/Observability/ChatUI) — Standard auto (beitreten, wenn ein bereites ServiceMesh existiert, sonst No-op); enabled erfordert eines; disabled tritt nie bei.

Für jeden aufgenommenen Namespace wendet der Operator das Data-Plane-Label, eine namespaceweite STRICT-PeerAuthentication (über eine kurze permissive→strict-Umstellung, damit bereits laufende Workloads nicht abgeschnitten werden) und — sofern nicht isolation: off — eine Isolations-AuthorizationPolicy an.

mTLS vs. Isolation

mTLS authentifiziert + verschlüsselt, autorisiert aber nicht: Jeder Workload im Mesh kann jeden anderen erreichen. spec.isolation ergänzt eine automatisch generierte AuthorizationPolicy, abgeleitet aus dem Verdrahtungsgraphen (den Referenzen, die der Operator ohnehin auflöst):

isolation	Wirkung
off	Nur mTLS — keine Autorisierung.
namespace (Standard)	Namespace-übergreifend verbieten; innerhalb des Namespace + die explizit verdrahteten namespaceübergreifenden Kanten erlauben. Isoliert Stacks/Mandanten.
strict	Pro-Service-Least-Privilege (L4; L7 Methode/Pfad benötigt Waypoints — noch nicht implementiert).

In ambient wird dies von ztunnel auf L4 ohne Waypoints durchgesetzt.

Externe Datenspeicher & Egress

Datenspeicher mit mode: external, externe LLM-APIs, Blob-Speicher und Key Vault liegen außerhalb des Mesh: Ihre Sicherheit ist die TLS der Verbindung selbst, nicht Istio. STRICT und Isolation regeln nur eingehenden Verkehr, sodass ausgehender Egress zu diesen Endpunkten nie blockiert wird.

Debuggen, ohne gegen den Operator zu kämpfen (Break-Glass)

STRICT blockiert weder kubectl exec, kubectl logs, ephemere Debug-Container noch einen Debug-Pod im Mesh — nutzen Sie diese. Um mTLS bewusst zu lockern, bearbeiten Sie nicht die verwaltete PeerAuthentication von Hand (der Operator setzt sie zurück); stattdessen:

• spec.mtls.maintenanceUntil (RFC3339): Der Operator hält aufgenommene Namespaces bis zu diesem Zeitpunkt auf PERMISSIVE und stellt danach automatisch STRICT wieder her. Auditierbar und selbstheilend.
• die Annotation core.navique.com/reconcile-paused an einem verwalteten Objekt für eine punktuelle Pause.

Provenienz & Abbau

• managed: den Sail Operator installieren (ref-gezählt) + die Istio-Control-Plane besitzen. Beim Löschen (wenn nichts anderes sie benötigt) deinstallieren und ihre CRDs bereinigen.
• adopt: ein Mesh existiert bereits (OpenShift / Benutzer-Istio) → nur konfigurieren, den Lebenszyklus nie verwalten. (Der managed-Modus übernimmt auch automatisch, wenn ein Mesh vorhanden ist.)
• external: die Control Plane nie anfassen; nur unsere Konfiguration ausgeben.

Das Löschen des ServiceMesh entfernt die von uns gesetzten Labels und sammelt die uns gehörenden Policies per Garbage Collection (über die clustergebundene Owner-Referenz) ein; eine übernommene Control Plane bleibt unangetastet.

Grenzen

• Cluster-Singleton mit Namen cluster; andere Namen werden Refused.
• OpenShift Service Mesh 2.x (Maistra) wird erkannt und zurückgestellt mit klarer Statusmeldung — übernehmen Sie ein vorhandenes Mesh oder upgraden Sie auf OSSM 3 / Sail.
• L7-AuthorizationPolicy (Methode/Pfad) + Waypoints sowie ein Nord-Süd-Istio-Ingress- Gateway sind noch nicht implementiert.

Siehe Editionen & Lizenzierung.