Przypnij OpenZiti do wersji v2.0.6 lub nowszej w linii 2.0 i nie traktuj tagu pre-release jako wersji przypinanej u klienta

Przypnij OpenZiti do wersji v2.0.6 lub nowszej w linii 2.0 i nie traktuj tagu pre-release jako wersji przypinanej u klienta

Zdanie, które słyszy MSP, brzmi: „mamy nakładkę zero-trust, więc płaskiej sieci już nie ma”. Odpowiedź: nakładka (overlay) to płaszczyzna sterowania, którą i tak trzeba zinwentaryzować, przypiąć do wersji i zabezpieczyć. To nie hasło, które znosi okna zmian. Chodzi tu o projekt OpenZiti, repozytorium openziti/ziti, licencja Apache-2.0, 4417 gwiazdek i 276 forków na GitHubie według stanu z 4 października 2026, strona domowa openziti.io. To liczby, a nie twierdzenie o popularności wykraczające poza samą liczbę.

Przypięcie wersji trzeba omówić od razu. Najnowsze pełne wydanie w linii 2.0 to v2.0.6, opublikowane 18 września 2026. Istnieją też v2.0.7 (25 września) i v2.0.8 (8 października), ale obie są nadal oznaczone jako pre-release.

Dalej: co może oznaczać „programowalna nakładka zero-trust”, czyli usługi trasowane według tożsamości, kontroler, routery brzegowe i zarejestrowane tożsamości. Oraz czym OpenZiti nie jest, w zestawieniu z sześcioma innymi produktami, które rozwiązują inne zadania. Porada dotycząca utrzymania kończy się na „wdróż przypięte wydanie”, a sześć kontroli obronnych nie dodaje żadnych szczegółów ataku.

Zdanie o funkcjach, którego używa ten artykuł, pochodzi z opisu repozytorium i z niczego więcej: główny projekt OpenZiti dostarcza pliki wykonywalne dla w pełni zero-trustowej, programowalnej sieci. Tematy repozytorium obejmują overlay, zero-trust i ZTNA, domyślna gałąź to main, a główny język to Go. Nie sprzedajemy tu jako faktu żadnej topologii wysokiej dostępności, żadnej liczby dotyczącej przepustowości ani liczby klientów. Schemat tego, jak jeden klient połączył swoje kontrolery, to dokumentacja projektowa tego klienta, a nie twierdzenie, które ta strona mogłaby wyprowadzić z liczby gwiazdek.

Obiekty, które MSP i tak musi nazwać, to kontrolery, routery brzegowe i zarejestrowane tożsamości, w tym siatkę kontrolerów HA (mesh), jeśli klient ją utrzymuje. To nazwy do eksportu inwentarza. Nie są instrukcją budowy, topologią do skopiowania ani obietnicą, że każde środowisko ma taką siatkę. Jeśli klient nie ma drugiego kontrolera, inwentarz to mówi. Pusty wiersz HA to fakt. Zgadywany drugi kontroler nie jest faktem.

„Trasowane według tożsamości” to zdanie dla kupującego i jest ono wąskie. Do usługi dociera się przez zarejestrowaną tożsamość i politykę, a nie dlatego, że host akurat stoi w sieci LAN klienta. To jest różnica, którą nakładka może tu sobie przypisać. Nie jest to twierdzenie, że błędna konfiguracja jest niemożliwa. Zbyt szeroka polityka, tożsamość, której nigdy nie odwołano, czy router administrowany tam, gdzie nie powinien, to nadal zwykłe awarie operacyjne. Nakładka zmienia pytanie z „która podsieć” na „która tożsamość i która polityka”. Nie usuwa pytania.

Gwiazdki to liczba i na tym koniec. 4417 gwiazdek z 4 października 2026 to nie ocena bezpieczeństwa, nie umowa wsparcia i nie przypięta wersja. Do repozytorium często trafiają zmiany; ostatni push przed tym artykułem był 8 października 2026. To mówi, że projekt się rozwija. Nie mówi, który tag powinien uruchamiać klient.

Licencja to Apache-2.0, tak jak podaje GitHub. Licencja informuje kupującego o warunkach praw autorskich. Nie mówi mu, które wydanie można bezpiecznie wprowadzić w oknie zmian, i nie zastępuje przypięcia wersji.

Stronę wydań najlepiej czytać jako krótką listę, a nie arkusz skrótów (digestów). v2.0.6 (18 września 2026) to pełne wydanie. v2.0.7 (25 września) i v2.0.8 (8 października) to wydania pre-release. v1.6.21 (18 września) i v1.5.18 (22 września) to pełne wydania w starszych liniach, a v2.0.5 (15 września) to poprzednie pełne wydanie 2.0. Każdy tag zostaje w swojej linii. Tag 1.6 nie staje się „nowszy niż 2.0” dlatego, że opublikowano go później tego samego dnia, a tag 2.0 nie zamyka linii utrzymaniowej 1.5 samym swoim istnieniem.

Zasada przypinania to jedno zdanie, które MSP może powtarzać. W linii 2.0 nie schodź poniżej v2.0.6, nie uruchamiaj ruchomego latest i nie promuj v2.0.7 ani v2.0.8, dopóki są oznaczone jako pre-release. Klient, który wciąż jest na 1.6, zostaje na zweryfikowanym tagu 1.6 (najnowszy to v1.6.21) aż do zaplanowanej migracji, a nie dlatego, że istnieje tag 2.0. „Po prostu weź najnowsze” w poprzek 1.5, 1.6 i 2.0 to polecenie, które ten artykuł odrzuca. Linie utrzymaniowe istnieją po to, by zaplanowana migracja była migracją, z ticketem, a nie przypadkiem kolejności sortowania.

Informacje o wydaniu v2.0.6, v2.0.7 i v2.0.8 opisują poprawki błędów oraz aktualizacje lub backporty komponentów. Przekaz dotyczący bezpieczeństwa jest krótki: projekt publikuje poprawki, a MSP wdraża przypięte wydanie po oknie zmian. Kto chce zobaczyć listę zgłoszeń, może otworzyć stronę wydań.

Wcześniejsze wydania z 2026 roku, z sierpnia, również zawierały poprawki bezpieczeństwa po stronie kontrolera i routerów, a biuletyny bezpieczeństwa są wymienione w ich informacjach o wydaniu. Praktyczna rada się nie zmienia: przypnij aktualne, zweryfikowane wydanie i traktuj biuletyn bezpieczeństwa jako powód do planowej aktualizacji.

Headscale to serwer koordynacyjny dla innej rodziny nakładek. Ten artykuł nie porównuje z nim list funkcji. Połączenie obu w jedną historię utwardzania ukryłoby, o której płaszczyźnie sterowania naprawdę jest ticket.

Linkerd2 to service mesh z płaszczyzną danych opartą na proxy. OpenZiti, w ujęciu tego artykułu, to nakładka tożsamościowa. To nie jest artykuł o sidecarach w siatce usług, a polityka sidecara nie jest przypięciem wydania kontrolera nakładki. MSP może używać obu. Używanie obu to nie to samo co „jedno zastępuje drugie”.

Tetragon to egzekwowanie polityk w czasie działania i obserwowalność, w innym projekcie. To nie jest to przypięcie. Czujnik obserwujący węzeł nie wybiera tagu OpenZiti, a tag OpenZiti nie staje się polityką czasu działania tylko dlatego, że oba słowa mogą pojawić się na tym samym slajdzie architektury.

Gatekeeper i Kyverno to kontrola dopuszczania (admission) polityk klastra. Nakładka zero-trust nie zastępuje polityki admission w Kubernetes, a polityka admission nie przypina wydania nakładki. To różne obiekty: jedno dopuszcza lub odrzuca żądania API do klastra, drugie trasuje zarejestrowane tożsamości do usług. Traktowanie ich jako zamienników sprawia, że okno zmian gubi zarówno tag nakładki, jak i ograniczenia admission.

Trivy, Prowler, Grype i Syft to skanery i narzędzia SBOM. Wynik skanowania nie jest decyzją o wydaniu nakładki, a ten artykuł nie pożycza ich numerów wersji, by ozdobić przypięcie OpenZiti.

MSP może używać kilku z nich. Błąd kupującego polega na traktowaniu ich jako zamienników. Zadaniem tego artykułu jest przypięcie OpenZiti i higiena tej płaszczyzny sterowania, nic więcej. Jeśli tytuł ticketu dałoby się zamienić na Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno lub Trivy bez zmiany kroków, ticket nie dotyczy tego przypięcia.

Dla każdej z sześciu poniższych kontroli są dowody, które się liczą, i takie, które się nie liczą. Liczba gwiazdek, hasło marketingowe „zero trust” i ruchomy skrót latest nie są dowodem dla żadnej z nich.

Po pierwsze: zinwentaryzuj kontrolery, routery brzegowe i zarejestrowane tożsamości, w tym członków klastra kontrolerów HA, jeśli istnieją. Dowodem jest eksport inwentarza, który nazywa te obiekty i mówi, czy istnieje drugi kontroler. Slajd z napisem „nakładka wdrożona” nie jest takim eksportem.

Po drugie: po oknie zmian przypnij znaną linię. W linii 2.0 minimum to v2.0.6. Wydania pre-release, takie jak v2.0.7 i v2.0.8, nie trafiają do tego ticketu, chyba że klient wyraźnie zaakceptuje pre-release, na piśmie, w tym tickecie. Dowodem jest ciąg tagu w rekordzie zmiany, a nie skrót, który ktoś pobrał rano w dniu okna, bo był na górze listy.

Po trzecie: wymagaj MFA dla administratorów na tożsamościach kontrolera i konsoli administracyjnej, odwołuj nieaktualne rejestracje i stosuj zasadę najmniejszych uprawnień w politykach tożsamości i usług. Dowodem jest ustawienie MFA na tych tożsamościach administracyjnych oraz rejestr odwołań dla rejestracji, które nie mają już właściciela.

Po czwarte: dostęp do płaszczyzny zarządzania tylko z zaufanych sieci administracyjnych lub przez hosty pośredniczące (jump hosts). Publiczna ekspozycja administracji lub rejestracji nie jest ustawieniem domyślnym. Dowodem jest lista dozwolonych adresów albo równoważna reguła dla hosta pośredniczącego, dołączona do ticketu. Schemat zapory bez identyfikatorów reguł to obrazek.

Po piąte: przeprowadzaj ćwiczenia kopii zapasowej i odtwarzania dla modelu danych kontrolera i materiału rejestracyjnego. Odbudowuj z zaufanych nośników i rotuj tożsamości po podejrzeniu kompromitacji. Dowodem jest protokół ćwiczenia odtwarzania: data, kto je przeprowadził i czy odtworzenie dało kontroler, który inwentarz nadal rozpoznaje.

Po szóste: wysyłaj logi audytowe do SIEM. Traktuj nieoczekiwane rejestracje, usunięcia MFA administratorów i niestabilność połączeń routerów jako sygnały operacyjne do obserwowania. Dowodem jest nazwa zapytania w SIEM i właściciel, który je przegląda. Zasobnik logów, którego nikt nie otwiera, to magazyn, a nie nadzór.

Zdanie, które zespół zmian może powtarzać: nie utożsamiaj „wdrożyliśmy nakładkę” z „płaszczyzna sterowania jest przypięta i zabezpieczona”. Wdrożenie to początek inwentarza. Przypięcie i zabezpieczenie to późniejsze tickety i muszą wskazywać linię.

W skrócie: OpenZiti (openziti/ziti) jest udostępniany na licencji Apache-2.0 i miał 4417 gwiazdek na GitHubie według stanu z 4 października 2026. Wersja minimalna w linii 2.0 to v2.0.6, wydana 18 września 2026, a v2.0.7 i v2.0.8 to wciąż wydania pre-release. Strona domowa to openziti.io.

OpenZiti to nie Headscale, nie Linkerd2, nie Tetragon, nie Gatekeeper, nie Kyverno i nie Trivy. Przypnij linię, zabezpiecz płaszczyznę sterowania i trzymaj dowody w tickecie.