- Octelium est une plateforme open source auto-hébergée de nouvelle génération qui prend en charge de façon unifiée le VPN d’accès distant, le ZTNA, les passerelles API/IA, etc.
- Grâce à l’auto-hébergement et au mode mono-tenant, elle fournit un accès sécurisé basé sur l’identité et sur la couche applicative (couche 7) à toutes les ressources internes et publiques
- Inclut des fonctions répondant aux exigences de sécurité modernes, comme l’accès sans secrets (secret-less), le contrôle fin fondé sur des politiques, l’administration centralisée et l’audit
- Peut offrir un avantage concurrentiel et remplacer diverses solutions commerciales ou open source existantes, comme Kubernetes, OpenVPN, Tailscale, Cloudflare Access, etc.
- Adopte un modèle open source et construit son activité via la prise en charge de fonctionnalités commerciales et la licence, tout en mettant l’accent sur un auto-hébergement complet
Importance et aperçu du projet Octelium
- Octelium est une plateforme unifiée de sécurité d’accès Zero Trust, open source, auto-hébergée et de nouvelle génération, capable de remplacer des solutions commerciales comme Teleport, Cloudflare, Tailscale et Ngrok.
- Par rapport aux solutions open source et commerciales existantes, son grand avantage est de pouvoir être entièrement auto-hébergée sans compromis sur les fonctionnalités, tout en évitant les coûts supplémentaires et la dépendance fournisseur.
Qu’est-ce qu’Octelium ?
- Octelium est une plateforme unifiée de gestion des accès appliquant des mécanismes basés sur l’identité et la couche 7
- C’est à la fois une alternative aux VPN d’accès distant (OpenVPN Access Server, Twingate, Tailscale, etc.) et une solution adaptée à de nombreux usages : ZTNA, BeyondCorp (Google BeyondCorp, Cloudflare Access, Teleport, etc.), ngrok (reverse proxy), passerelle API/IA, infrastructure PaaS auto-hébergée, alternative à l’ingress Kubernetes, infrastructure Homelab, etc.
- Pour l’accès des utilisateurs (humains comme workloads), des organisations et des applications, elle prend en charge à la fois un mode client basé sur des tunnels WireGuard/QUIC et un accès navigateur sans client de type BeyondCorp
- Ses éléments centraux sont le policy-as-code, qui permet de définir les politiques sous forme de code, ainsi que la sécurité contextuelle et basée sur l’identité, l’authentification sans secrets et l’autorisation fine
Principaux cas d’usage
- VPN d’accès distant moderne : basé sur WireGuard/QUIC, avec sécurité dynamique, sensible à l’identité et à la couche applicative
- Mise en place unifiée d’accès ZTNA/BeyondCorp
- Tunnel sécurisé / reverse proxy auto-hébergé (alternative à ngrok et Cloudflare Tunnel)
- PaaS auto-hébergé (déploiement et montée en charge d’applications conteneurisées, hébergement public anonyme)
- Passerelle API (alternative à Kong Gateway et Apigee)
- Passerelle IA (connexion aux fournisseurs de LLM et contrôle basé sur l’identité)
- Accès unifié et sans secrets aux API SaaS
- Fourniture d’une infrastructure de passerelle MCP/A2A (standards de contexte de modèle et de communication entre agents)
- Alternative avancée à l’ingress / au load balancer Kubernetes
- Homelab (administration distante sécurisée et unifiée de ressources personnelles, IoT, cloud, etc.)
Principales caractéristiques
Architecture moderne unifiée
- Contrôle granulaire, sensible à l’identité et au niveau applicatif pour toutes les ressources (internes/derrière un NAT, publiques) et tous les utilisateurs (humains/workloads)
- Fournit à la fois l’accès distant fondé sur un VPN et l’accès sans client de type BeyondCorp
- Fonctionne sur Kubernetes, avec montée en charge horizontale et haute disponibilité intégrées
Accès dynamique sans secrets (secret-less)
- Prend en charge un accès sécurisé à de nombreuses applications et bases de données — HTTP/gRPC API, applications web, SSH, Kubernetes, PostgreSQL/MySQL, etc. — sans gestion ni partage de clés secrètes
- Permet aussi l’accès via mTLS sans partage de PKI ni de certificats
Contrôle d’accès contextuel, basé sur l’identité et sur la couche 7
- Intègre un système de politiques (ABAC) central, modulaire et composable
- Prend en charge des langages de politique comme CEL et OPA, avec un contrôle fin à l’échelle de chaque requête
Routage et configuration dynamiques
- Le routage fondé sur des politiques permet, pour une même ressource, des contextes supérieurs, comptes et conditions de routage différents
Authentification forte continue
- Intégration avec des IdP standards comme OpenID Connect et SAML2.0
- Les workloads utilisent des jetons OIDC pour une authentification sans secret
- Prise en charge des niveaux d’assurance NIST, de la MFA et de la protection contre le phishing (Passkey, Yubikey, etc.)
Visibilité approfondie et audit au niveau applicatif
- Intégration OpenTelemetry, avec journalisation en temps réel de toutes les requêtes et envoi vers des collecteurs OTLP externes
SSH serverless et déploiement d’applications conteneurisées
- Accès SSH possible, sans privilèges root, même vers des conteneurs, des objets IoT et des hôtes sans SSH
- Prend en charge le déploiement, la montée en charge et l’accès sécurisé à des applications conteneurisées de type PaaS
Administration centralisée déclarative et programmable
- Administration déclarative à la manière de Kubernetes ; l’état du cluster peut être reproduit avec une seule commande ou par le code
- Exploitation compatible DevOps/GitOps via la CLI
octeliumctl et l’API gRPC
Aucun changement réseau requis et résolution des problèmes classiques des VPN
- Les ressources amont n’ont pas besoin de connaître l’existence même d’Octelium, et les services peuvent fonctionner en toute sécurité derrière un NAT sans ouverture de ports
- Automatisation de la configuration, notamment avec IP privées dual-stack dédiées et DNS privé
Totalement open source, auto-hébergé et sans dépendance fournisseur
- Code source complet publié, sans limitation fonctionnelle dans la version commerciale ni verrouillage fournisseur
- Prend en charge des déploiements évolutifs, du mini-cluster sur un seul nœud jusqu’aux grands environnements cloud
Licence et support
- Le code client est sous Apache 2.0, le cluster sous AGPLv3
- Licence commerciale et support entreprise disponibles ; les contributions externes sont actuellement limitées
- Support communautaire via la documentation officielle, Discord, Slack, e-mail, Reddit, etc.
Résumé des principaux points de la FAQ
- Le projet est actuellement en phase de bêta publique, après une longue période de développement interne avant le passage à l’open source
- Il est piloté par un seul développeur, George Badawi, et fonctionne de manière indépendante, sans VC ni capitaux externes
- Peut jouer le rôle d’un VPN, mais vise fondamentalement une architecture ZTA reposant sur des proxys sensibles à l’identité
- Il n’impose pas de restrictions « peu compatibles avec l’esprit open source » ni de contraintes commerciales, et l’auto-hébergement avec toutes les fonctionnalités est un objectif de conception
- Son modèle économique repose sur le support technique, les licences commerciales et des fonctionnalités additionnelles pour les entreprises (par ex. intégration SIEM, backend Vault, EDR)
1 commentaires
Avis Hacker News
Pour ceux qui ont du mal à comprendre ce que fait Octelium, j’ai trouvé l’explication la plus claire ici et je la partage : le lien Comment fonctionne Octelium - documentation officielle est le plus facile à saisir. Au lieu de semer la confusion en listant toutes les fonctionnalités possibles d’Octelium, l’approche qui part des concepts fondamentaux puis les explique progressivement est séduisante. Les fonctions principales sont une passerelle de type VPN capable de prendre des décisions de sécurité granulaires en fonction du contenu tout en comprenant des protocoles avancés, ainsi qu’une couche de configuration de cluster construite au-dessus de Kubernetes. La combinaison des deux revient à créer un « cloud personnel ». Comme les grandes plateformes cloud, cela offre énormément de possibilités, mais il est difficile de savoir par où commencer. Cela semble être un excellent système, avec des usages potentiels variés : homelab personnel, petite entreprise cherchant à réduire ses coûts cloud, PaaS sur mesure, etc.
Tailscale me satisfait, mais je ressens le besoin d’un concurrent. Une IPO semble se profiler, et à ce stade, en l’absence de concurrence, les prix risquent fortement d’augmenter brutalement.
On peut le résumer comme une infrastructure programmable de tunnels réseau.
À titre personnel, je vois plusieurs problèmes, et je partage pourquoi cela pousse forcément les utilisateurs à être sceptiques : absence d’historique de développement, énorme premier commit sorti de nulle part, peu d’informations publiques, impression qu’il n’existe même pas de vraie entreprise, marketing affirmant tout résoudre, sécurité avancée sans preuves, etc. Tout cela nuit à la confiance. Dans une telle situation, il faut plus d’informations pour savoir s’il s’agit d’une vraie technologie maison ou si c’est construit sur des briques existantes suffisamment fiables. Si cela doit être lancé comme une activité commerciale, il faut établir sa crédibilité. À l’inverse, si c’est un projet personnel, lui donner une apparence de business peut au contraire passer pour du faux, une arnaque ou un signal d’alerte. Il est difficile d’être positif face à l’idée qu’un développeur solo sorte soudain un produit capable de concurrencer de grands acteurs. Il est important de mettre clairement l’accent sur la sécurité. S’il est difficile d’expliquer l’objectif du logiciel en une seule phrase, la bataille s’annonce rude. Énumérer encore plus de fonctionnalités n’est pas la solution. Au contraire, cela donne une impression de « installe-moi quoi qu’il arrive », ce qui finit par ôter toute envie d’essayer. Il est souligné que cela risque fort d’entraver le succès du projet.
C’est un excellent retour. Je comprends la légitimité de la critique, dans la mesure où Octelium a été volontairement conçu pour assurer plusieurs fonctions à la fois. Octelium est une plateforme unifiée et généraliste d’accès zero trust, utilisable dans de nombreux cas entre humains et workloads, ainsi qu’entre workloads eux-mêmes (la documentation donne divers exemples en détail). Il est donc compréhensible que cela soit déroutant pour un nouvel utilisateur. Si le premier commit est apparu d’un coup, c’est parce que le développement a en réalité commencé début 2020, mais qu’au moment de publier le code, j’ai préféré repartir d’un dépôt public propre sans historique initial, afin d’éviter tout risque de fuite d’informations personnelles. Au cours des cinq dernières années, j’ai fait près de 9 000 commits manuels ; au départ, c’était un simple VPN WireGuard d’accès à distance, puis cela a complètement évolué vers l’architecture, les fonctionnalités et la complexité actuelles.
Il faut faire preuve d’indulgence envers les développeurs open source. Personne ne connaît le parcours ni les motivations de l’OP, et il fait peut-être simplement cela pour le plaisir. Il n’a pas à se justifier. C’est de l’open source et du logiciel libre. Quant à la critique selon laquelle on ne peut pas décrire le produit en une phrase, on peut le résumer assez simplement, comme tailscale, cloudflare access ou ngrok. Si l’on n’a pas besoin de ce type de produit, alors on n’a de toute façon pas besoin de celui-ci non plus.
J’ai regardé Octelium récemment, et on dirait qu’un cluster Kubernetes est requis à l’installation. Si c’est bien le cas, la barrière à l’entrée est beaucoup trop élevée. Nous voulons attacher des nœuds à un réseau overlay, pas ajouter une dépendance à une autre couche d’infrastructure comme k8s. Étant donné qu’un tel outil devrait avoir un minimum, voire aucune dépendance à des services internes, ce choix me surprend. S’il faut un SDN au-dessus du cluster, alors c’est peut-être la vraie cible, mais je me demande si ce n’est que cela. J’espère que l’intégration k8s est optionnelle, et non un prérequis obligatoire ou le seul mode de déploiement. Si quelqu’un a des ressources sur l’utilisation d’Octelium sans k8s, je suis preneur.
octeliumctl applypour que tous les services soient automatiquement déployés, gérés, scalés puis supprimés si nécessaire. Aucune opération manuelle n’est requise, comme ouvrir des ports de firewall. De la même manière que Kubernetes gère les conteneurs, Octelium orchestre automatiquement les services, proxys, etc. Il n’y a pas non plus de gestion complexe à faire sur le nombre de nœuds ou le réseau CRI. Le cluster couvre l’ensemble des nœuds et peut être administré de manière déclarative et programmable. Exploiter Octelium ne nécessite aucune compréhension approfondie de Kubernetes ; en dehors de quelques tâches spécifiques comme le dimensionnement du cluster k8s lui-même ou la configuration des certificats TLS, on manipule simplement Octelium. Pour plus de détails, je recommande la documentation officielle.Le fait de voir autant de buzzwords me fait immédiatement beaucoup douter. Même en regardant la page GitHub, j’ai du mal à comprendre concrètement ce que fait le produit.
Globalement, il existe déjà trop de produits similaires : Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird, etc. Chacun a ses avantages et ses inconvénients, mais dans la pratique je trouve que les différences réelles restent minimes. La fonctionnalité que je veux vraiment, personnellement, c’est un « lighthouse » zero trust. Avec Zerotier ou Tailscale, le service a le pouvoir d’ajouter des nœuds à mon compte ou à mon réseau. Ce que je veux, c’est un self-hosting complet, avec un lighthouse qui ne fasse pas partie du réseau lui-même et serve uniquement à observer les nœuds. Je vais devoir creuser davantage.
Après lecture de la documentation, j’ai l’impression que beaucoup de gens passent à côté de la vraie valeur d’Octelium. Si cela fonctionne réellement comme décrit, cela pourrait être une perle encore méconnue. Ce que les entreprises veulent, c’est sortir de la sécurité périmétrique classique pour aller vers le modèle présenté par Google überProxy/BeyondCorp — un concept qui a depuis été dilué par toutes sortes de buzzwords —, à savoir une séparation propre entre systèmes de production, réseau interne de l’entreprise et Internet public, une UX aussi transparente que possible pour les employés, une gestion explicite des autorisations sur le trafic traversant ces frontières, et une authentification forte de l’identité de tous les clients. En dehors de Google, les contraintes sont fortes à cause de la diversité des protocoles. Les proxys conscients des protocoles permettent déjà mieux que de simples décisions coarse-grain et du logging, mais lorsqu’ils vont jusqu’à l’inférence de type, on peut alors appliquer un contrôle d’accès bien plus fin à l’échelle de chaque requête (toutes les conditions de chaque requête étant exposées au moteur de politiques). La documentation est verbeuse et le marketing manque de fluidité, mais le problème lui-même est si complexe que personne ne l’a vraiment résolu complètement. Teleport a été parmi les premiers à avancer à la fois côté OSS et commercial, et StrongDM tente aussi des choses intéressantes. J’aimerais également que Hashicorp investisse davantage dans ce domaine (avis personnel).
Octelium peut certes remplacer les produits mentionnés plus haut, mais son ambition et ses cas d’usage sont plus larges, avec une orientation clairement zero trust. C’est bien plus qu’un simple outil de VPN ou d’accès distant. J’aimerais vraiment que l’on prenne le temps de lire la documentation pour comprendre l’intention, l’architecture et les fonctionnalités. Aujourd’hui, tout le monde présente son produit comme « zero trust », mais les véritables ZTA telles que définies par le NIST — c’est-à-dire proxy conscient de la couche L7, point de décision de politique, contrôle d’accès granulaire par requête fondé sur du code de politique, identité centralisée, intégration d’informations issues d’outils externes de SIEM/SSO/threat intelligence, etc. — restent rares. En pratique, parmi les produits commerciaux réellement classés comme « vraie » ZTA, on trouve Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, etc. Au contraire, les entreprises ont tellement abusé de ce terme qu’elles ont fortement dilué le concept de « vrai zero trust ».
Voir le mode cathedral de sanctum. C’est entièrement self-hosted, et les nœuds servent uniquement à la découverte. Une fois le tunnel établi, le nœud cathedral n’intervient plus, sauf pour la distribution de black keys ou quand un pair est derrière un NAT. Il y a aussi reliquary. Je l’exploite moi-même. sanctum, reliquary
Pour une liste plus complète de projets du même type, voir awesome-tunneling.
Je comprends que l’ajout du mot-clé « AI » relève du SEO. C’est un peu comme ajouter « Reddit » dans un titre d’article. Même si le contenu est excellent, ce genre de procédé ne donne pas une bonne impression. Les schémas de passerelle API et de passerelle AI sont presque identiques. blog tailscale : AI-normal
ext_procd’Envoy arrive bientôt, et le support de proxy-wasm pourrait être ajouté selon la demande. Voir aussi cette explication sur HTTP.Je cherche activement une alternative open source à Tailscale. Mais le README est tellement long qu’il vaudrait mieux condenser l’aperçu du projet et les liens vers la documentation.
Le principal atout de Tailscale, c’est la simplicité des connexions P2P. Octelium, en revanche, semble utiliser une architecture à routeur centralisé ; j’aimerais savoir si c’est exact.
Octelium n’est pas un VPN P2P, mais une architecture zero trust. Bien sûr, il peut aussi servir de VPN d’accès distant basé sur WireGuard/QUIC, mais structurellement il est plus proche de Cloudflare Access ou Teleport. Contrôle d’accès basé sur la couche L7, accès sans secrets (injection sans déploiement direct de clés, tokens, clés API, etc.), configuration et routage dynamiques, visibilité et audit en temps réel via OpenTelemetry : c’est fondamentalement différent d’un VPN P2P. Une véritable architecture ZTNA/BeyondCorp (hors service mesh) a des limites intrinsèques si on tente de l’implémenter sous forme de VPN P2P. Pour obtenir du contrôle d’accès par requête et de la visibilité, un proxy conscient de la couche L7 est indispensable.
À noter que même Tailscale fait parfois transiter les paquets par un routeur centralisé. Explication des types de connexion de Tailscale
Je ne comprends pas pourquoi l’installation d’un cluster k3s est intégrée à l’application. Il me semblerait plus clair de pouvoir l’ajouter facilement à une infra existante, ou d’exposer les services via un simple CRD. Le concept d’un Cloudflare Access/Teleport open source est séduisant, mais comme tout finit souvent en personnalisation au-dessus de k8s, j’aurais été plus intéressé si l’accent avait été mis sur les fonctions d’accès elles-mêmes.
octeliumctl applyou l’API gRPC, et l’on peut oublier toute l’administration restante. Les ressources ont auparavant existé sous forme de CRD, mais comme elles sont trop nombreuses — utilisateurs, sessions, services, namespaces (dont certains distincts des namespaces k8s), politiques, appareils, identifiants, etc. — et que le volume de données est important, le backend etcd s’est révélé instable. Un backend Postgres séparé a donc fini par être adopté.Il y a déjà trop de projets semblables déjà sortis.
Je me demande si c’est un remplaçant aux outils de gestion d’accès de niveau grande entreprise (botnet d’entreprise). Si j’étais une grande entreprise, je voudrais plutôt un logiciel de grande entreprise avec un package de support pour la stabilité ; j’ai du mal à voir comment un projet open source porté par un seul développeur pourrait résoudre ce problème.