Garder ses clés API secrètes, même versionnées sur GitHub
Vos clés API vivent en clair dans des fichiers .env, des configs, parfois un script oublié. Vous savez qu'un seul commit malheureux suffit, et qu'une clé publiée sur GitHub ne redevient jamais secrète. Alors vous ne versionnez rien, vous trimballez vos secrets à la main, et vous croisez les doigts à chaque commit.
Cette masterclass vous donne la chaîne complète age + sops : vos clés chiffrées en AES-256 dans un fichier que vous pouvez versionner sans risque, Git ne voit que du texte illisible, vous seul déchiffrez, et deux garde-fous (un .gitignore et un hook pre-commit) bloquent toute fuite avant qu'elle parte.
Ce que cet exercice ne peut pas casser
L'exercice se fait sur une feuille : vous ne touchez ni à votre dépôt, ni à vos fichiers, ni à votre historique. La seule action qui engage, révoquer une clé compromise, est précisément celle qu'il faut faire : une clé fuitée se remplace, elle ne se répare pas.
Ce que vous saurez faire à la fin
- Trier votre inventaire de secrets en deux piles : les clés à protéger, et les clés compromises à révoquer d'abord.
- Chiffrer vos clés API avec age et sops, et les déchiffrer à la volée pour les utiliser.
- Poser les deux garde-fous qui empêchent un secret en clair de partir dans un commit.
- Niveau membre· le prompt prêt à coller qui construit votre chaîne de chiffrement complète, commande par commande, adaptée à votre système et à vos outils.
- Niveau Pro· je monte la chaîne avec vous et je vérifie qu'aucun secret en clair ne subsiste, ni dans votre dépôt, ni dans votre historique.
Sept maillons : on trie d'abord, on chiffre ensuite, et deux garde-fous veillent pour la suite.
Pourquoi on trie avant de chiffrer
La tentation, c'est de foncer sur le chiffrement. Mauvais ordre. Aucun chiffrement ne rattrape une clé déjà fuitée : si elle est entrée un jour dans l'historique Git, elle est compromise, point. La méthode commence donc par un tri, déroule ensuite la chaîne age + sops, et se termine par deux garde-fous, parce que l'erreur humaine, elle, reviendra.
1Trier : les saines d'un côté, les compromises de l'autredoute : « et si une clé a déjà fuité ? »
Deux piles. Les clés jamais commitées : à protéger. Les clés déjà entrées dans l'historique Git : compromises, à révoquer et régénérer AVANT toute autre étape. Supprimer le fichier ne suffit pas, l'historique garde tout. Une clé déjà publiée ne redevient jamais secrète, elle se remplace.
2age : votre paire de clés, générée une foisdoute : « encore un outil à installer ? »
Vous installez age et vous générez votre paire de clés. C'est la serrure de tout le système : cette paire servira à chiffrer et déchiffrer chacun de vos fichiers de secrets. Une installation, une commande de génération, et c'est posé pour de bon.
3sops et son fichier .sops.yamldoute : « à quoi sert ce fichier de plus ? »
Vous installez sops, puis vous écrivez votre .sops.yaml : la configuration qui relie vos fichiers de secrets à votre clé age. C'est elle qui dit quoi chiffrer, pour qui. Sans elle, sops ne sait pas quel fichier protéger ni avec quelle clé.
4Chiffrer, puis déchiffrer à la voléedoute : « et pour utiliser mes clés ensuite ? »
Vous chiffrez votre fichier de secrets en AES-256 : il devient versionnable sans risque, Git ne voit que du texte illisible. Et quand un projet a besoin d'une clé, vous déchiffrez à la volée : la version en clair ne vit qu'au moment où vous l'utilisez, jamais dans le dépôt.
5Deux garde-fous contre le commit de tropdoute : « et le jour où je vais trop vite ? »
Le .gitignore bloque tous les fichiers de secrets en clair tout en autorisant les versions chiffrées. Le hook pre-commit scanne chaque commit et bloque les motifs de clés connues de vos outils. Le jour où vous irez trop vite, c'est lui qui dira non à votre place.
6La checklist qui confirme que tout est propredoute : « comment en être sûr ? »
Dernière étape : vérifier, point par point, que plus aucun secret en clair n'existe ni dans votre dépôt, ni dans votre historique. Tant que cette checklist n'est pas verte, la chaîne n'est pas finie.
À vous de jouer : votre inventaire de secrets
Une feuille, trois colonnes : la clé, son emplacement, son statut Git. C'est exactement la matière que le prompt attend.
Le résultat, en 30 secondes
À partir de votre inventaire, le prompt déroule tout, adapté à votre système et à vos outils : les clés à révoquer d'abord, les huit étapes avec leurs commandes exactes, votre .gitignore, votre hook pre-commit et la checklist finale.
Clé à révoquer d'abord : votre clé de paiement, présente dans un commit de mars, à régénérer depuis le tableau de bord du service avant toute autre étape. Mise en place, étape 1 sur 8 : installer age avec votre gestionnaire de paquets, vous devez voir un numéro de version s'afficher. Étape 2 : générer votre paire de clés. En bas : le bloc .gitignore à coller, le script du hook avec la liste des motifs surveillés, et la checklist de fin.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur sécurité senior, spécialiste de la gestion des secrets pour des solos et des petites équipes techniques. Ton exigence : zéro secret en clair, jamais, et une méthode qu'un non-spécialiste peut suivre sans se tromper. Tu ne t'appuies QUE sur ce que je te donne. Ce que tu ne sais pas (ma stack, mes outils, l'état de mon historique Git), tu me le demandes, tu ne l'inventes jamais. Si tu n'es pas certain qu'une manipulation est sûre, tu le signales au lieu de l'affirmer. # CONTEXTE Je veux chiffrer mes clés API avec age et sops (AES-256) pour pouvoir les versionner sans risque, déchiffrer à la volée pour les utiliser, et poser deux garde-fous (un `.gitignore` et un hook pre-commit) qui m'empêchent de commiter un secret en clair. Mon système d'exploitation : [macOS / Linux / autre]
Le prompt construit votre chaîne complète, adaptée à votre système et à vos outils : le tri de vos clés, les commandes exactes pas à pas, votre .gitignore, votre hook pre-commit et la checklist finale. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous découvrez qu'une clé API traîne en clair dans un commit vieux de six mois. Quelle est la première chose à faire ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un confrère qui versionne ses .env en clair : pourquoi chiffrer ne sauvera pas une clé déjà commitée, et que faire à la place ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Trier n'importe quel inventaire de secrets en deux piles : à protéger, à remplacer.
- Expliquer le rôle de chaque maillon de la chaîne : age, sops, .sops.yaml, .gitignore, hook pre-commit.
- Réagir correctement à une clé fuitée : révoquer d'abord, chiffrer ensuite.
Une clé déjà publiée ne redevient jamais secrète, elle se remplace.
Faites-le avec moi
Je monte la chaîne avec vous, du tri de vos clés au hook pre-commit, et je vérifie qu'aucun secret en clair ne subsiste. Vous arrêtez de croiser les doigts à chaque commit.