Indispensabile pentru funcționarea site-ului (autentificare, preferințe, securitate). Mereu active.
Fixează OpenZiti la v2.0.6 sau mai nou pe linia 2.0 și nu trata o etichetă pre-release ca versiunea fixată pentru client
Fraza pe care o aude un MSP: „avem un overlay zero-trust, deci rețeaua plată a dispărut.” Răspunsul: overlay-ul este un plan de control care trebuie inventariat, fixat la o versiune și securizat, iar pe linia 2.0 versiunea minimă OpenZiti este v2.0.6.
Fixează OpenZiti la v2.0.6 sau mai nou pe linia 2.0 și nu trata o etichetă pre-release ca versiunea fixată pentru client
Fraza pe care o aude un MSP este: „avem un overlay zero-trust, deci rețeaua plată a dispărut.” Răspunsul este că overlay-ul este un plan de control pe care tot trebuie să-l inventariezi, să-l fixezi la o versiune și să-l securizezi. Nu este un slogan care desființează ferestrele de modificare. Proiectul despre care vorbim este OpenZiti, depozitul openziti/ziti, licențiat Apache-2.0, cu 4417 stele și 276 de fork-uri pe GitHub la 4 octombrie 2026 și pagina principală openziti.io. Acestea sunt numărători, nu o afirmație despre popularitate dincolo de cifră.
Versiunea fixată vine imediat după. Cea mai nouă versiune completă de pe linia 2.0 este v2.0.6, publicată pe 18 septembrie 2026. Există și v2.0.7 (25 septembrie) și v2.0.8 (8 octombrie), ambele încă marcate ca pre-release.
În continuare: ce poate însemna „overlay zero-trust programabil”, adică servicii rutate după identitate, un controller, routere de margine și identități înrolate. Și ce nu este OpenZiti, comparat cu alte șase produse care rezolvă alte sarcini. Sfatul de întreținere se oprește la „aplică o versiune fixată”, iar cele șase controale defensive nu adaugă detalii de atac.

Fraza despre funcționalități pe care o folosește acest articol vine din descrierea depozitului și din nimic altceva: proiectul principal OpenZiti livrează executabilele pentru o rețea programabilă, complet zero-trust. Subiectele depozitului includ overlay, zero-trust și ZTNA, ramura implicită este main, iar limbajul principal este Go. Aici nu se vinde ca fapt nicio topologie de înaltă disponibilitate, nicio cifră de debit și niciun număr de clienți. Diagrama felului în care un client și-a conectat controllerele este documentația de proiectare a acelui client, nu o afirmație pe care această pagină o poate împrumuta dintr-un număr de stele.
Obiectele pe care un MSP tot trebuie să le numească sunt controllerele, routerele de margine și identitățile înrolate, inclusiv un mesh de controllere HA, dacă clientul are unul. Acestea sunt nume pentru un export de inventar. Nu sunt un ghid de instalare, nici o topologie de copiat și nici promisiunea că fiecare mediu are un astfel de mesh. Dacă clientul nu are un al doilea controller, inventarul spune asta. Un rând HA gol este un fapt. Un al doilea controller ghicit nu este.
„Rutat după identitate” este fraza pentru cumpărător și este una îngustă. Un serviciu este accesat printr-o identitate înrolată și printr-o politică, nu pentru că gazda se află întâmplător în LAN-ul clientului. Aceasta este diferența pe care un overlay o poate revendica aici. Nu este o afirmație că erorile de configurare sunt imposibile. O politică prea largă, o identitate care nu a fost niciodată revocată sau un router administrat de unde nu ar trebui rămân defecțiuni operaționale obișnuite. Overlay-ul mută întrebarea de la „ce subrețea” la „ce identitate și ce politică”. Nu elimină întrebarea.
Stelele sunt o numărătoare și atât. Cele 4417 stele din 4 octombrie 2026 nu sunt o evaluare de securitate, nu sunt un contract de suport și nu sunt o versiune fixată. Depozitul primește push-uri frecvente; ultimul dinaintea acestui articol a fost pe 8 octombrie 2026. Asta arată că proiectul se mișcă. Nu spune ce etichetă ar trebui să ruleze un client.
Licența este Apache-2.0, așa cum o raportează GitHub. O licență îi spune cumpărătorului care sunt condițiile de drepturi de autor. Nu îi spune ce versiune poate intra în siguranță într-o fereastră de modificare și nu înlocuiește versiunea fixată.
Pagina de versiuni se citește cel mai bine ca o listă scurtă, nu ca o foaie de calcul cu digest-uri. v2.0.6 (18 septembrie 2026) este o versiune completă. v2.0.7 (25 septembrie) și v2.0.8 (8 octombrie) sunt versiuni pre-release. v1.6.21 (18 septembrie) și v1.5.18 (22 septembrie) sunt versiuni complete pe liniile mai vechi, iar v2.0.5 (15 septembrie) este versiunea completă anterioară a liniei 2.0. Fiecare etichetă rămâne în linia ei. O etichetă 1.6 nu devine „mai nouă decât 2.0” pentru că a fost publicată mai târziu în aceeași zi, iar o etichetă 2.0 nu închide o linie de întreținere 1.5 doar prin faptul că există.
Regula de fixare este o frază pe care un MSP o poate repeta. Pe linia 2.0, nu coborî sub v2.0.6, nu rula un latest flotant și nu promova v2.0.7 sau v2.0.8 cât timp sunt marcate ca pre-release. Un client aflat încă pe 1.6 rămâne pe o etichetă 1.6 verificată (cea mai nouă este v1.6.21) până la o migrare planificată, nu pentru că există o etichetă 2.0. „Ia pur și simplu ultima versiune” peste 1.5, 1.6 și 2.0 este instrucțiunea pe care acest articol o refuză. Liniile de întreținere există pentru ca o migrare planificată să fie o migrare, cu un tichet, nu un accident al ordinii de sortare.
Notele de lansare pentru v2.0.6, v2.0.7 și v2.0.8 descriu remedieri de erori și actualizări sau backport-uri de componente. Mesajul de securitate este scurt: proiectul livrează remedieri, iar MSP-ul aplică o versiune fixată după o fereastră de modificare. Cine vrea lista de probleme poate deschide pagina de versiuni.
Versiuni anterioare din 2026, din august, au conținut și ele remedieri de securitate pe partea de controller și routere, cu avizele de securitate listate în notele lor de lansare. Sfatul practic nu se schimbă: fixează o versiune actuală și verificată și tratează un aviz de securitate ca pe un motiv de actualizare planificată.
Headscale este un server de coordonare pentru o altă familie de overlay-uri. Acest articol nu compară liste de funcționalități cu el. Contopirea celor două într-o singură poveste de securizare ar ascunde despre ce plan de control este de fapt tichetul.
Linkerd2 este un service mesh cu un plan de date bazat pe proxy-uri. OpenZiti, așa cum este tratat aici, este un overlay de identitate. Acesta nu este un articol despre sidecar-uri de mesh, iar o politică de sidecar nu este versiunea fixată a unui controller de overlay. Un MSP le poate rula pe amândouă. A le rula pe amândouă nu înseamnă același lucru cu „unul îl înlocuiește pe celălalt”.
Tetragon înseamnă aplicarea politicilor la rulare și observabilitate, într-un alt proiect. Nu este această fixare. Un senzor care urmărește un nod nu alege eticheta OpenZiti, iar o etichetă OpenZiti nu devine o politică de rulare doar pentru că ambele cuvinte pot apărea pe același slide de arhitectură.
Gatekeeper și Kyverno sunt controlul admiterii pentru politicile de cluster. Un overlay zero-trust nu înlocuiește o politică de admitere Kubernetes, iar o politică de admitere nu fixează versiunea unui overlay. Obiectele sunt diferite: unul admite sau respinge cererile API într-un cluster, celălalt rutează identități înrolate către servicii. Tratarea lor ca substitute este felul în care o fereastră de modificare pierde și eticheta overlay-ului, și constrângerile de admitere.
Trivy, Prowler, Grype și Syft sunt scanere și instrumente SBOM. O constatare de scanare nu este o decizie de versiune pentru un overlay, iar acest articol nu le împrumută versiunile pentru a decora fixarea OpenZiti.
Un MSP poate rula mai multe dintre ele. Greșeala cumpărătorului este să le trateze ca substitute. Sarcina acestui articol este fixarea OpenZiti și igiena acelui plan de control, nimic altceva. Dacă titlul tichetului ar putea fi înlocuit cu Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno sau Trivy fără a schimba pașii, tichetul nu este despre această fixare.
Fiecare dintre cele șase controale de mai jos are dovezi care contează și dovezi care nu contează. Un număr de stele, un slogan de marketing care spune „zero trust” și un digest latest flotant nu sunt dovezi pentru niciunul dintre ele.
Primul: inventariază controllerele, routerele de margine și identitățile înrolate, inclusiv membrii unui cluster de controllere HA, dacă există. Dovada este un export de inventar care numește aceste obiecte și spune dacă există un al doilea controller. Un slide care spune „overlay implementat” nu este acel export.
Al doilea: fixează o linie cunoscută după fereastra de modificare. Pe linia 2.0, pragul minim este v2.0.6. Versiunile pre-release precum v2.0.7 și v2.0.8 rămân în afara acelui tichet, cu excepția cazului în care clientul acceptă explicit o versiune pre-release, în scris, în acel tichet. Dovada este șirul etichetei din înregistrarea modificării, nu un digest descărcat de cineva în dimineața ferestrei pentru că apărea primul.
Al treilea: cere MFA pentru administratori pe identitățile controllerului și ale consolei de administrare, revocă înrolările învechite și păstrează privilegiul minim în politicile de identitate și de serviciu. Dovada este o setare MFA pe aceste identități de administrare și un registru de revocare pentru înrolările care nu mai au un responsabil.
Al patrulea: accesează planul de management doar din rețele de administrare de încredere sau prin gazde de salt (jump hosts). Expunerea publică a administrării sau a înrolării nu este o setare implicită. Dovada este o listă de permisiuni sau o regulă echivalentă pentru gazdele de salt, atașată la tichet. O diagramă de firewall fără identificatori de reguli este un desen.
Al cincilea: fă exerciții de backup și restaurare pentru modelul de date al controllerului și pentru materialul de înrolare. Reconstruiește din medii de încredere și rotește identitățile după o compromitere suspectată. Dovada este procesul-verbal al exercițiului de restaurare: data, cine l-a efectuat și dacă restaurarea a produs un controller pe care inventarul încă îl recunoaște.
Al șaselea: trimite jurnalele de audit către un SIEM. Tratează înrolările neașteptate, eliminările MFA pentru administratori și instabilitatea legăturilor routerelor ca semnale operaționale de urmărit. Dovada este numele interogării din SIEM și un responsabil care o urmărește. Un bucket de jurnale pe care nu-l deschide nimeni este stocare, nu supraveghere.
Fraza pe care echipa de modificări o poate repeta: nu confunda „am implementat un overlay” cu „planul de control este fixat și securizat”. Implementarea este începutul inventarului. Fixarea și securizarea sunt tichete ulterioare și trebuie să numească o linie.
Pe scurt: OpenZiti (openziti/ziti) are licența Apache-2.0 și avea 4417 stele pe GitHub la 4 octombrie 2026. Versiunea minimă pe linia 2.0 este v2.0.6, lansată pe 18 septembrie 2026, în timp ce v2.0.7 și v2.0.8 sunt încă versiuni pre-release. Pagina principală este openziti.io.
OpenZiti nu este Headscale, nu este Linkerd2, nu este Tetragon, nu este Gatekeeper, nu este Kyverno și nu este Trivy. Fixează linia, securizează planul de control și păstrează dovezile în tichet.