Ça y est : j’ai publié mon premier projet open source. Il s’appelle Keymaker, c’est une interface web locale pour gérer ses clés API OVHcloud (les inventorier, les auditer, les révoquer, en créer de nouvelles), et je vais vous raconter pourquoi je l’ai écrit et comment il fonctionne.
Petit avertissement d’entrée de jeu : c’est un projet non officiel, sans aucun lien avec OVHcloud. Juste un outil que j’avais besoin d’utiliser pour moi-même, et que j’ai fini par nettoyer et publier.
Le déclic : des clés API partout, et plus aucune vue d’ensemble#
Si vous suivez la série Mon homelab de zéro, vous savez que j’utilise l’API OVHcloud à plusieurs endroits : notamment pour le challenge ACME DNS-01 qui génère mes certificats Let’s Encrypt via la zone ktw.ovh. Chaque intégration demande une clé, avec ses propres droits.
Et c’est là que le problème s’installe, sournoisement. Au fil des tests, des scripts jetables et des intégrations qui restent, les clés s’accumulent. On finit avec une poignée de tokens dont on ne sait plus trop :
- à quoi ils servent encore,
- quels droits on leur a accordés (parfois beaucoup trop larges),
- s’ils expirent un jour,
- et depuis combien de temps ils n’ont pas servi.
Autrement dit : une surface d’attaque qui grossit dans le dos, exactement le genre de chose que j’aime traquer. Sauf que l’interface OVHcloud, déjà pas trop pratique pour créer une clé, n’est pas géniale non plus pour faire le ménage et auditer l’existant d’un coup d’œil. J’ai cherché un outil qui fasse ça proprement, je n’ai pas trouvé mon bonheur, alors je l’ai fait.
Ce que fait Keymaker#
L’idée tient en une phrase : une console locale pour voir et maîtriser toutes ses clés API OVHcloud au même endroit. Concrètement :
- Inventaire : la liste de toutes vos clés, avec leurs règles d’accès, leur date de création, leur expiration et leur dernière utilisation.
- Audit : Keymaker signale les clés à risque, celles qui ont un accès à l’ensemble du compte, celles qui n’expirent jamais, celles qui dorment depuis plus de six mois… bref, les candidates idéales au ménage.
- Explorateur de routes : un navigateur cherchable des endpoints de l’API OVHcloud, pour construire des règles d’accès au plus juste plutôt que d’utiliser des wildcards.
- Création et remplacement : créer une nouvelle clé, ou faire tourner une clé existante quand ses droits doivent changer.
- Révocation : supprimer une clé proprement, avec confirmation pour éviter le clic malheureux.
Le tout dans une petite interface web, thème clair/sombre, en français comme en anglais.
Les partis pris (surtout côté sécurité)#
Un outil qui manipule des clés API, c’est par définition sensible. J’ai donc pris quelques décisions assumées dès le départ.
Zéro persistance. Keymaker n’a pas de base de données, pas de cache sur disque. Il lit votre configuration en lecture seule, interroge l’API OVHcloud à la volée, et n’écrit rien. Quand vous fermez le conteneur, il ne reste aucune trace. C’est la même philosophie que celle qui me plaît dans Bruno pour les API : vos données restent chez vous, et rien ne traîne.
En localhost, point. Par défaut, le service n’écoute que sur 127.0.0.1. Ce n’est pas fait pour être exposé sur le réseau, encore moins sur Internet. C’est un outil d’atelier, qui tourne le temps d’une session sur votre machine.
Docker uniquement. Pas d’installation à base de dépendances qui polluent le système : une image, une commande, et c’est parti. Plus simple à distribuer, plus simple à jeter.
Défense en profondeur. Au-delà du localhost : un token d’accès aléatoire généré à chaque session, une protection CSRF via un second token et aucun secret dans les logs. Et un détail que j’aime bien : si vous ne donnez pas le droit DELETE à la clé de gestion, Keymaker bascule automatiquement en lecture seule. Le principe de moindre privilège s’applique à l’outil lui-même.
La clé de gestion, ce paradoxe assumé. Pour gérer vos clés, Keymaker a lui-même besoin d’une clé API (avec les droits ad hoc). C’est le même genre d’amorçage que la clé age ou le token GitLab dont je parlais dans le homelab : il y a toujours un premier secret qu’on pose à la main. La bonne pratique, c’est de lui donner le strict nécessaire (et de la révoquer avec Keymaker le jour venu, forcément).
L’essayer en une commande#
Le principe : vous créez une clé de gestion avec les bons droits, vous la rangez dans un fichier ovh.conf (le format standard des SDK OVHcloud), et vous lancez le conteneur.
docker run --rm -p 127.0.0.1:8080:8080 \
-v ./ovh.conf:/config/ovh.conf:ro \
ghcr.io/kentrow/keymaker:0.1.0Le :ro sur le volume dit bien ce qu’il veut dire : Keymaker lit la config, il n’y touche pas. Ensuite, direction http://127.0.0.1:8080 avec le token affiché au démarrage. Les détails (droits exacts de la clé de gestion, format du fichier) sont dans le README du dépôt.
Ce que ça m’a appris#
Publier un projet, ce n’est pas juste pousser du code sur GitHub. C’est aussi écrire une doc lisible, choisir une licence (Apache 2.0 ici), soigner les messages d’erreur, penser à celui qui va cloner sans rien connaître du contexte… exactement le même réflexe de reproductibilité que dans le homelab, mais tourné vers les autres cette fois.
C’est un premier jet (version 0.1.0), écrit en Go, avec sûrement des angles à polir. Mais il fait déjà ce pour quoi je l’ai créé : me donner, en trente secondes, une vue claire de ce que mes clés OVHcloud peuvent faire, et de celles qu’il faut supprimer.
Liens utiles#
- Le dépôt Keymaker sur GitHub
- Les issues : les retours, idées et bugs sont les bienvenus
Mon mot de la fin#
Si vous avez un compte OVHcloud et que vous n’avez jamais vraiment fait le tri dans vos clés API, lancez Keymaker une fois. Vous tomberez sans doute, comme moi, sur deux ou trois tokens oubliés aux droits bien trop larges. Et si le projet vous plaît, une étoile sur le dépôt fait toujours plaisir.
À bientôt !
