ServiceMesh

Portée : cluster (singleton) · Sous licence — actuellement en préversion (utilisable avec la fonctionnalité preview ou service-mesh)

Fonctionnalité en préversion

Le service mesh est livré mais pas encore GA — sur certaines plateformes il peut causer plus de friction que de valeur (interaction ambient/Cilium, cas limites de démontage). Il est protégé derrière l'adhésion preview, de sorte que seul un groupe de test l'active. Une licence sans service-mesh ni preview le laisse refusé (PreviewLocked) et la plateforme fonctionne normalement sans mTLS.

ServiceMesh apporte le mTLS et l'isolation des locataires à la plateforme via Istio, à la manière d'un opérateur : il installe Istio s'il est absent et l'adopte s'il est déjà présent (notamment sur OpenShift Service Mesh 3), puis configure les namespaces des composants de la plateforme — sans étapes manuelles istioctl/helm.

Il s'appuie sur le Sail Operator (le successeur GA de l'IstioOperator in-cluster supprimé, et la base d'OpenShift Service Mesh 3), de sorte que le chemin géré (Kubernetes classique) et le chemin d'adoption (OpenShift / Istio existant) convergent vers une seule API.

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 (échappatoire)
  isolation: namespace # off | namespace | strict
  enrollNamespaces: [] # également inscrits : tout namespace portant le label d'inscription au mesh

Opt-in & sûr en cas d'échec

Le mesh est une amélioration, jamais une dépendance dure :

• Pas de CR ServiceMesh → rien ne se passe. Les composants fonctionnent en clair ; la plateforme n'est pas affectée. Soumis à licence : sans licence, même no-op.
• Le mTLS STRICT n'est appliqué qu'une fois le plan de contrôle prêt — une installation échouée ou incompatible ne peut jamais casser le trafic des charges de travail. Au pire « pas de mTLS », jamais « plateforme cassée ».
• Sur Cilium + ambient (un point délicat connu), l'opérateur émet un avertissement PreconditionNotMet recommandant dataPlane: sidecar plutôt que d'échouer silencieusement.

Comment un namespace est inscrit

Un namespace rejoint le mesh lorsqu'il porte le label core.navique.com/mesh=enabled. Trois façons de le poser :

• spec.enrollNamespaces sur le ServiceMesh.
• le label du namespace directement.
• spec.mesh.mode sur un Stack ou une charge de travail (Gateway/Observability/ChatUI) — par défaut auto (rejoindre quand un ServiceMesh prêt existe, sinon no-op) ; enabled en exige un ; disabled ne rejoint jamais.

Pour chaque namespace inscrit, l'opérateur applique le label de plan de données, une PeerAuthentication STRICT à l'échelle du namespace (via une brève bascule permissive→strict pour que les charges déjà en cours ne soient pas coupées) et — sauf isolation: off — une AuthorizationPolicy d'isolation.

mTLS vs isolation

Le mTLS authentifie + chiffre mais n'autorise pas : toute charge de travail du mesh peut en atteindre une autre. spec.isolation ajoute une AuthorizationPolicy générée automatiquement à partir du graphe de câblage (les références que l'opérateur résout déjà) :

isolation	Effet
off	mTLS uniquement — aucune autorisation.
namespace (par défaut)	Refuser le cross-namespace ; autoriser l'intra-namespace + les arêtes cross-namespace explicitement câblées. Isole les Stacks/locataires.
strict	Moindre privilège par service (L4 ; L7 méthode/chemin nécessite des waypoints — pas encore implémenté).

En ambient, c'est appliqué au niveau L4 par ztunnel sans waypoints.

Datastores externes & egress

Les datastores mode: external, les API LLM externes, le stockage blob et Key Vault vivent hors du mesh : leur sécurité est le TLS de la connexion elle-même, pas Istio. STRICT et l'isolation ne gouvernent que le trafic entrant, de sorte que l'egress sortant vers ces points de terminaison n'est jamais bloqué.

Déboguer sans combattre l'opérateur (break-glass)

STRICT ne bloque ni kubectl exec, ni kubectl logs, ni les conteneurs de débogage éphémères, ni un pod de débogage dans le mesh — utilisez-les. Pour relâcher le mTLS délibérément, ne modifiez pas la PeerAuthentication gérée à la main (l'opérateur la rétablit) ; à la place :

• spec.mtls.maintenanceUntil (RFC3339) : l'opérateur maintient les namespaces inscrits en PERMISSIVE jusqu'à cette heure, puis rétablit automatiquement STRICT. Auditable et auto-réparateur.
• l'annotation core.navique.com/reconcile-paused sur un objet géré, pour une pause ponctuelle.

Provenance & démantèlement

• managed : installer le Sail Operator (avec comptage de références) + posséder le plan de contrôle Istio. À la suppression (quand rien d'autre n'en a besoin), le désinstaller et nettoyer ses CRDs.
• adopt : un mesh existe déjà (OpenShift / Istio utilisateur) → configurer seulement, ne jamais gérer son cycle de vie. (Le mode managed adopte aussi automatiquement si un mesh est présent.)
• external : ne jamais toucher au plan de contrôle ; émettre seulement notre configuration.

Supprimer le ServiceMesh retire les labels que nous avons posés et collecte les policies que nous possédons (via l'owner reference à l'échelle du cluster) ; un plan de contrôle adopté reste intact.

Limites

• Singleton de cluster nommé cluster ; les autres noms sont Refused.
• OpenShift Service Mesh 2.x (Maistra) est détecté et différé avec un statut clair — adoptez un mesh existant ou passez à OSSM 3 / Sail.
• L'AuthorizationPolicy L7 (méthode/chemin) + waypoints et une passerelle d'entrée Istio nord-sud ne sont pas encore implémentés.

Voir Éditions et licences.