OpenBao s’impose comme une alternative open source pour la gestion des secrets, certificats et clés, offrant aux organisations la possibilité de garder cette composante de sécurité en interne, au sein de leur infrastructure. Né comme un fork de HashiCorp Vault, le projet est aujourd’hui en développement sous l’égide de l’OpenSSF, au sein de la Linux Foundation, avec une architecture centrée sur des politiques d’accès, des identifiants dynamiques, le chiffrement et l’audit.

Les enjeux d’OpenBao en 30 secondes

• OpenBao a été créé à partir d’un fork de HashiCorp Vault, avec une compatibilité vis-à-vis de son modèle de gestion des secrets.
• Il peut stocker des secrets chiffrés et générer des identifiants temporaires pour des services compatibles.
• Intègre des politiques d’accès, la rotation et la révocation des identifiants, ainsi que des fonctions d’audit.
• Propose également des services de chiffrement via Transit et des fonctionnalités pour la gestion de PKI.
• Sa principale différence avec Secrets Manager ou Key Vault réside dans son modèle : l’organisation déploie et administre OpenBao elle-même.

La gestion des secrets commence souvent par une étape simple, comme une connexion à une base de données ou une clé API. Le problème apparaît lorsque ces données se multiplient à travers diverses applications, serveurs, conteneurs ou services cloud. Les stocker dans des fichiers de configuration ou des variables d’environnement peut suffire à petite échelle, mais complique la traçabilité, l’accès, ou la révocation des identifiants lorsque ceux-ci ne sont plus nécessaires.

OpenBao propose une couche centrale pour orchestrer cette gestion. Le système peut stocker des secrets arbitraires, les chiffrer avant de les enregistrer en stockage persistant, et appliquer des politiques pour contrôler qui peut y accéder.

OpenBao, Vault et les services des cloud providers (AWS, Azure)

La comparaison avec HashiCorp Vault est incontournable, étant donné qu’OpenBao en est un fork. Toutefois, sa proposition actuelle se distingue par un point important : OpenBao est développé dans le cadre d’une gouvernance communautaire, sous l’égide de l’OpenSSF et de la Linux Foundation.

Contrairement aux services managés de grands fournisseurs cloud – comme AWS Secrets Manager ou Azure Key Vault, qui sont intégrés à leurs plateformes respectives – OpenBao s’adresse à une équipe technique prête à déployer et à gérer elle-même l’infrastructure.

Ce tableau permet de situer rapidement les alternatives. Cependant, il faut garder à l’esprit que toutes ces fonctionnalités ne sont pas forcément équivalentes dans chaque produit. Par exemple, dans AWS et Azure, plusieurs capacités dépendent fortement de leur intégration avec d’autres services.

Pour une équipe, la différence concrète est claire : avec OpenBao, il faut aussi assurer l’exploitation d’OpenBao. Cela implique de gérer le déploiement, la disponibilité, le stockage, les mises à jour, l’application des politiques, et la reprise après incident.

Identifiants temporaires plutôt que secrets permanents

Une des fonctionnalités phares d’OpenBao est la génération d’identifiants dynamiques.

Plutôt que de fournir à une application un mot de passe valable des mois, le système peut générer des identifiants à la demande, associés à une période de validité appelée bail.

Une fois ce bail expiré, ces identifiants peuvent être révoqués automatiquement ou renouvelés tant qu’ils restent nécessaires.

Ce mécanisme est particulièrement utile dans les architectures composées de services éphémères ou à la charge fluctuante. Une application n’a pas besoin d’utiliser une crédentielle statique partagée sur toute sa durée de vie.

OpenBao permet aussi de révoquer individuellement ces identifiants ou de gérer des groupes de secrets. Cela facilite la réactivité face à un incident de sécurité ou un besoin de retirer un accès.

Transit, pour séparer le chiffrement des applications

OpenBao intègre également Transit, un moteur cryptographique permettant de réaliser diverses opérations de chiffrement et déchiffrement sans que l’application ait à gérer directement les clés.

Le principe est simple : l’application envoie les données à chiffrer à OpenBao et reçoit en retour le résultat. Les clés restent sous contrôle du système de gestion des secrets.

Ce mécanisme évite que chaque équipe doive installer une infrastructure spécifique pour la gestion des clés cryptographiques, tout en permettant de centraliser certaines politiques d’utilisation des clés.

Les capacités d’OpenBao s’étendent aussi à l’infrastructure de clé publique (PKI). Le projet comprend des fonctionnalités liées aux certificats, et les versions récentes proposent aussi des mécanismes d’intégration avec des clés externes via des plugins de gestion de clés.

Par exemple, dans OpenBao 2.7, le support pour des clés externes via des plugins KMS a été ajouté pour les services PKI et Transit. L’objectif est de permettre des opérations cryptographiques avec des clés gérées hors de l’environnement d’OpenBao, y compris via des modules compatibles PKCS#11.

Le prix du contrôle, c’est l’opération

L’un des grands avantages d’une solution autogérée réside dans sa maîtrise opérationnelle.

Contrairement à AWS Secrets Manager ou Azure Key Vault, où une partie de l’infrastructure est confiée au fournisseur, avec OpenBao, c’est l’équipe qui contrôle l’emplacement de deployment, l’intégration avec la plateforme, et la maintenance.

Cela inclut la conception du stockage, la configuration de haute disponibilité, la sécurisation des accès administratifs, la gestion des sauvegardes, la mise à jour des versions, et la mise en place de procédures de récupération.

Pour une organisation utilisant déjà Kubernetes, des serveurs internes ou une infrastructure hybride, ce modèle offre une stratégie de contrôle renforcée sur ses données et ses outils de sécurité. À l’inverse, pour une équipe cherchant simplement un service de gestion des secrets, un service managé pourrait mieux correspondre à ses besoins opérationnels.

OpenBao est écrit en Go. Le dépôt inclut le code serveur, l’interface web et la documentation pour le déployer et le faire évoluer. Il permet aussi de compiler le binaire bao directement depuis la source.

L’ambition du projet dépasse la simple gestion de mots de passe : il couvre un ensemble étendu de fonctionnalités, telles que l’entreposage de secrets, la génération d’identifiants temporaires, l’application de politiques, la révocation d’accès, la gestion de certificats et la réalisation d’opérations cryptographiques, tout cela dans une infrastructure sous contrôle interne.

Foire aux questions

En quoi OpenBao diffère-t-il d’AWS Secrets Manager ?

OpenBao s’installe et s’administre dans l’infrastructure interne de l’organisation. En revanche, AWS Secrets Manager est un service managé d’AWS, intégré à son écosystème cloud.

OpenBao, c’est la même chose que HashiCorp Vault ?

Non. Bien qu’OpenBao ait été créé comme un fork de HashiCorp Vault, il évolue désormais en tant que projet indépendant, avec une gouvernance communautaire sous l’égide de l’OpenSSF et de la Linux Foundation.

OpenBao peut-il générer des identifiants temporaires ?

Oui. Il peut produire des secrets dynamiques pour des systèmes spécifiques, en leur associant une période de validité. Ces identifiants peuvent être renouvelés ou révoqués.

À quoi sert Transit dans OpenBao ?

Transit permet d’effectuer des opérations de chiffrement et de déchiffrement sans que l’application ait à manipuler directement les clés cryptographiques. Il centralise une partie de la gestion cryptographique dans OpenBao.