Fissa OpenZiti alla v2.0.6 o successiva sulla linea 2.0, e non trattare un tag pre-release come il pin del cliente

Fissa OpenZiti alla v2.0.6 o successiva sulla linea 2.0, e non trattare un tag pre-release come il pin del cliente

La frase che un MSP si sente dire è «abbiamo un overlay zero-trust, quindi la rete piatta non c’è più». La risposta è che l’overlay è un control plane che va comunque inventariato, fissato a una versione e blindato. Non è uno slogan che manda in pensione le finestre di modifica. Il progetto di cui parliamo è OpenZiti, repository openziti/ziti, licenza Apache-2.0, con 4417 stelle e 276 fork su GitHub al 4 ottobre 2026 e homepage openziti.io. Sono conteggi, non una dichiarazione di popolarità che vada oltre il numero.

Il pin va detto subito dopo. La release completa più recente sulla linea 2.0 è la v2.0.6, pubblicata il 18 settembre 2026. Esistono anche la v2.0.7 (25 settembre) e la v2.0.8 (8 ottobre), entrambe ancora contrassegnate come pre-release.

Di seguito: che cosa può voler dire “overlay zero-trust programmabile”, cioè servizi instradati per identità, un controller, edge router e identità registrate. E che cosa OpenZiti non è, a confronto con sei altri prodotti che fanno lavori diversi. Il consiglio di manutenzione si ferma ad “applica una release fissata”, e i sei controlli difensivi non aggiungono dettagli d’attacco.

La frase sulle funzionalità che questo articolo usa viene dalla descrizione del repository e da nient’altro: il progetto principale di OpenZiti distribuisce gli eseguibili per una rete programmabile e interamente zero-trust. Tra i topic del repository ci sono overlay, zero-trust e ZTNA, il branch predefinito è main e il linguaggio principale è Go. Qui non si vende come fatto nessuna topologia ad alta disponibilità, nessun dato di throughput e nessun numero di clienti. Lo schema di come un cliente ha collegato i propri controller è la documentazione di progetto di quel cliente, non un’affermazione che questa pagina possa ricavare da un numero di stelle.

Gli oggetti che un MSP deve comunque nominare sono controller, edge router e identità registrate, compresa una mesh di controller HA se il cliente ne gestisce una. Sono nomi per un export d’inventario. Non sono una guida di installazione, non una topologia da copiare e non la promessa che ogni ambiente abbia la mesh. Se il cliente non gestisce un secondo controller, l’inventario lo dice. Una riga HA vuota è un fatto. Un secondo controller supposto no.

“Instradato per identità” è la frase per l’acquirente, ed è una frase stretta. Un servizio si raggiunge tramite un’identità registrata e una policy, non perché l’host si trova sulla LAN del cliente. Questa è la differenza che un overlay può rivendicare qui. Non è un’affermazione che gli errori di configurazione siano impossibili. Una policy troppo ampia, un’identità mai revocata o un router lasciato dove non dovrebbe essere amministrato restano normali guasti operativi. L’overlay sposta la domanda da “quale sottorete” a “quale identità e quale policy”. Non elimina la domanda.

Le stelle sono un conteggio, e lì ci si ferma. Le 4417 stelle del 4 ottobre 2026 non sono una valutazione di sicurezza, non un contratto di supporto e non un pin. Il repository riceve push frequenti; l’ultimo prima di questo articolo è dell’8 ottobre 2026. Questo dice che il progetto si muove. Non dice quale tag debba usare un cliente.

La licenza è Apache-2.0, come riportato da GitHub. Una licenza informa l’acquirente sui termini di copyright. Non gli dice quale release sia sicura da mettere in una finestra di modifica, e non sostituisce il pin.

La pagina delle release si legge meglio come un breve elenco che come un foglio di digest. La v2.0.6 (18 settembre 2026) è una release completa. La v2.0.7 (25 settembre) e la v2.0.8 (8 ottobre) sono pre-release. La v1.6.21 (18 settembre) e la v1.5.18 (22 settembre) sono release complete sulle linee più vecchie, e la v2.0.5 (15 settembre) è la precedente release completa della 2.0. Ogni tag resta dentro la propria linea. Un tag 1.6 non diventa “più nuovo della 2.0” perché è stato pubblicato più tardi nella giornata, e un tag 2.0 non chiude una linea di manutenzione 1.5 solo perché esiste.

La regola del pin è una frase che un MSP può ripetere. Sulla linea 2.0 non si scende sotto la v2.0.6, non si usa un latest flottante e non si promuovono la v2.0.7 o la v2.0.8 finché sono contrassegnate come pre-release. Un cliente ancora sulla 1.6 resta su un tag 1.6 verificato (il più recente è la v1.6.21) fino a una migrazione pianificata, non perché esiste un tag 2.0. “Prendi l’ultima e basta” tra 1.5, 1.6 e 2.0 è l’istruzione che questo articolo rifiuta. Le linee di manutenzione esistono perché una migrazione pianificata sia una migrazione, con un ticket, e non un incidente dovuto all’ordinamento.

Le note di rilascio di v2.0.6, v2.0.7 e v2.0.8 descrivono correzioni di bug e aggiornamenti o backport di componenti. Il messaggio sulla sicurezza è breve: il progetto rilascia correzioni e l’MSP applica una release fissata dopo una finestra di modifica. Chi vuole l’elenco delle issue può aprire la pagina delle release.

Anche release precedenti del 2026, ad agosto, contenevano correzioni di sicurezza lato controller e router, con gli advisory elencati nelle note di rilascio. Il consiglio pratico non cambia: fissare una release attuale e verificata, e trattare un advisory come un motivo per aggiornare secondo pianificazione.

Headscale è un server di coordinamento per un’altra famiglia di overlay. Questo articolo non ne confronta le checklist di funzionalità. Unire i due in un’unica storia di hardening nasconderebbe a quale control plane si riferisce davvero il ticket.

Linkerd2 è un service mesh con data plane a proxy. OpenZiti, come lo trattiamo qui, è un overlay di identità. Questo non è un articolo sui sidecar di una mesh, e una policy di sidecar non è il pin di release di un controller overlay. Un MSP può usarli entrambi. Usarli entrambi non equivale a dire “uno sostituisce l’altro”.

Tetragon è enforcement di runtime e osservabilità in un progetto diverso. Non è questo pin. Un sensore che osserva un nodo non sceglie il tag di OpenZiti, e un tag di OpenZiti non diventa una policy di runtime perché le due parole compaiono nella stessa slide di architettura.

Gatekeeper e Kyverno sono admission di policy per cluster. Un overlay zero-trust non sostituisce una policy di admission Kubernetes, e una policy di admission non fissa la release di un overlay. Gli oggetti sono diversi: uno ammette o nega richieste API in un cluster, l’altro instrada identità registrate verso servizi. Trattarli come sostituti è il modo in cui una finestra di modifica perde sia il tag dell’overlay sia i vincoli di admission.

Trivy, Prowler, Grype e Syft sono scanner e strumenti SBOM. Un risultato di scansione non è una decisione di release per un overlay, e questo articolo non prende in prestito le loro versioni per decorare un pin di OpenZiti.

Un MSP può usarne più d’uno. L’errore dell’acquirente è trattarli come sostituti. Il compito di questo articolo è il pin di OpenZiti e l’igiene di quel control plane, nient’altro. Se il titolo del ticket si potesse sostituire con Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno o Trivy senza cambiare i passaggi, il ticket non riguarda questo pin.

Ciascuno dei sei controlli che seguono ha prove che contano e prove che non contano. Un numero di stelle, uno slogan di marketing che dice “zero trust” e un digest latest flottante non sono prove per nessuno di essi.

Primo: inventariare controller, edge router e identità registrate, compresi i membri di un cluster di controller HA se presenti. La prova è un export d’inventario che nomina quegli oggetti e dice se esiste un secondo controller. Una slide con scritto “overlay distribuito” non è quell’export.

Secondo: fissare una linea nota dopo la finestra di modifica. Sulla linea 2.0 il minimo è la v2.0.6. Le pre-release come la v2.0.7 e la v2.0.8 restano fuori da quel ticket, a meno che il cliente non accetti esplicitamente una pre-release, per iscritto, su quel ticket. La prova è la stringa del tag nel change record, non un digest scaricato la mattina della finestra perché compariva per primo.

Terzo: richiedere l’MFA per gli amministratori sulle identità del controller e della console di amministrazione, revocare le registrazioni obsolete e mantenere il privilegio minimo sulle policy di identità e di servizio. La prova è un’impostazione MFA su quelle identità amministrative e un registro di revoca per le registrazioni che non hanno più un responsabile.

Quarto: raggiungere il piano di gestione solo da reti di amministrazione fidate o da jump host. L’esposizione pubblica dell’amministrazione o della registrazione non è un default. La prova è una allowlist, o una regola equivalente sui jump host, allegata al ticket. Uno schema del firewall senza identificativi delle regole è un disegno.

Quinto: eseguire esercitazioni di backup e ripristino per il modello dati del controller e per il materiale di registrazione. Ricostruire da supporti fidati e ruotare le identità dopo una sospetta compromissione. La prova è il verbale dell’esercitazione di ripristino: la data, chi l’ha eseguita e se il ripristino ha prodotto un controller che l’inventario riconosce ancora.

Sesto: inviare i log di audit a un SIEM. Trattare registrazioni inattese, rimozioni dell’MFA amministrativa e instabilità dei collegamenti dei router come segnali operativi da sorvegliare. La prova è il nome della query nel SIEM e un responsabile che la guarda. Un bucket di log che nessuno apre è archiviazione, non sorveglianza.

La frase che il team delle modifiche può ripetere: non confondere “abbiamo distribuito un overlay” con “il control plane è fissato e blindato”. La distribuzione è l’inizio dell’inventario. Il pin e il blocco sono ticket successivi, e devono nominare una linea.

In sintesi: OpenZiti (openziti/ziti) è distribuito con licenza Apache-2.0 e aveva 4417 stelle su GitHub al 4 ottobre 2026. La versione minima sulla linea 2.0 è la v2.0.6, rilasciata il 18 settembre 2026, mentre la v2.0.7 e la v2.0.8 sono ancora pre-release. La homepage è openziti.io.

OpenZiti non è Headscale, non è Linkerd2, non è Tetragon, non è Gatekeeper, non è Kyverno e non è Trivy. Fissate la linea, blindate il control plane e tenete le prove nel ticket.