Sur git, ne stockez jamais de secrets
Je vois une mauvaise utilisation dans le monde git.
Même si certains projets encouragent ce comportement. Soyez clair sur ce point : stocker des secrets sur git est toujours une mauvaise idée.
Rupture de flux git à distance
Si vous stockez un secret sur git, vous êtes censé le stocker chiffré (évidemment).
Pour faire un versionnage, vous utilisez simplement un commit. Comme l’algorithme de chiffrement n’est pas déterministe (comme il se doit, ce n’est pas un hachage), vous vous retrouvez avec un blob de données chiffrées qui est entièrement différent du commit précédent. Il est impossible de faire une comparaison et le fichier complet est téléchargé à chaque fois.
Maintenant, plus drôle. Vous voulez faire une git merge car 2 branches ont reçu des mises à jour séparées sur leurs secrets. Comme vous devez comparer 2 fichiers chiffrés entièrement différents, quels avantages peuvent offrir toute stratégie merge de git. Vous finirez certainement par bousiller votre fichier et perdre les secrets qu’il contient.
Rupture de flux git local
Vous pourriez dire “de cette façon, je gère mes secrets avec le même flux que mon code”. Et je répondrai “Vraiment? En êtes-vous vraiment sûr?”
Jetons donc un œil à votre flux local, car je vous ai déjà expliqué que votre flux distant est définitivement mort.
- Vous tirez le repo
- Vous l’intégrez dans votre VSCode ou votre terminal ou tout autre IDE
- Vous changez quelque chose sur le code
- Vous commit
- Vous tirez et poussez
Ok, maintenant pour les secrets.
- Vous tirez le repo
- Vous l’intégrez dans votre VSCode ou votre terminal ou tout autre IDE
- Jusqu’ici tout va bien
- J’espère que vous avez installé l’outil pour déchiffrer votre fichier de secrets
- Vous le déchiffrez (en espérant que l’outil soit intégré dans votre IDE)
- Vous changez quelque chose dessus
- Vous le chiffrez avec le même outil ou un autre
- Vous vérifiez deux fois que vous n’avez pas laissé le fichier non chiffré quelque part sur votre espace de travail
- Vous commit avec une goutte sur le front et une douleur au ventre
- Vous tirez
- Vous essayez de comprendre comment résoudre le conflit entre vos 2 blobs de fichier chiffré car un nouveau commit à distance a déjà modifié le fichier
- Vous commit à nouveau en espérant que vous n’avez pas tout foiré
- Vous poussez
- Vous voyez par la suite que vous avez commit également le fichier non chiffré et que les secrets sont maintenant disponibles librement sur le remote
- Vous essayez désespérément de réinitialiser bousillant le flux git pour toute l’équipe
- Vous pleurez
Je ne suis pas sûr que ce soit le même flux git.
En conclusion, stockez vos secrets dans des stockages faits pour cela. Par exemple, Hashicorp Vault sur votre infrastructure et keepassXC localement.