Service mesh security: portare lo zero trust dentro il cluster

Service mesh security è la disciplina che applica la fiducia zero là dove, dentro le architetture a microservizi, ne è rimasta di meno: nel traffico tra un servizio e l’altro. Per anni l’attenzione si è concentrata sul perimetro, su ciò che entra ed esce dal cluster, mentre la rete interna, quella su cui i servizi si parlano tra loro, è rimasta una zona di fiducia implicita. Un servizio si fidava di un altro perché entrambi giravano nello stesso ambiente, e questo bastava. È esattamente l’assunzione che un attaccante, ottenuto un primo appiglio, sfrutta per muoversi lateralmente senza incontrare resistenza.

Una service mesh ribalta questa assunzione, e lo fa senza chiedere agli sviluppatori di toccare il codice. Inserendo un livello dedicato alla comunicazione tra i servizi, dà a ciascuna chiamata interna tre cose che prima mancavano: un’identità verificabile per chi chiama e chi risponde, la cifratura del traffico, e una decisione di autorizzazione a ogni passaggio. Tradotto, trasforma una rete interna piatta e fidata in una sequenza di checkpoint, dove ogni connessione va dimostrata invece che data per scontata.

Il traffico est-ovest era terra di fiducia

Conviene fissare la geografia del problema. Il traffico nord-sud è quello che attraversa il confine del cluster, dall’esterno verso un servizio o viceversa, ed è da sempre il più sorvegliato: lì si concentrano firewall, gateway, controlli. Il traffico est-ovest è invece quello laterale, tra i servizi che vivono dentro il cluster, e storicamente è stato lasciato scorrere su una rete sostanzialmente aperta, nella convinzione che il pericolo venisse da fuori.

Questa convinzione non regge più. Negli attacchi moderni, una volta dentro, l’avversario cerca proprio di spostarsi tra i servizi usando connessioni che la rete interna considera legittime, esattamente come fa lungo le relazioni di fiducia tra identità. Una difesa che presidia solo il confine lascia all’intruso un intero territorio in cui muoversi indisturbato. La service mesh security porta la logica della segmentazione al livello del singolo servizio: non più una rete interna da attraversare liberamente, ma tante connessioni ciascuna da autenticare e autorizzare, applicando dentro il cluster lo stesso principio di zero trust che si pretende al perimetro.

Identità, cifratura, autorizzazione: cosa dà il mesh

Il cuore tecnico sta in ciò che la mesh aggiunge a ogni chiamata est-ovest, e che l’applicazione non deve implementare. Il primo elemento è l’identità del carico di lavoro. Ogni servizio riceve un’identità crittografica forte, stabile e indipendente dall’indirizzo IP o dal punto in cui gira, secondo lo standard SPIFFE, che la rappresenta in certificati X.509 dedicati. È una identità non umana a tutti gli effetti, ma assegnata e ruotata automaticamente dalla mesh: piattaforme come Istio la emettono in modo nativo attraverso la propria autorità di certificazione, e Linkerd fa lo stesso con un’impostazione più snella.

Su quell’identità poggiano gli altri due elementi. La cifratura arriva con il mutual TLS, l’mTLS, in cui non è solo il server a presentare un certificato, ma anche il client: entrambe le parti si autenticano a vicenda e il traffico viaggia cifrato, qualunque sia la rete sottostante. E sopra la cifratura si applica l’autorizzazione: regole che stabiliscono quale identità può chiamare quale servizio, su quale percorso, con quale metodo, negando tutto il resto. Il risultato è che ogni salto tra servizi diventa una decisione esplicita, autenticata, cifrata e autorizzata, e tutto questo senza una riga di codice applicativo in più.

service mesh security non finisce con l’mTLS

È qui che molti si fermano troppo presto, ed è l’errore da evitare. Attivare l’mTLS dà una falsa sensazione di compiutezza, ma l’mTLS risolve solo metà del problema: autentica, non autorizza. Garantisce che le due parti siano chi dicono di essere e che nessuno origli, ma non dice nulla su chi abbia il diritto di parlare con chi. Un carico di lavoro con un certificato valido resta in grado di raggiungere un servizio anche quando non dovrebbe. Per chiudere davvero il traffico servono le politiche di autorizzazione, che esprimono in modo esplicito i permessi, per esempio consentendo al solo servizio degli ordini di chiamare quello dei pagamenti sul percorso del checkout, e vietando ogni altra connessione.

C’è poi una trappola nella configurazione predefinita. Per agevolare l’adozione graduale, le mesh partono spesso in modalità permissiva, accettando sia il traffico cifrato sia quello in chiaro. È comodo durante la migrazione, ma lascia aperta proprio la porta che si crede chiusa: finché non si passa alla modalità rigida, che rifiuta il traffico non protetto, la garanzia dell’mTLS è solo parziale. La buona pratica, una volta completata l’adozione, è imporre la modalità rigida e affiancare alle politiche della mesh anche le politiche di rete native di Kubernetes, per una difesa a più livelli che non dipenda da un solo meccanismo.

Il prezzo del proxy, e come sta calando

La service mesh security ha avuto a lungo un costo operativo concreto, ed è giusto dirlo. Il modello classico inserisce accanto a ogni servizio un proxy, il sidecar, che intercetta tutto il traffico: questo aggiunge consumo di memoria per ogni unità, introduce un salto in più a ogni richiesta e comporta una latenza misurabile, che secondo i confronti pubblici varia sensibilmente tra le diverse soluzioni. Per molte organizzazioni questa tassa è stata la ragione principale di esitazione.

La risposta del settore, negli ultimi anni, è stata ripensare l’architettura per ridurre quel costo. Sono emersi i modelli senza sidecar: la modalità ambient di Istio, che separa il livello di sicurezza dal proxy per ogni carico, e gli approcci basati su eBPF come quello di Cilium, che spostano la logica nel kernel anziché in un proxy affiancato. L’obiettivo è ottenere gli stessi risultati, identità, cifratura e autorizzazione su ogni chiamata, con un peso operativo molto più leggero. Resta una scelta che va misurata sul proprio carico, ma la barriera che frenava l’adozione si sta abbassando.

Quale mesh, e perché conta adesso

Il panorama del 2026 offre alternative mature con compromessi diversi: Istio, il più completo e versatile, oggi disponibile anche in modalità ambient; Linkerd, orientato alla semplicità e a un impatto operativo minimo; le mesh basate su eBPF integrate con il livello di rete; le soluzioni capaci di estendersi oltre i container, fino alle macchine virtuali. La scelta dipende dalla complessità che si è disposti a gestire e dal peso che si può sostenere, ma il principio di sicurezza che offrono converge: identità per ogni servizio, cifratura per ogni chiamata, autorizzazione per ogni salto. Va precisato che a convergere è più il risultato che il meccanismo: dove Istio e Linkerd poggiano su identità SPIFFE e mTLS, le mesh basate su eBPF come Cilium raggiungono obiettivi simili per altre vie, con identità legate alle etichette dei carichi a livello di rete, cifratura tipicamente via WireGuard o IPsec e un’autenticazione reciproca in stile mTLS più recente e ancora in via di maturazione.

Il motivo per cui il tema è rilevante adesso è la combinazione tra la diffusione delle architetture a microservizi e l’evoluzione degli attacchi verso il movimento laterale con credenziali e connessioni legittime. In un ambiente dove decine o centinaia di servizi si chiamano di continuo, lasciare quel dialogo su una rete di fiducia implicita significa offrire all’intruso il terreno ideale. La service mesh security è la risposta strutturale: rende il principio per cui nessuna connessione è fidata per default vero anche dentro il cluster, e non solo al suo confine. Non è un interruttore da accendere, perché richiede mTLS in modalità rigida e politiche di autorizzazione scritte con cura, ma è il modo con cui la rete interna smette di essere l’ultima zona franca della sicurezza cloud-native.

https://www.ictsecuritymagazine.com/cyber-security/service-mesh-security/