DEV Community

Michée lengronne for Limawi

Posted on • Originally published at blog.limawi.io on

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.

Sur git, ne stockez jamais de secrets

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.


Top comments (0)