OpenZiti auf der 2.0-Linie bei v2.0.6 oder neuer pinnen und einen Pre-Release-Tag nicht als Kunden-Pin behandeln

OpenZiti auf der 2.0-Linie bei v2.0.6 oder neuer pinnen und einen Pre-Release-Tag nicht als Kunden-Pin behandeln

Der Satz, den ein MSP hört, lautet: „Wir betreiben ein Zero-Trust-Overlay, also ist das flache Netz weg.“ Die Antwort: Das Overlay ist eine Control Plane, die man trotzdem inventarisieren, auf eine Version pinnen und absichern muss. Es ist kein Slogan, der Änderungsfenster überflüssig macht. Es geht hier um OpenZiti, Repository openziti/ziti, lizenziert unter Apache-2.0, mit 4417 GitHub-Sternen und 276 Forks am 4. Oktober 2026 und einer Homepage unter openziti.io. Das sind Zählwerte, keine Aussage über Beliebtheit, die über die Zahl hinausgeht.

Der Pin gehört in denselben Atemzug. Das neueste vollständige Release auf der 2.0-Linie ist v2.0.6, veröffentlicht am 18. September 2026. Daneben gibt es v2.0.7 (25. September) und v2.0.8 (8. Oktober); beide sind noch als Pre-Release markiert.

Im Folgenden geht es darum, was „programmierbares Zero-Trust-Overlay“ bedeuten darf: identitätsbasiert geroutete Dienste, ein Controller, Edge-Router und registrierte Identitäten. Und darum, was OpenZiti nicht ist, im Vergleich mit sechs anderen Produkten, die andere Aufgaben lösen. Der Wartungsrat endet bei „ein gepinntes Release einspielen“, und die sechs Verteidigungskontrollen fügen keine Angriffsdetails hinzu.

Der Funktionssatz, den dieser Artikel verwendet, stammt aus der Repository-Beschreibung und aus nichts anderem: Das Hauptprojekt von OpenZiti liefert die Programme für ein vollständig zero-trust-basiertes, programmierbares Netzwerk. Zu den Topics des Repositorys gehören overlay, zero-trust und ZTNA, der Standard-Branch ist main, und die Hauptsprache ist Go. Hier wird keine Hochverfügbarkeits-Topologie als Tatsache verkauft, keine Durchsatzzahl und keine Kundenzahl. Ein Diagramm, wie ein Kunde seine Controller verbunden hat, ist dessen Designdokumentation, keine Aussage, die diese Seite aus einer Sternezahl ableiten kann.

Die Objekte, die ein MSP trotzdem benennen muss, sind Controller, Edge-Router und registrierte Identitäten, einschließlich eines HA-Controller-Mesh, falls der Kunde eines betreibt. Das sind Namen für einen Inventarexport. Sie sind keine Bauanleitung, keine Topologie zum Kopieren und kein Versprechen, dass jede Umgebung das Mesh hat. Betreibt der Kunde keinen zweiten Controller, sagt das Inventar genau das. Eine leere HA-Zeile ist eine Tatsache. Ein geratener zweiter Controller ist es nicht.

„Identitätsbasiert geroutet“ ist der Satz für den Käufer, und er ist eng gefasst. Ein Dienst wird über eine registrierte Identität und eine Richtlinie erreicht, nicht weil der Host zufällig im Kunden-LAN steht. Das ist der Unterschied, den ein Overlay hier beanspruchen darf. Es ist keine Behauptung, dass Fehlkonfigurationen unmöglich wären. Eine zu weite Richtlinie, eine nie widerrufene Identität oder ein Router, der dort verwaltet wird, wo er es nicht sollte, bleiben gewöhnliche Betriebsfehler. Das Overlay verschiebt die Frage von „welches Subnetz“ zu „welche Identität und welche Richtlinie“. Es schafft die Frage nicht ab.

Sterne sind ein Zählwert, dann ist Schluss. Die 4417 Sterne vom 4. Oktober 2026 sind keine Sicherheitsbewertung, kein Supportvertrag und kein Pin. Das Repository erhält häufig Pushes; der letzte vor diesem Artikel war am 8. Oktober 2026. Das zeigt, dass sich das Projekt bewegt. Es sagt nicht, welchen Tag ein Kunde betreiben sollte.

Die Lizenz ist Apache-2.0, wie GitHub sie angibt. Eine Lizenz informiert den Käufer über Urheberrechtsbedingungen. Sie sagt ihm nicht, welches Release sicher in ein Änderungsfenster gehört, und sie ersetzt den Pin nicht.

Die Release-Seite liest sich am besten als kurze Liste, nicht als Tabelle voller Digests. v2.0.6 (18. September 2026) ist ein vollständiges Release. v2.0.7 (25. September) und v2.0.8 (8. Oktober) sind Pre-Releases. v1.6.21 (18. September) und v1.5.18 (22. September) sind vollständige Releases auf den älteren Linien, und v2.0.5 (15. September) ist das vorherige vollständige 2.0-Release. Jeder Tag bleibt in seiner Linie. Ein 1.6-Tag wird nicht „neuer als 2.0“, weil er später am Tag veröffentlicht wurde, und ein 2.0-Tag beendet keine 1.5-Wartungslinie, nur weil es ihn gibt.

Die Pin-Regel ist ein Satz, den ein MSP wiederholen kann. Auf der 2.0-Linie nicht unter v2.0.6 gehen, kein schwebendes latest betreiben und weder v2.0.7 noch v2.0.8 freigeben, solange sie als Pre-Release markiert sind. Ein Kunde, der noch auf 1.6 ist, bleibt bis zu einem geplanten Wechsel auf einem geprüften 1.6-Tag (der neueste ist v1.6.21), nicht weil es einen 2.0-Tag gibt. „Einfach das Neueste nehmen“ über 1.5, 1.6 und 2.0 hinweg ist die Anweisung, die dieser Artikel ablehnt. Wartungslinien gibt es, damit ein geplanter Wechsel ein Wechsel mit Ticket ist und kein Zufall der Sortierreihenfolge.

Die Release Notes zu v2.0.6, v2.0.7 und v2.0.8 beschreiben Fehlerbehebungen sowie Komponenten-Updates oder Backports. Die Sicherheitsbotschaft ist kurz: Das Projekt liefert Korrekturen, und der MSP spielt nach einem Änderungsfenster ein gepinntes Release ein. Wer die Liste der Issues sehen will, kann die Release-Seite öffnen.

Auch frühere Releases aus dem Jahr 2026, im August, enthielten Sicherheitskorrekturen auf Controller- und Router-Seite; die Advisories stehen in ihren Release Notes. Der praktische Rat bleibt derselbe: ein aktuelles, geprüftes Release pinnen und ein Advisory als Grund behandeln, planmäßig zu aktualisieren.

Headscale ist ein Koordinationsserver für eine andere Overlay-Familie. Dieser Artikel vergleicht keine Funktionslisten damit. Beide in eine Härtungsgeschichte zu packen, würde verdecken, um welche Control Plane es im Ticket tatsächlich geht.

Linkerd2 ist ein Service Mesh mit Proxy-Datenebene. OpenZiti, wie es hier behandelt wird, ist ein Identitäts-Overlay. Dies ist kein Artikel über Mesh-Sidecars, und eine Sidecar-Richtlinie ist kein Release-Pin für einen Overlay-Controller. Ein MSP kann beides betreiben. Beides zu betreiben ist nicht derselbe Satz wie „das eine ersetzt das andere“.

Tetragon ist Laufzeit- und Observability-Durchsetzung in einem anderen Projekt. Es ist nicht dieser Pin. Ein Sensor, der einen Knoten beobachtet, wählt nicht den OpenZiti-Tag, und ein OpenZiti-Tag wird nicht zur Laufzeitrichtlinie, nur weil beide Begriffe auf derselben Architekturfolie stehen können.

Gatekeeper und Kyverno sind Admission-Kontrolle für Cluster-Richtlinien. Ein Zero-Trust-Overlay ersetzt keine Kubernetes-Admission-Richtlinie, und eine Admission-Richtlinie pinnt kein Overlay-Release. Die Objekte sind verschieden: Das eine lässt API-Anfragen in einen Cluster zu oder lehnt sie ab, das andere routet registrierte Identitäten zu Diensten. Wer sie als Ersatz füreinander behandelt, verliert im Änderungsfenster sowohl den Overlay-Tag als auch die Admission-Vorgaben.

Trivy, Prowler, Grype und Syft sind Scanner und SBOM-Werkzeuge. Ein Scanner-Befund ist keine Release-Entscheidung für ein Overlay, und dieser Artikel leiht sich ihre Versionsangaben nicht, um einen OpenZiti-Pin auszuschmücken.

Ein MSP kann mehrere davon betreiben. Der Fehler des Käufers ist, sie als austauschbar zu behandeln. Aufgabe dieses Artikels sind der OpenZiti-Pin und die Hygiene dieser Control Plane, nichts anderes. Ließe sich der Titel des Tickets gegen Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno oder Trivy tauschen, ohne die Schritte zu ändern, geht es im Ticket nicht um diesen Pin.

Für jede der sechs folgenden Kontrollen gibt es Nachweise, die zählen, und solche, die nicht zählen. Eine Sternezahl, ein Marketingsatz mit „Zero Trust“ und ein schwebender latest-Digest sind für keine davon ein Nachweis.

Erstens: Controller, Edge-Router und registrierte Identitäten inventarisieren, einschließlich der HA-Controller-Mitglieder, falls vorhanden. Nachweis ist ein Inventarexport, der diese Objekte benennt und angibt, ob es einen zweiten Controller gibt. Eine Folie mit „Overlay ausgerollt“ ist dieser Export nicht.

Zweitens: nach dem Änderungsfenster eine bekannte Linie pinnen. Auf der 2.0-Linie ist die Untergrenze v2.0.6. Pre-Releases wie v2.0.7 und v2.0.8 bleiben aus diesem Ticket draußen, es sei denn, der Kunde akzeptiert ein Pre-Release ausdrücklich und schriftlich in genau diesem Ticket. Nachweis ist der Tag-String im Change Record, nicht ein Digest, den jemand am Morgen des Fensters gezogen hat, weil er oben stand.

Drittens: Admin-MFA für Controller- und Admin-Konsolen-Identitäten verlangen, veraltete Registrierungen widerrufen und minimale Rechte bei Identitäts- und Dienstrichtlinien einhalten. Nachweis ist eine MFA-Einstellung für diese Admin-Identitäten und ein Widerrufsprotokoll für Registrierungen, die keinen Verantwortlichen mehr haben.

Viertens: die Management-Ebene nur aus vertrauenswürdigen Admin-Netzen oder über Jump-Hosts erreichen. Öffentlich erreichbare Administration oder Registrierung ist kein Standard. Nachweis ist eine Allowlist oder eine gleichwertige Jump-Host-Regel, die dem Ticket beiliegt. Ein Firewall-Diagramm ohne Regelkennungen ist ein Bild.

Fünftens: Backup- und Wiederherstellungsübungen für das Controller-Datenmodell und das Registrierungsmaterial durchführen. Aus vertrauenswürdigen Medien neu aufbauen und Identitäten nach einer vermuteten Kompromittierung rotieren. Nachweis ist ein Protokoll der Wiederherstellungsübung: das Datum, wer sie durchgeführt hat und ob die Wiederherstellung einen Controller ergab, den das Inventar noch erkennt.

Sechstens: Audit-Logs an ein SIEM senden. Unerwartete Registrierungen, entfernte Admin-MFA und instabile Router-Verbindungen als betriebliche Signale beobachten. Nachweis ist der Name der Abfrage im SIEM und ein Verantwortlicher, der sie ansieht. Ein Log-Bucket, den niemand öffnet, ist Speicher, keine Überwachung.

Der Satz, den das Change-Team wiederholen kann: „Wir haben ein Overlay ausgerollt“ ist nicht dasselbe wie „die Control Plane ist gepinnt und abgesichert“. Das Ausrollen ist der Anfang des Inventars. Pin und Absicherung sind spätere Tickets, und sie müssen eine Linie benennen.

Kurz gesagt: OpenZiti (openziti/ziti) steht unter der Lizenz Apache-2.0 und hatte am 4. Oktober 2026 4417 GitHub-Sterne. Die Mindestversion auf der 2.0-Linie ist v2.0.6, veröffentlicht am 18. September 2026, während v2.0.7 und v2.0.8 noch Pre-Releases sind. Die Homepage ist openziti.io.

OpenZiti ist nicht Headscale, nicht Linkerd2, nicht Tetragon, nicht Gatekeeper, nicht Kyverno und nicht Trivy. Linie pinnen, Control Plane absichern und die Nachweise im Ticket ablegen.