cClaude.rocks ☕ Le blog

Pour la configuration des projets informatiques il est parfois nécessaire d’utiliser des clés d’API (ex : ressource web…) ou des informations d’identification (ex : compte mail, base de donnée…).

Mettre ces informations dans un dépôt git pose problème, car toute personne ayant accès au dépôt sera à même de lire ces informations secrètes.

git-crypt est une solution permettant de résoudre ce problème à moindres frais.

Comment gérer vos codes secrets avec git ?

J'essaie toujours de configurer mes projets de manière à pouvoir exécuter une seule commande pour les déployer à partir de zéro en supprimant toute étape manuelle.

Je versionne le code de mes projets dans git, incluant la configuration, et ces dépôts ne sont pas sur github (ou sur un dépôt gérer en dehors de ma plateforme) puisque cela impliquerait de donner mes codes secrets aux administrateurs de ces services.

L’outil git-crypt

git-crypt vise à résoudre ce problème en chiffrant vos codes secrets chaque fois que vous les transférez vers votre référentiel git et en les déchiffrant chaque fois que vous les extrayez. Cela se produit de manière transparente.

Installer git-crypt.

Il y a des instructions pour Linux, Mac et Windows sur la page d’installation de git-crypt.

sudo apt install git-crypt

Sous Linux Mint, c’est la version 0.6.0 qui est actuellement dans les dépôts, alors que le code source est version 0.7.0.

Créer un nouveau référentiel git

mkdir monproject
cd monproject
git init
echo 'La documentation de monproject' > README.md
git add README.md
git commit -m 'Initial commit'

Nous avons maintenant un référentiel git contenant un seul fichier texte avec lequel on va pouvoir jouer.

Configurez le référentiel pour utiliser git-crypt

git-crypt init

Generating key...

git-crypt export-key ../git-crypt-key

cp .git/git-crypt/keys/default ../git-crypt-key

Indiquez à git-crypt quels fichiers chiffrer.

Imaginez que notre application ait besoin d’une clé API et que nous souhaitions la stocker dans un fichier appelé ma-cle-d-api.key.

Avant d’ajouter ce fichier à notre référentiel, nous dirons à git-crypt que nous souhaitons que le fichier ma-cle-d-api.key soit chiffré.

Nous faisons cela en utilisant le fichier .gitattributes. Il s’agit d’un fichier que nous pouvons utiliser pour ajouter des métadonnées supplémentaires à notre référentiel git. Ce n’est pas spécifique à git-crypt, vous avez donc peut-être déjà un fichier .gitattributes dans votre référentiel. Si tel est le cas, ajoutez simplement les lignes pertinentes et ne remplacez pas l’intégralité du fichier.

Dans notre cas, nous n’avons pas de fichier .gitattributes, nous devons donc en créer un. Le fichier .gitattributes contient des lignes de la forme :

[file pattern] attr1=value1 attr2=value2

Pour git-crypt, le modèle de fichier doit correspondre à tous les fichiers que nous voulons que git-crypt chiffre, et les attributs sont toujours les mêmes : filter et diff, que nous définissons tous deux sur git-crypt.

Ainsi, notre fichier .gitattributes devrait contenir ceci :

ma-cle-d-api.key filter=git-crypt diff=git-crypt

Créez le fichier .gitattributes, puis ajoutez-le dans votre référentiel git :

echo 'ma-cle-d-api.key filter=git-crypt diff=git-crypt' .gitattributes
git add .gitattributes
git commit -m 'Tell git-crypt to encrypt ma-cle-d-api.key'

Ici on a utilisé le nom de fichier littéral ma-cle-d-api.key dans mon fichier .gitattributes, mais il peut s’agir de n’importe quel modèle de fichier incluant le(s) fichier(s) que vous souhaitez chiffrer. On aurait également pu utiliser, par exemple, *.key.

Il peut être facile de commettre une erreur dans votre fichier .gitattributes si vous essayez de protéger plusieurs fichiers avec une seule entrée de modèle. Je recommande donc fortement de lire cette section du README git-crypt, qui met en évidence certains des pièges courants.

Ajoutez un fichier contenant des informations secrètes.

Maintenant que nous avons dit à git-crypt que nous souhaitions chiffrer le fichier ma-cle-d-api.key, ajoutons-le à notre référentiel.

echo 'une secète valeur fictive' > ma-cle-d-api.key

Nous n’avons pas encore ajouté ma-cle-d-api.key à git, mais nous pouvons vérifier ce que git-crypt va faire en exécutant :

git-crypt status

Vous devriez voir le résultat suivant :

    encrypted: ma-cle-d-api.key
not encrypted: .gitattributes
not encrypted: file.txt

Ainsi, même si le fichier ma-cle-d-api.key n’a pas encore été ajouté dans notre référentiel git, cela vous indique que git-crypt va le chiffrer pour vous.

Ajoutons et validons le fichier :

git add ma-cle-d-api.key
git commit -m 'Added the API key file'

Vérifier que nos informations sensibles sont chiffrées

Nous avons demandé à git-crypt de chiffrer et nous l’avons ajouté ma-cle-d-api.key à notre référentiel. Cependant, si l’on y regarde, rien ne semble différent :

cat ma-cle-d-api.key

une secète valeur fictive

La raison en est que git-crypt chiffre et déchiffre les fichiers de manière transparente lorsque vous les poussez et les extrayez vers votre référentiel. Ainsi, le fichier ma-cle-d-api.key ressemble à un fichier normal en texte clair.

file ma-cle-d-api.key

ma-cle-d-api.key: ASCII text

Une façon de confirmer que vos fichiers sont réellement chiffrés consiste à transférer votre référentiel vers un serveur git. Lorsque vous affichez le fichier ma-cle-d-api.key à l'aide de l’interface Web du serveur git, vous verrez qu’il s’agit d’un fichier binaire crypté plutôt que de texte.

Un moyen plus simple de voir à quoi ressemblerait le référentiel pour quelqu’un sans la clé de déchiffrement est d’exécuter :

git-crypt lock

Maintenant, si nous regardons notre fichier ma-cle-d-api.key, les choses sont différentes :

file ma-cle-d-api.key && cat ma-cle-d-api.key

ma-cle-d-api.key: data
GITCRYPT����^ie�ҧ�I�]�88�G��ZB��u�2y߳g�

Vous verrez des résultats indésirables différents de ceux que j'obtiens, mais il est clair que le fichier est crypté. C’est ce qui serait stocké sur le serveur git.

Pour retrouver le fichier ma-cle-d-api.key en texte clair, exécutez :

git-crypt unlock ../git-crypt-key

Le fichier ../git-crypt-key étant celui que nous avons enregistré précédemment en utilisant :

git-crypt export-key [FILEOUT]

Résumons

Reprenons ce que nous avons vu :

• On initialise sur un référentiel git pour l’utiliser avec git-crypt à l’aide de :

git-crypt init

• On utilise le fichier .gitattributes pour indiquer à git-crypt quels fichiers chiffrer

• Pour chiffrer, en local, tous les fichiers spécifiés par .gitattributes on utilise :

git-crypt lock

• Pour déchiffrer tous les fichiers on a :

git-crypt unlock [path to keyfile]

Le fichier git-crypt-key est très important. Sans cela, vous ne pourrez décrypter aucun des fichiers cryptés de votre référentiel. Toute personne possédant une copie de ce fichier a accès à tous les secrets cryptés de votre référentiel. Vous devez donc garder ce fichier en sécurité.

Réutiliser votre fichier de clé git-crypt

Nous avons utilisé git-crypt init et git-crypt export-key pour créer notre fichier git-crypt-key. Mais si nous devons avoir un fichier de clés distinct pour chacun de nos référentiels, alors nous n’avons pas beaucoup amélioré notre gestion des données sensibles.

Heureusement, il est très simple d’utiliser le même fichier de clé git-crypt pour plusieurs référentiels git.

Pour utiliser un fichier de clé existant, utilisez-le simplement git-crypt unlock à la place de git-crypt init lorsque vous configurez votre référentiel git pour utiliser git-crypt, comme ceci :

mkdir mon-autre-project   # Au même niveau de répertoire que `monproject`
cd mon-autre-project
git init
echo 'mon-autre-project' > README.md
git add README.md
git commit -m 'initial commit'
git-crypt unlock ../git-crypt-key

Réutiliser votre fichier de clé git-crypt est pratique, mais cela signifie que si quelqu'un d'autre obtient une copie de votre fichier de clé, toutes vos données sensibles sont exposées.

Il s’agit du même genre de compromis en matière de sécurité que l’utilisation d’un gestionnaire de mots de passe. Plutôt que de gérer plusieurs mots de passe, chacun comportant son propre risque d’exposition, vous les conservez tous dans un magasin sécurisé et utilisez un seul mot de passe principal pour les déverrouiller.

L’idée ici est qu’il est plus facile de gérer un mot de passe important que de nombreux mots de passe de moindre importance.

Quand NE PAS utiliser git-crypt

git-crypt est un excellent moyen de conserver les secrets dont vos applications ont besoin directement dans le référentiel git, aux côtés du code source de l'application. Cependant, comme toute autre mesure de sécurité, cela ne sera pas toujours approprié ou conseillé.

Voici quelques éléments à prendre en compte pour décider si c’est la bonne solution pour votre projet particulier :

git-crypt est conçu pour les situations dans lesquelles la majorité des fichiers de votre référentiel git peuvent rester en texte clair et il vous suffit de chiffrer quelques fichiers contenant des informations sensibles. Si vous devez chiffrer la plupart ou la totalité des fichiers de votre référentiel, d’autres solutions peuvent être mieux adaptées.

Il n’existe pas de moyen simple de révoquer l’accès aux secrets d'un référentiel une fois que quelqu’un possède le fichier de clé, ni de moyen simple de faire pivoter (c’est-à-dire de remplacer) un fichier de clé. On rappelle que le but de git est de garder toutes les versions de votre projet et changer la clé aura un impact sur l’historique.

git-crypt chiffre uniquement le contenu des fichiers. Par conséquent, cela ne convient pas si les métadonnées de votre référentiel sont également sensibles (c'est-à-dire les noms de fichiers, les dates de modification, les messages de validation, etc.).

Certaines applications graphiques pour git ne fonctionne pas de manière fiable avec git-crypt, en particulier lorsqu’elles sont anciennes.

Il y a plus d'informations dans la section Limitations du README de git-crypt.

Une meilleure façon d'utiliser git-crypt

Plutôt que de gérer directement votre fichier de clé git-crypt, il existe une meilleure façon de gérer les référentiels chiffrés en intégrant git-crypt avec gpg, afin que vous puissiez utiliser votre clé privée gpg pour décrypter le référentiel git. Cela vous permet également d'ajouter plusieurs collaborateurs à un référentiel git sans transmettre de secrets entre les parties. Cependant, cela nécessite une configuration plus compliquée.

Je ne rentre pas dans le détail, mais au cas où je met un lien vers un post qui en parle: Using Git-crypt to Protect Sensitive Data

Liens

• page d’installation de git-crypt
• How to Manage Your Secrets with git-crypt
• Using Git-crypt to Protect Sensitive Data

ᦿ