Keyorix : un gestionnaire de secrets open source sur site

Keyorix est un nouveau gestionnaire de secrets open source conçu pour fonctionner entièrement sur l'infrastructure de l'entreprise. Il s'adresse aux organisations qui n'ont pas le droit, ou pas l'envie, de confier leurs identifiants à un fournisseur cloud.

Pour les lecteurs moins familiers de ce type d'outil, un gestionnaire de secrets est un coffre protégé dans lequel les applications récupèrent les valeurs sensibles dont elles ont besoin pour fonctionner : mots de passe de bases de données, clés d'API ou jetons d'accès. L'objectif est de sortir ces valeurs des fichiers de configuration et du code source, où elles ont tendance à fuiter. Comme l'a montré une affaire récente, les dépôts GitHub exposent encore un grand nombre d'identifiants valides.

Keyorix est distribué sous la forme d'un binaire unique. Dans sa version de base, il n'a besoin d'aucune connexion Internet.

À qui il s'adresse

La société à l'origine du projet, Keyorix SL, cible les équipes qui ne peuvent pas envoyer leurs secrets vers un service SaaS. Deux publics sont cités explicitement : les exploitants de réseaux isolés, coupés d'Internet par conception, et les entreprises européennes qui doivent se mettre en conformité avec NIS2 et DORA.

NIS2 est la directive européenne qui fixe les exigences de cybersécurité pour les organisations des secteurs critiques et importants. DORA, le règlement sur la résilience opérationnelle numérique, encadre la résilience opérationnelle et informatique du secteur financier.

Keyorix SL publie son propre tableau comparatif, qui place l'outil entre deux solutions établies. D'un côté, Vault, qui peut tourner sur site mais exige un administrateur dédié. De l'autre, Doppler, présenté comme simple d'utilisation mais disponible uniquement en SaaS. Keyorix se positionne comme une option auto-hébergée, sans la lourdeur d'exploitation de Vault.

Fournir les secrets aux applications

Les développeurs disposent de deux moyens principaux pour transmettre les secrets à leurs logiciels. Le premier est un outil en ligne de commande qui les injecte sous forme de variables d'environnement. L'application les lit alors comme n'importe quel autre paramètre, sans avoir besoin de savoir d'où ils viennent.

Le second est un ensemble de SDK pour Go, Python et Node.js, destiné aux équipes qui veulent interroger le coffre directement depuis leur code.

Les organisations qui utilisent déjà Vault peuvent importer leurs secrets existants dans Keyorix. Une seule commande Docker Compose suffit à lancer l'ensemble de la pile, interface web comprise.

Contrôle d'accès et gestion au quotidien

Autour du coffre lui-même, Keyorix ajoute une couche de droits d'accès et de traçabilité. La liste des fonctionnalités comprend :

le contrôle d'accès basé sur les rôles et les droits par groupe
la gestion des versions des secrets
des environnements distincts de développement, de préproduction et de production
des jetons de service pour les tâches CI/CD
des alertes dans le tableau de bord pour les secrets qui approchent de leur échéance de rotation

Les équipes qui préfèrent éviter la ligne de commande peuvent tout gérer depuis un tableau de bord web.

Comment les données sont protégées

Chaque secret est chiffré en AES-256-GCM. Au démarrage, l'opérateur saisit une phrase secrète, à partir de laquelle est dérivée une clé de chiffrement de clés. Cette clé est conservée uniquement en mémoire et sert à protéger la clé de données qui chiffre réellement les secrets.

Pour le stockage, Keyorix utilise SQLite en développement et pour les petites équipes, et PostgreSQL pour les déploiements en production.

Chaque accès à un secret est consigné avec le détail de l'auteur de la requête, du secret concerné, du moment de l'accès et de la provenance de la requête. Ces enregistrements sont conservés dans deux couches d'audit distinctes.

Keyorix est disponible gratuitement sur GitHub.

Notre analyse

Keyorix arrive à un moment où la gestion des secrets est sous une pression inhabituelle. Des identifiants continuent d'apparaître dans du code public, et les chaînes CI/CD comme les outils automatisés ont de plus en plus besoin de leurs propres jetons. Notre article sur les agents d'IA qui conservent l'accès aux données une fois leurs tâches terminées pointe le même problème de fond : les identités machines s'accumulent, et quelqu'un doit suivre et renouveler ce qu'elles détiennent. Des fonctionnalités comme les alertes de rotation, les jetons de service et les journaux d'audit détaillés répondent directement à cet enjeu.

L'angle réglementaire semble lui aussi délibéré. Pour les entreprises européennes aux prises avec NIS2 et DORA, pouvoir montrer où se trouvent les identifiants, qui y a accédé et quand peut s'avérer utile, et tout garder sur site retire un prestataire tiers de l'équation. Cela dit, l'argumentaire vient de l'éditeur, et la comparaison avec Vault et Doppler est celle de l'entreprise elle-même. Les équipes ont intérêt à vérifier ces affirmations plutôt qu'à les prendre pour argent comptant.

L'auto-hébergement renvoie aussi la responsabilité au client. La conception garde la clé de chiffrement de clés uniquement en mémoire, ce qui limite l'exposition sur disque mais fait aussi de la phrase secrète un secret opérationnel critique à part entière. Le risque lié à la chaîne d'approvisionnement compte également, comme le montrent des incidents tels que la compromission de l'Artifactory d'OpenInfra Europe pour les infrastructures autogérées.

Reste à voir si Keyorix fera l'objet d'audits de sécurité indépendants, avec quelle rapidité le projet réagira aux problèmes signalés, et si les utilisateurs de Vault adopteront réellement la fonction d'import. Ces facteurs détermineront sans doute s'il devient une option sérieuse pour les environnements réglementés et isolés ou s'il reste une alternative de niche.