Épingler OpenZiti à la v2.0.6 ou à une version ultérieure sur la branche 2.0, et ne pas traiter un tag de pré-version comme l'épinglage client

Épingler OpenZiti à la v2.0.6 ou à une version ultérieure sur la branche 2.0, et ne pas traiter un tag de pré-version comme l'épinglage client

La phrase qu’un MSP entend, c’est : « nous avons un overlay zero trust, donc le réseau plat a disparu ». La réponse : l’overlay est un plan de contrôle qu’il faut quand même inventorier, épingler à une version et verrouiller. Ce n’est pas un slogan qui met fin aux fenêtres de changement. Le projet dont il est question ici est OpenZiti, dépôt openziti/ziti, sous licence Apache-2.0, avec 4417 étoiles et 276 forks sur GitHub au 4 octobre 2026 et un site à l’adresse openziti.io. Ce sont des comptages, pas une affirmation de popularité au-delà du chiffre.

L’épinglage vient dans la foulée. La version complète la plus récente de la branche 2.0 est la v2.0.6, publiée le 18 septembre 2026. La v2.0.7 (25 septembre) et la v2.0.8 (8 octobre) existent aussi, et toutes deux sont encore marquées comme pré-versions.

La suite précise ce que « overlay zero trust programmable » a le droit de signifier : des services routés par identité, un contrôleur, des routeurs de périphérie et des identités enrôlées. Elle dit aussi ce qu’OpenZiti n’est pas, face à six autres produits qui font d’autres métiers. Le conseil de maintenance s’arrête à « appliquer une version épinglée », et les six contrôles défensifs n’ajoutent aucun détail d’attaque.

La phrase sur les fonctionnalités qu’utilise cet article vient de la description du dépôt et de rien d’autre : le projet parent d’OpenZiti fournit les exécutables d’un réseau programmable entièrement zero trust. Les sujets du dépôt incluent overlay, zero-trust et ZTNA, la branche par défaut est main et le langage principal est Go. Aucune topologie haute disponibilité n’est vendue ici comme un fait, aucun chiffre de débit, aucun nombre de clients. Le schéma de la façon dont un client a relié ses contrôleurs est le dossier de conception de ce client, pas une affirmation que cette page pourrait tirer d’un nombre d’étoiles.

Les objets qu’un MSP doit tout de même nommer sont les contrôleurs, les routeurs de périphérie et les identités enrôlées, y compris un maillage de contrôleurs HA si le client en exploite un. Ce sont des noms pour un export d’inventaire. Ce n’est pas un guide d’installation, pas une topologie à copier, ni la promesse que chaque parc dispose du maillage. Si le client n’exploite pas de second contrôleur, l’inventaire le dit. Une ligne HA vide est un fait. Un second contrôleur supposé n’en est pas un.

« Routé par identité » est la phrase destinée à l’acheteur, et elle est étroite. Un service est joint par une identité enrôlée et par une politique, pas parce que l’hôte se trouve sur le LAN du client. C’est la différence qu’un overlay peut revendiquer ici. Ce n’est pas une affirmation selon laquelle une erreur de configuration serait impossible. Une politique trop large, une identité jamais révoquée ou un routeur administré là où il ne devrait pas l’être restent des défaillances opérationnelles ordinaires. L’overlay fait passer la question de « quel sous-réseau » à « quelle identité et quelle politique ». Il ne supprime pas la question.

Les étoiles sont un comptage, et on s’arrête là. Les 4417 étoiles du 4 octobre 2026 ne sont ni une évaluation de sécurité, ni un contrat de support, ni un épinglage. Le dépôt reçoit des push fréquents ; le dernier avant cet article date du 8 octobre 2026. Cela montre que le projet bouge. Cela ne dit pas quel tag un client devrait exécuter.

La licence est Apache-2.0, telle que GitHub l’indique. Une licence renseigne l’acheteur sur les conditions de droit d’auteur. Elle ne lui dit pas quelle version peut entrer sans risque dans une fenêtre de changement, et elle ne remplace pas l’épinglage.

La page des versions se lit mieux comme une courte liste que comme un tableur de condensats. La v2.0.6 (18 septembre 2026) est une version complète. La v2.0.7 (25 septembre) et la v2.0.8 (8 octobre) sont des pré-versions. La v1.6.21 (18 septembre) et la v1.5.18 (22 septembre) sont des versions complètes sur les anciennes branches, et la v2.0.5 (15 septembre) est la version complète précédente de la 2.0. Chaque tag reste dans sa branche. Un tag 1.6 ne devient pas « plus récent que la 2.0 » parce qu’il a été publié plus tard dans la journée, et un tag 2.0 ne met pas fin à une branche de maintenance 1.5 du seul fait d’exister.

La règle d’épinglage tient en une phrase qu’un MSP peut répéter. Sur la branche 2.0, ne pas descendre sous la v2.0.6, ne pas exécuter un latest flottant et ne pas promouvoir la v2.0.7 ni la v2.0.8 tant qu’elles sont marquées comme pré-versions. Un client encore en 1.6 reste sur un tag 1.6 vérifié (le plus récent est la v1.6.21) jusqu’à une migration planifiée, et non parce qu’un tag 2.0 existe. « Prendre la dernière, point » à travers 1.5, 1.6 et 2.0 est la consigne que cet article refuse. Les branches de maintenance existent pour qu’une migration planifiée soit une vraie migration, avec un ticket, et non un accident d’ordre de tri.

Les notes de version des v2.0.6, v2.0.7 et v2.0.8 décrivent des corrections de bogues et des mises à jour ou rétroportages de composants. Le message de sécurité est court : le projet publie des correctifs, et le MSP applique une version épinglée après une fenêtre de changement. Le lecteur qui veut la liste des tickets peut ouvrir la page des versions.

Des versions antérieures de 2026, en août, contenaient elles aussi des correctifs de sécurité côté contrôleur et routeur, avec les avis de sécurité listés dans leurs notes de version. Le conseil pratique ne change pas : épingler une version actuelle et vérifiée, et traiter un avis de sécurité comme une raison de mettre à jour selon le calendrier prévu.

Headscale est un serveur de coordination pour une autre famille d’overlays. Cet article n’en compare pas les listes de fonctionnalités. Fondre les deux dans un même récit de durcissement masquerait le plan de contrôle dont le ticket parle réellement.

Linkerd2 est un service mesh avec un plan de données à proxys. OpenZiti, tel qu’il est traité ici, est un overlay d’identité. Ce n’est pas un article sur les sidecars de maillage, et une politique de sidecar n’est pas l’épinglage de version d’un contrôleur d’overlay. Un MSP peut exploiter les deux. Exploiter les deux ne revient pas à dire « l’un remplace l’autre ».

Tetragon assure l’application de règles à l’exécution et l’observabilité, dans un autre projet. Ce n’est pas cet épinglage. Un capteur qui surveille un nœud ne choisit pas le tag d’OpenZiti, et un tag d’OpenZiti ne devient pas une politique d’exécution parce que les deux mots peuvent figurer sur la même diapositive d’architecture.

Gatekeeper et Kyverno relèvent de l’admission de politiques de cluster. Un overlay zero trust ne remplace pas une politique d’admission Kubernetes, et une politique d’admission n’épingle pas une version d’overlay. Les objets diffèrent : l’un admet ou refuse des requêtes API dans un cluster, l’autre route des identités enrôlées vers des services. Les traiter comme interchangeables, c’est ainsi qu’une fenêtre de changement perd à la fois le tag de l’overlay et les contraintes d’admission.

Trivy, Prowler, Grype et Syft sont des scanners et des outils SBOM. Un résultat de scan n’est pas une décision de version pour un overlay, et cet article n’emprunte pas leurs numéros de version pour décorer un épinglage d’OpenZiti.

Un MSP peut en exploiter plusieurs. L’erreur de l’acheteur est de les traiter comme interchangeables. L’objet de cet article est l’épinglage d’OpenZiti et l’hygiène de ce plan de contrôle, rien d’autre. Si l’on pouvait remplacer le titre du ticket par Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno ou Trivy sans changer les étapes, le ticket ne porte pas sur cet épinglage.

Chacun des six contrôles ci-dessous a des preuves qui comptent et des preuves qui ne comptent pas. Un nombre d’étoiles, un slogan marketing qui dit « zero trust » et un condensat latest flottant ne prouvent aucun d’entre eux.

Premièrement, inventorier les contrôleurs, les routeurs de périphérie et les identités enrôlées, y compris les membres d’un cluster de contrôleurs HA s’ils existent. La preuve est un export d’inventaire qui nomme ces objets et indique s’il existe un second contrôleur. Une diapositive « overlay déployé » n’est pas cet export.

Deuxièmement, épingler une branche connue après la fenêtre de changement. Sur la branche 2.0, le plancher est la v2.0.6. Les pré-versions comme la v2.0.7 et la v2.0.8 restent hors de ce ticket, sauf si le client accepte explicitement une pré-version, par écrit, dans ce ticket. La preuve est la chaîne du tag dans l’enregistrement de changement, pas un condensat récupéré le matin de la fenêtre parce qu’il apparaissait en premier.

Troisièmement, exiger la MFA administrateur sur les identités du contrôleur et de la console d’administration, révoquer les enrôlements obsolètes et appliquer le moindre privilège aux politiques d’identité et de service. La preuve est un paramètre MFA sur ces identités d’administration et un registre de révocation pour les enrôlements qui n’ont plus de responsable.

Quatrièmement, n’accéder au plan de gestion que depuis des réseaux d’administration de confiance ou des hôtes de rebond. Une exposition publique de l’administration ou de l’enrôlement n’est pas un réglage par défaut. La preuve est une liste d’autorisation, ou une règle équivalente sur les hôtes de rebond, jointe au ticket. Un schéma de pare-feu sans identifiants de règles est une image.

Cinquièmement, réaliser des exercices de sauvegarde et de restauration du modèle de données du contrôleur et du matériel d’enrôlement. Reconstruire à partir de supports de confiance et renouveler les identités après une compromission présumée. La preuve est le compte rendu de l’exercice de restauration : la date, qui l’a mené et si la restauration a produit un contrôleur que l’inventaire reconnaît encore.

Sixièmement, envoyer les journaux d’audit vers un SIEM. Traiter les enrôlements inattendus, les suppressions de MFA administrateur et l’instabilité des liens de routeurs comme des signaux opérationnels à surveiller. La preuve est le nom de la requête dans le SIEM et un responsable qui la consulte. Un compartiment de journaux que personne n’ouvre, c’est du stockage, pas de la surveillance.

La phrase que l’équipe des changements peut répéter : ne pas confondre « nous avons déployé un overlay » avec « le plan de contrôle est épinglé et verrouillé ». Le déploiement est le début de l’inventaire. L’épinglage et le verrouillage sont des tickets ultérieurs, et ils doivent nommer une branche.

En bref : OpenZiti (openziti/ziti) est sous licence Apache-2.0 et comptait 4417 étoiles sur GitHub au 4 octobre 2026. Sa version plancher sur la branche 2.0 est la v2.0.6, publiée le 18 septembre 2026, tandis que la v2.0.7 et la v2.0.8 sont encore des pré-versions. Le site du projet est openziti.io.

OpenZiti n’est ni Headscale, ni Linkerd2, ni Tetragon, ni Gatekeeper, ni Kyverno, ni Trivy. Épinglez la branche, verrouillez le plan de contrôle et gardez les preuves dans le ticket.