ServiceMesh

Ambito: cluster (singleton) · Con licenza — attualmente in anteprima (utilizzabile con la funzionalità preview oppure service-mesh)

Funzionalità in anteprima

Il service mesh è incluso ma non ancora GA — su alcune piattaforme può creare più attrito che valore (interazione ambient/Cilium, casi limite nello smantellamento). È subordinato all'opt-in preview, così solo un gruppo di test lo abilita. Una licenza senza service-mesh né preview lo lascia rifiutato (PreviewLocked) e la piattaforma funziona normalmente senza mTLS.

ServiceMesh porta mTLS e isolamento tra tenant nella piattaforma tramite Istio, alla maniera di un operatore: installa Istio quando è assente e lo adotta quando è già presente (in particolare su OpenShift Service Mesh 3), quindi configura i namespace dei componenti della piattaforma — senza passaggi manuali con istioctl/helm.

È gestito tramite il Sail Operator (il successore GA dell'IstioOperator interno al cluster, ormai rimosso, e la base di OpenShift Service Mesh 3), così i percorsi managed (Kubernetes standard) e adopt (OpenShift / Istio esistente) convergono su un'unica 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 (escape hatch)
  isolation: namespace # off | namespace | strict
  enrollNamespaces: [] # also enrolled: any namespace with the mesh-enroll label

Opt-in e sicuro in caso di errore

Il mesh è un miglioramento, mai una dipendenza obbligatoria:

• Nessuna CR ServiceMesh → non succede nulla. I componenti comunicano in chiaro; la piattaforma non è interessata. Soggetto a licenza: senza licenza il risultato è lo stesso, nessun effetto.
• mTLS STRICT viene applicato solo dopo che il control plane è Ready — un'installazione fallita o incompatibile non può mai interrompere il traffico dei workload. Il caso peggiore è "nessun mTLS", mai "piattaforma non funzionante".
• Su Cilium + ambient (un noto punto critico) l'operatore solleva un avviso PreconditionNotMet che raccomanda dataPlane: sidecar, invece di fallire silenziosamente.

Come un namespace viene incluso nel mesh

Un namespace entra nel mesh quando porta la label core.navique.com/mesh=enabled. Ci sono tre modi per impostarla:

• spec.enrollNamespaces sul ServiceMesh.
• Direttamente la label sul namespace.
• spec.mesh.mode su uno Stack o su un workload (Gateway/Observability/ChatUI) — per default auto (entra quando esiste un ServiceMesh Ready, altrimenti nessun effetto); enabled ne richiede uno; disabled non entra mai.

Per ogni namespace incluso l'operatore applica la label del data plane, una PeerAuthentication STRICT valida per l'intero namespace (tramite un breve passaggio permissive→strict, così i workload già in esecuzione non vengono interrotti) e — a meno di isolation: off — una AuthorizationPolicy di isolamento.

mTLS vs isolamento

L'mTLS autentica e cifra, ma non autorizza: qualsiasi workload nel mesh può raggiungere qualsiasi altro. spec.isolation aggiunge una AuthorizationPolicy generata automaticamente, derivata dal grafo dei collegamenti (i riferimenti che l'operatore già risolve):

isolation	Effetto
off	Solo mTLS — nessuna autorizzazione.
namespace (predefinito)	Nega il traffico tra namespace; consente quello all'interno del namespace + i collegamenti tra namespace esplicitamente configurati. Isola Stack/tenant.
strict	Privilegio minimo per servizio (L4; metodo/percorso L7 richiede i waypoint — non ancora implementato).

In modalità ambient ciò viene applicato a livello L4 da ztunnel, senza waypoint.

Datastore esterni ed egress

I datastore mode: external, le API LLM esterne, il blob storage e Key Vault risiedono al di fuori del mesh: la loro sicurezza è il TLS della connessione stessa, non Istio. STRICT e isolamento governano solo il traffico in ingresso, quindi l'egress in uscita verso quegli endpoint non viene mai bloccato.

Debug senza scontrarsi con l'operatore (break-glass)

STRICT non blocca kubectl exec, kubectl logs, i container di debug effimeri né un pod di debug nel mesh — usa questi strumenti. Per allentare deliberatamente l'mTLS, non modificare a mano la PeerAuthentication gestita (l'operatore la ripristina); invece:

• spec.mtls.maintenanceUntil (RFC3339): l'operatore mantiene i namespace inclusi in PERMISSIVE fino a quel momento, poi ripristina automaticamente STRICT. Verificabile e autoriparante.
• l'annotazione core.navique.com/reconcile-paused su un oggetto gestito, per una pausa ad hoc.

Provenienza e smantellamento

• managed: installa il Sail Operator (con conteggio dei riferimenti) e possiede il control plane Istio. All'eliminazione (quando nient'altro ne ha bisogno) lo disinstalla e ne rimuove le CRD.
• adopt: esiste già un mesh (OpenShift / Istio dell'utente) → solo configurazione, senza mai gestirne il ciclo di vita. (La modalità managed adotta automaticamente un mesh anche quando è già presente.)
• external: non tocca mai il control plane; emette solo la nostra configurazione.

Eliminare il ServiceMesh rimuove le label che abbiamo aggiunto ed elimina le policy di nostra proprietà (tramite l'owner reference a livello di cluster); un control plane adottato resta intatto.

Limiti

• Singleton di cluster chiamato cluster; gli altri nomi risultano Refused.
• OpenShift Service Mesh 2.x (Maistra) viene rilevato e rinviato con uno status chiaro — adotta un mesh esistente oppure aggiorna a OSSM 3 / Sail.
• AuthorizationPolicy L7 (metodo/percorso) + waypoint e un ingress gateway Istio nord-sud non sono ancora implementati.

Vedi Edizioni e licenze.