OpenZiti : zero-trust networking applicatif open source

Le VPN d'entreprise classique est un réseau plat. Une fois connecté, on accède à tout le LAN. Si le poste qui se connecte est compromis, c'est le LAN entier qui est exposé. La promesse zero-trust depuis 10 ans : ne jamais faire confiance par défaut, authentifier chaque flux applicatif, segmenter au niveau service.

OpenZiti est l'implémentation open source la plus complète de ce modèle. Projet porté par NetFoundry, sous Apache 2.0, il fournit un overlay applicatif où chaque connexion est authentifiée, autorisée, chiffrée par identité, sans exposer de port public. Les services deviennent "dark" : invisibles depuis Internet, joignables uniquement par les identités autorisées via le fabric Ziti.

Pour les organisations qui veulent dépasser le modèle "VPN + firewall périphérique", c'est une option mature en 2026.

• Le modèle zero-trust applicatif
• Architecture OpenZiti : controller, edge, fabric
• Identité, policy, et services
• Déploiement en pratique
• Embedded vs Tunneler vs Edge Routers
• Cas d'usage : SaaS, IoT, accès remote
• Comparaison avec Tailscale, ZeroTier, Cloudflare ZT
• Limites et signaux d'alerte

Le NIST SP 800-207 définit zero-trust avec trois principes :

1. Pas de confiance implicite par localisation réseau.
2. Authentification continue de chaque session.
3. Autorisation par identité, par flux, par contexte.

Les VPN classiques (OpenVPN, IPsec, WireGuard) violent ces principes : une fois authentifié, le client est sur le LAN, libre de bouger. Les firewalls L3-L4 ne savent pas qui ouvre la connexion.

Tailscale et Headscale avancent dans le bon sens : authentification par identité, mais le modèle reste largement réseau (les noeuds se voient mutuellement par défaut).

OpenZiti pousse plus loin : on ne se connecte pas à un réseau, on se connecte à un service. Chaque flux applicatif est une session séparée, autorisée par policy, chiffrée mTLS, et auditée.

OpenZiti est composé de trois plans :

Controller : le cerveau. Stocke les identités, les services, les policies. API REST + ZAC (Ziti Admin Console). Pas dans le data plane, juste l'orchestration. SQLite ou PostgreSQL.

Edge : composants qui terminent les connexions clients et exposent les services backends. Trois variantes :

• Tunneler : agent installé sur poste client ou serveur, capture le trafic vers les services Ziti.
• Edge Router : noeud du fabric, point d'entrée pour des clients externes.
• Embedded SDK : intégration directe dans une application via les SDK Go, Python, Java, .NET, etc. L'app parle Ziti nativement, pas de tunnel TCP.

Fabric : le réseau interne entre Edge Routers. Mesh chiffré mTLS, pondération de chemin par latence, failover automatique. Le fabric peut être hébergé n'importe où : public cloud, privé, mix.

L'architecture découple complètement le data plane (fabric) du control plane (controller). Le controller peut tomber, le fabric continue de servir le trafic existant. Au fail du controller, on perd la capacité à provisionner de nouveaux liens.

Trois concepts clés.

Identités : chaque entité (utilisateur, serveur, application) a une identité dans Ziti, matérialisée par un certificat client signé par la CA Ziti. Pas de partage d'identité, pas de mots de passe partagés.

Services : ressources accessibles via Ziti. Un service a un nom (prod-postgres), un endpoint backend (10.0.0.5:5432), et des policies d'accès.

Policies : règles "qui peut accéder à quel service depuis quel contexte". Exprimées par tags : attribute=ops,environment=prod autorisé sur service=prod-postgres.

# Exemple de policy de service
service-policy:
  name: ops-can-access-prod-db
  type: Bind
  semantic: AllOf
  identityRoles: ['#ops-team']
  serviceRoles: ['@prod-postgres']
  postureChecks: ['@yubikey-required', '@disk-encryption-on']

Les postureChecks sont des vérifications côté client (chiffrement disque actif, antivirus à jour, OS patché, présence d'une YubiKey). Si l'identité ne respecte pas, accès refusé.

C'est un modèle d'accès par identité + contexte, applicable par flux, pas par session.

Stack minimale OpenZiti :

# Bootstrap automatique (controller + 1 edge router en local)
curl -sLf https://get.openziti.io/bootstrap.bash | bash

# Démarre :
# - controller sur :1280
# - edge router sur :3022
# - ZAC (UI) sur https://localhost:8443

Pour un déploiement prod : Controller sur un VPS public ou privé, 2-3 Edge Routers répartis géographiquement, agents Tunneler sur les machines clients et serveurs.

Le fabric communique en mTLS sur des ports configurables. Pas de port unique magique : l'architecture est explicite.

Pour un Edge Router public exposé Internet : le port d'écoute (par défaut 443) accepte uniquement des connexions Ziti authentifiées. Pas de "service exposed" classique : la connexion entrante est filtrée par identité Ziti avant d'atteindre le backend.

C'est ça le concept "dark service" : le port 443 du Edge Router est ouvert publiquement, mais sans identité Ziti valide, la connexion est rejetée silencieusement. Pas de surface d'attaque applicative.

Trois modes d'intégration côté client / serveur, par ordre de complexité.

Tunneler (le plus simple). Agent système qui capture le trafic IP local et le redirige vers Ziti. L'app legacy continue de croire qu'elle parle à 10.0.0.5:5432, le tunneler intercepte et tunnelise via Ziti.

# Linux tunneler
sudo ziti-edge-tunnel run -i alice.json
# alice.json contient l'identité enrollée

Avantage : pas de modification d'application. Inconvénient : nécessite un agent privilégié.

Embedded SDK (le plus efficace). L'application appelle directement les API Ziti :

import "github.com/openziti/sdk-golang/ziti"

cfg, _ := ziti.NewConfigFromFile("alice.json")
ctx := ziti.NewContext(cfg)
conn, _ := ctx.Dial("prod-postgres")
// conn est une socket Ziti, pas une socket TCP classique

Avantage : pas d'agent, intégration native. Inconvénient : modification d'application requise.

Edge Router (le plus opérable pour clients externes). Pour exposer un service à des clients externes qui ne veulent pas installer d'agent. Edge Router devient un endpoint TLS standard (avec auth client cert) qui forward vers Ziti.

Choix dépend du contexte : lab interne et serveurs prod = Tunneler ou SDK. Service exposé à des partenaires externes = Edge Router.

SaaS B2B avec accès client privé. Au lieu d'exposer une API REST sur Internet, exposer un service Ziti. Chaque client B2B a son identité Ziti. Pas de DDoS, pas de scan, pas d'exposition. C'est exactement le pattern qu'utilise NetFoundry pour ses produits.

IoT / OT remote management. Boitiers en bord de site, accédés depuis un NOC central. Ziti Tunneler embedded dans le firmware, identité provisioned au boot. Pas de port ouvert sur le boitier. Pas d'IP publique nécessaire.

Accès remote employés. Au lieu d'un VPN qui donne accès au LAN entier, chaque service interne est exposé comme service Ziti, l'identité de l'employé détermine ce qu'il peut accéder. Granularité par service.

Multi-cloud private connectivity. Cluster K8s sur AWS, base de données sur GCP, backup sur OVH. Au lieu de peering VPC complexe, un fabric Ziti chiffré qui connecte les services entre eux par identité.

Rotation continue. Un service compromis (clé volée, pod corrompu) est exclu du fabric par révocation. Les autres restent fonctionnels. Pas de re-déploiement réseau global.

OpenZiti descend à une granularité plus fine (par service, par session), mais demande plus d'investissement. Tailscale s'opère plus simplement pour un mesh d'employés. Cloudflare couvre le besoin, mais reste propriétaire et managé.

Pour des stacks zero-trust applicatif vraiment self-hostées, OpenZiti est l'option la plus complète en 2026.

Courbe d'apprentissage. Les concepts (identités, services, policies, postures, edge routers, tunnel mode) sont nombreux. Compter 2-3 semaines pour qu'une équipe ops soit autonome.

SDK maturité variable. Go et Python sont matures. .NET, Java, Swift sont OK. Rust et autres en cours.

Latence overlay. Comme tout overlay, ajout de quelques ms par hop fabric. Pour des apps low-latency (HFT, gaming), à mesurer.

Outillage observabilité. Prometheus exporters disponibles mais ergonomie en cours d'amélioration.

Pas de NAT classique. Si on a besoin de tunnels site-to-site classiques (deux LANs A et B qui se voient transparent), OpenZiti n'est pas l'outil. Reste sur du WireGuard.

Compatibilité applicative. Les apps qui parlent UDP, multicast, ou ICMP sont moins bien supportées que TCP. Vérifier en amont.

Rotation des certs. La rotation est gérée mais demande une stratégie. Documenter le runbook.

Communauté plus petite. NetFoundry est le sponsor principal. Si NetFoundry pivote, le projet reste open source mais le rythme peut ralentir. Risque inhérent à tout projet sponsorisé.

OpenZiti livre ce qu'il promet : zero-trust applicatif, services dark, granularité par flux. Le coût d'apprentissage est réel, le bénéfice sécurité aussi. Pour une organisation qui démarre un projet zero-trust et veut éviter le piège du Tailscale "qui ressemble à du VPN amélioré", OpenZiti mérite l'examen. Cadrer la trajectoire sur un périmètre limité avant d'engager évite les fausses routes, un cadrage qui se délègue volontiers à une équipe d'exploitation.

• OpenZiti documentation officielle : référence concepts, install, ops.
• GitHub openziti/ziti : code source controller et edge.
• NetFoundry blog : analyses techniques par les sponsors du projet.
• NIST SP 800-207 Zero Trust Architecture : référentiel ZT officiel.
• BeyondCorp Google paper : papier fondateur du concept de zero-trust applicatif.
• Awesome Ziti : ressources et exemples communautaires.