Tutoriel sur la sécurisation d'un repository Git central, cas de GitLab et GitHub

Vous travaillez avec Git sur les projets de votre entreprise/organisation et vous vous demandez comment sécuriser les échanges de données qui circulent sur le réseau entre le repository de chaque poste développeur et son référentiel central tel que GitLab ou GitHub, alors ce tutoriel est fait pour vous. Il organise, structure et synthétise les procédures à suivre pour atteindre cet objectif. Ces procédures ici sont basées sur l'OS Windows, mais rassurez-vous, il n'y a pas de changement fondamental avec d'autres environnements.


Réagissez à cet article en faisant vos remarques ici : 1 commentaire Donner une note  l'article (5)

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Dans une entreprise ou une organisation, la gestion technique d'un projet informatique qui y est développé passe par des outils, comme Git, qui permettent non seulement de versionner/historiser et de suivre l'évolution des changements effectués sur ce projet, mais surtout d'assurer la cohérence du travail collaboratif des différents acteurs qui contribuent par l'ajout, la modification et la suppression des fichiers de données. Comme cela sera présenté dans la section suivante, Git propose une architecture décentralisée qui consiste à disposer d'un repository central, en général hébergé sur un système dédié du marché comme GitLab ou Github (mais il n'est pas exclu de créer son propre repository central privé), sur lequel l'on connecte plusieurs repository locaux (correspondants à chaque machine développeur). Le repository central aura pour but de recueillir et de centraliser les différents fichiers de données qui lui seront transmis individuellement par chaque repository local (et donc par chaque machine développeur). De même tout repository local aura la possibilité de récupérer tous les fichiers situés sur le repository central de manière à lui être équivalent à un instant t.

Il y va de soi donc, qu'un tel système a besoin d'un réseau au sens informatique du terme pour fonctionner. Ainsi, lorsque dans la configuration de Git le choix d'utiliser un repository central du marché tel que GitLab ou Github est fait, on se retrouve dans un cas où nous aurons besoin d'un réseau Internet pour y accéder. À ce moment, il y a des risques à contrer que nous expliquerons dans la suite de cet article.

II. Git et le travail collaboratif

Lorsqu'une équipe de développeurs travaillent sur un projet collaboratif géré à l'aide de l'outil de versioning Git, ils doivent s'échanger les données de leur travail à travers des commit and push et des pull. Cela passe par la communication entre leur repository git local respectif avec un repository central généralement hébergé sur un serveur tel que GitLab, GitHub ou encore Bitbucket, etc. Cet échange de données se fait naturellement au travers de connexions réseau Internet. Comme nous pouvons le voir sur la figure ci-dessous, les données qui sont échangées entre un repository local et celui central, peuvent être sujettes à interception par des méthodes de hacking et puis piratées.

Schéma collaboratif Git

Le but de ce tutoriel est de vous montrer comment sécuriser un canal de communication (représentée par la flèche bleue à double tête) ouvert entre un repository Git – situé sur votre machine locale – et son référent central reposant sur un serveur distant situé sur Internet. Nous prendrons pour exemple un repository central situé sur GitLab.com et GitHub.com. Nous présenterons deux protocoles qui sont indépendants l'un de l'autre, mais complémentaires, permettant d'atteindre notre objectif :

  • SSH : Secure Shell ;
  • GPG : Gnu Privacy Guard.

III. Le protocole SSH

III-A. Définition

Secure Shell, en abrégé SSH, est un protocole basé sur les techniques de cryptographie et qui permet d'établir un canal de communication sécurisé entre deux ordinateurs A et B qui s'échangent des données au travers d'un réseau. Plus concrètement, il permet sur l'un des ordinateurs (A par exemple) de générer une paire de clefs privée et publique appelée SSH Key pair. Ensuite, A fournira la clef publique générée à B afin qu'ils puissent mutuellement s'identifier lorsqu'ils s'échangent des données.

Dans notre cas, l'échange de données se passe entre la machine hébergeant notre repository Git local et le serveur GitLab.com ou GitHub.com hébergeant le repository Git de référence. La mise en place du protocole SSH permet que lorsqu'un développeur effectue un commit and push ou un pull depuis son repository local vers le référent, alors une authentification d'arrière-plan est établie entre les deux entités. Par conséquent, il n'est plus nécessaire de saisir son login/password pour s'authentifier, ce qui est un réel avantage par rapport au protocole HTTPS généralement utilisé.

III-B. Outils nécessaires

Pour utiliser les commandes SSH, il faut avoir installé le client openSSH sur votre machine. Mais puisque dans ce tutoriel, nous travaillons sous environnement Windows, il convient de noter que votre outil Git installé via gitforWindows embarque déjà une version de ce client. Si pour une raison ou une autre, vous ne pouvez/voulez pas utiliser la version standalone de openSSH ou même celle intégrée dans votre outil Git, vous avez aussi la possibilité d'installer Putty qui vient lui aussi avec une version du client openSSH.

SSH utilise plusieurs algorithmes de cryptage pour permettre la création de la SSH Key pair :

  • RSA ;
  • DSA ;
  • ECDSA ;
  • ED25519.

D'après GitLab en particulier et la littérature que nous avons consultée, en général, il est conseillé d'utiliser ED25519, le plus robuste de ces algorithmes qui ne sont déjà pas des moindres. C'est celui-là que nous utiliserons pour la génération de la paire de clefs SSH qui nous permettra de sécuriser le canal de communication entre notre repository local et le repository central. Quand, nous avons compris les notions et les principes définis ci-dessus, il ne nous reste plus qu'à passer à la pratique et vous verrez que c'est hyper simple à mettre en œuvre.

III-C. Génération de la SSH Key pair avec l'algo ED25519

Comme nous venons de le dire, la mise en œuvre de SSH est très simple. Nous énumérons donc dans ce qui suit, les étapes à suivre fidèlement pour atteindre notre objectif.

  • Ouvrez votre invite de commande Git Bash ou votre client openSSH ou encore putty, et saisissez la commande suivante :
 
Sélectionnez
ssh-keygen -t ed25519 -C <unCommentaireDeVotreChoix>

En général, il faut saisir un commentaire parlant qui permettra d'identifier votre clef lorsqu'on la saisira dans GitLab/GitHub.

  • Répondez aux différentes questions, suite à l'exécution de la commande précédente, notamment :

- le répertoire dans lequel déposer la paire de clefs SSH générée : laissez celui par défaut qui pointe vers le répertoire C:/Users/votreCompte/.ssh ;
- un mot de passe pour protéger l'accès aux deux fichiers générés contenant pour l'un la clef privée et pour l'autre la clef publique : pas besoin.

Si malgré tout vous souhaitez saisir un mot de passe, sachez qu'il existe la commande ssh-keygen -p -f votreMdp qui permet de le modifier a posteriori.

III-D. Ajout de la public SSH Key sur le repo central

III-D-1. Ajout de clef dans GitLab ou GitHub

  • Étape 1 : copiez la clef publique générée à la section précédente.

Deux possibilités de le faire :
- soit vous utilisez un éditeur de texte tel que Bloc-notes ou notepad++, pour ouvrir et copier le contenu du fichier C:/Users/votreCompte/.ssh/id_ed25519.pub ;
- soit vous utilisez votre Git Bash (ou votre client openSSH ou putty) et exécutez la commande suivante :

 
Sélectionnez
cat ~/.ssh/id_ed25519.pub | clip
  • Étape 2 :

- si vous travaillez avec GitLab : allez sur votre compte GitLab.com et connectez-vous. Une fois connecté, cliquez sur votre avatar en haut à droite, dans le menu qui se déroule, cliquez sur Settings, enfin dans le menu de gauche qui s'affiche, cliquez sur SSH Keys :

Interface GitLab de configuration SSH

- si vous travaillez avec GitHub : allez sur votre compte GitHub.com et connectez-vous. Une fois connecté, cliquez sur votre avatar en haut à droite, dans le menu qui se déroule, cliquez sur Settings, enfin dans le menu de gauche qui s'affiche, cliquez sur SSH and GPG Keys :

Interface GitHub de configuration SSH

Puis cliquez sur le bouton New SSH key :

Interface GitHub de configuration SSH

Dans le grand champ texte de l'un ou de l'autre, collez votre clef publique copiée à l'étape précédente.

  • Étape 3 : validez enfin la configuration de votre clef avec le bouton Add Key pour GitLab ou Add SSH key pour GitHub.

Si vous n'avez pas fait d'erreur de copie de la clef publique (la moindre erreur est fatale, même l'ajout d'un simple espace fausse la clef), vous verrez le fingerprint (l'empreinte) de votre clef s'afficher juste après le bouton Add Key.

Ainsi se terminent la génération et la configuration de la SSH Key Pair entre votre machine locale et le serveur GitLab/GitHub. Mais pour commencer l'utilisation de votre outil Git en mode SSH, il vous reste à tester la configuration qui vient d'être faite et régler les problèmes s'il y en a.

III-D-2. Test de configuration

Pour tester que les étapes de configuration que vous avez réalisées dans les sections précédentes sont bonnes, ouvrez votre Git Bash/openSSH/putty et exécutez la commande suivante :

  • si vous travaillez avec GitLab :
 
Sélectionnez
ssh -T git@gitlab.com
  • si vous travaillez avec GitHub :
 
Sélectionnez
ssh -T git@github.com

À la validation de cette commande, votre client SSH détectera et résoudra le nom de domaine de votre hôte distant gitlab.com (ou github.com) en vous exposant son adresse IP et vous demandera de confirmer cette information afin de l'ajouter dans la whitelist des hôtes reconnus. Cette whitelist est contenue dans le fichier C:/Users/votreCompte/.ssh/known_hosts créé par le client SSH. Ce fichier répertorie l'ensemble des hôtes avec lesquels vous avez partagé votre clef publique SSH.
A contrario, si l'exécution de cette commande provoque une erreur, alors il y a certainement eu erreur dans les étapes précédentes, vous devez la rechercher et corriger.

Bon à savoir :
Pour jouir de votre configuration SSH, trois cas de figure se proposent à vous :

  • tout nouveau projet que vous clonez depuis le repository de référence vers votre repository git local doit utiliser l'url Git :
 
Sélectionnez
git clone git@<votreLogin><pathVersLeProjetGit>.git
  • tout nouveau projet créé en local et que vous voulez uploader sur votre repository de référence, doit être configuré en lui affectant une remote url de type SSH :
 
Sélectionnez
git remote add origin git@<votreLogin><pathVersLeProjetGit>.git
  • Si vous aviez déjà un projet existant giteurisé dont la remote url utilisée est HTTPS, vous devez la modifier en SSH :
 
Sélectionnez
git remote set-url origin git@<votreLogin><pathVersLeProjetGit>.git

Maintenant tout est bon, il ne vous reste plus qu'à effectuer des commits et des push avec votre outil git pour bénéficier des avantages du protocole SSH. Enjoy !!!

Enfin, sachez que les configurations précédentes (II-C et II-D) doivent être répétées pour chaque machine locale (chaque développeur donc) souhaitant se connecter au repository git de référence sur GitLab/GitHub.

IV. Le protocole GPG

IV-A. Définition

Gnu Privacy Guard, en abrégé GPG, est une implémentation de la spécification OpenPGP basée sur les techniques de cryptographie, permettant de signer et de chiffrer une donnée transmise sur Internet depuis un ordinateur connecté. Le terme signer signifie identifier et étiqueter l'auteur de la transmission de la donnée, tandis que chiffrer signifie crypter ladite donnée à l'aide d'un algorithme de cryptage. Cela passe par la génération d'une paire de clefs privée/publique que nous appelons GPG Key Pair.

Dans notre cas, nous allons utiliser GPG pour signer et chiffrer les commits que nous poussons depuis notre reporitory Git local vers son référent sur GitLab ou GitHub. Ainsi, tout commit effectué par un développeur connu sera marqué Verified et le cas contraire Unverified. Nous vous montrerons comment y parvenir dans les sections suivantes.

Mais avant d'y parvenir, il est important de présenter le principe de partage de clef GPG que proposent des référents comme GitLab ou GitHub :

  • le committer doit avoir à disposition une paire de clefs privée/publique GPG ;
  • la clef publique GPG du committer doit avoir été uploadée sur GitLab/GitHub ;
  • une adresse email contenue dans la paire de clefs GPG doit correspondre à l'adresse email d'identification du compte du committer dans GitLab ou GitHub. Cela est nécessaire pour signer les commits ;
  • au moment d'effectuer un commit, l'adresse email utilisée (c.-à-d., le paramètre user.email de la config git) par le committer doit correspondre à celle contenue dans la clef GPG pour être signée comme Verified.

IV-B. Outils nécessaires

Pour générer la GPG Key pair, il faut avoir les outils nécessaires. Tenant compte de notre environnement Windows de travail, nous vous conseillons d'utiliser le logiciel GPG4Win, ou alors d'utiliser votre Git Bash de votre outil gitforWindows. Mais pour être sûr de pouvoir pleinement utiliser votre Git Bash sans être importuné lors de l'utilisation des commandes GPG, assurez-vous d'avoir une version de Git qui embarque une version de GPG supérieure ou égale à 2.0.

IV-C. Génération de la GPG Key pair avec l'algo RSA

La génération de la paire de clefs GPG est simple. Nous la présentons sous forme d'étapes dans la suite.

  • Étape 1 : ouvrez votre Git Bash et saisissez la commande suivante :
 
Sélectionnez
gpg --gen-key

Si vous choisissez d'utiliser Kleopatra, l'outil fourni par Gpg4Win, vous pourrez générer votre clef à l'aide d'une assistance graphique.

  1. Choisissez le type d'algorithme de cryptage souhaité : RSA.
  2. Choisissez la taille de votre clef : 4096.
  3. Date d'expiration de la clef : tapez la touche Entrée de votre clavier pour laisser la valeur par défaut, c'est-à-dire la date ne s'expire pas.
  4. Confirmez toutes les réponses données ci-dessus : y.
  5. Entrez votre nom et l'adresse email à associer à votre clef GPG : cette adresse email doit impérativement correspondre à celle configurée dans votre compte GitLab/GitHub.
  6. Saisissez un mot de passe à associer à votre clef GPG : saisissez un mot de passe que vous pourrez retenir, car vous allez l'utiliser a posteriori.

À l'exécution de la commande précédente, plusieurs questions vous sont posées dans le prompt de votre Git Bash.

  • Étape 2 : exécutez la commande suivante pour afficher la clef privée :
 
Sélectionnez
gpg --list-secret-keys --keyid-format LONG <adresseEmailAssocierALaClefGPG>

Le résultat de cette commande produira un résultat de la forme :

 
Sélectionnez
sec   rsa4096/6ECC3D540027F3A3 2013-03-30 [SC]
      E045937A26CFE04DC79CFE5A6ECC3D549927F3C3
uid                 [ultimate] Georges KEMAYO (My-GPG-Key) <monemail@exemple.com>
ssb   rsa4096/0F0AF99189CF5C12 2013-03-30 [E]

Copiez l'ID dans la clef qui s'affiche. Dans notre cas, cet ID correspond à 6ECC3D540027F3A3. L'ID correspond toujours à la chaine de caractères après le slash sur la première ligne.

  • Étape 3 : exportez/affichez la clef publique GPG à partir de l'ID précédente :
 
Sélectionnez
gpg --armor --export <ID>

Le prompt va donc afficher la clef publique générée. Copiez-la entièrement. Il s'agit de plusieurs lignes de chaines de caractères illisibles balisées par un ----BEGIN PUBLIC PGP KEY BLOCK--------- et un --------END PUBLIC PGP KEY BLOCK---------

IV-D. Ajout de la public GPG Key sur le repo central

IV-D-1. Ajout de clef dans GitLab ou GitHub

L'ajout la clef publique copiée précédemment, dans GitLab/GitHub, se fait comme décrit par les étapes suivantes :

  • Étape 1 :

- si vous travaillez avec GitLab, allez sur votre compte GitLab.com et connectez-vous. Une fois connecté, cliquez sur votre avatar en haut à droite, dans le menu qui se déroule, cliquez sur Settings, enfin dans le menu de gauche qui s'affiche, cliquez sur SSH Keys :

Interface GitLab de configuration GPG

- si vous travaillez avec GitHub : allez sur votre compte GitHub.com et connectez-vous. Une fois connecté, cliquez sur votre avatar en haut à droite, dans le menu qui se déroule, cliquez sur Settings, enfin dans le menu de gauche qui s'affiche, cliquez sur SSH and GPG Keys :

Interface GitHub de configuration GPG

Puis cliquez sur le bouton New GPG key :

Interface GitHub de configuration GPG
  • Étape 2 : validez enfin la configuration de votre clef avec le bouton Add Key pour GitLab ou Add GPG key pour GitHub.

Si vous n'avez pas fait d'erreur de copie de la clef publique (la moindre erreur est fatale, même l'ajout d'un simple espace fausse la clef), vous verrez le fingerprint (l'empreinte) de votre clef s'afficher juste après le bouton Add Key.

Ainsi se terminent la génération et la configuration de la GPG Key Pair entre votre machine locale et le serveur GitLab/GitHub. Mais pour commencer l'exploitation du protocole GPG avec Git, il vous reste quelques configurations à faire sur votre configuration Git.

IV-D-2. Association de la GPG Key à la conf global Git

Pour associer la GPG Key à notre outil Git, nous avons besoin de l'ID de la clef privée copiée précédemment (exemple : 6ECC3D540027F3A3). Ouvrez votre Git Bash et exécutez successivement les commandes suivantes :

 
Sélectionnez
git config --global user.signingkey <ID>
 
Sélectionnez
git config --global gpg.program C:\Program Files\Git\usr\bin\gpg.exe
 
Sélectionnez
git config --global commit.gpgsign true

IV-D-3. Test de configuration

Pour vérifier le bon fonctionnement de votre configuration, effectuez un commit and push vers votre repository central GitLab ou GitHub.

  • Si au moment du commit, la valeur du paramètre git user.email (voir commande git config --list) correspond à celle associée à votre clef GPG et celle de votre compte GitLab/GitHub, vous pourrez observer l'affichage suivant sur l'interface :
Commit vérifié par GPG
  • Si par contre, vous changez votre user.email avant d'effectuer votre commit pour qu'il ne corresponde plus à celui associé à votre clef GPG et celui de votre compte GitLab/GitHub, vous pourrez observer l'affichage suivant sur l'interface :
Commit non vérifié par GPG

IV-D-4. Configuration bonus : mise en cache du mot de passe GPG

Après avoir mis en place la configuration GPG précédente, vous observez qu'à chaque commit (voir commande git commit -m "commentaire"), la popup suivante s'ouvre, vous demandant à chaque fois de saisir votre mot de passe GPG.

Popup passphrase GPG

Si vous avez l'habitude de committer dans des laps de temps courts, il est possible de mettre en cache votre mot de passe GPG pour qu'il ne vous soit plus intempestivement demandé et ne le soit que lorsque celui en cache est arrivé en timeout. Nous vous montrons ici comment réaliser cela.

Pour mettre en cache le passphrase (c'est-à-dire, le mot de passe GPG) que vous avez choisi lors de la génération de votre clef GPG, suivez les étapes suivantes :

  • Étape 1 : éditez avec Bloc-notes ou notepad++, le fichier C:\Users\votreCompte\.gnupg\gpg.conf et décommentez (enlevez le #) sur la ligne où il est écrit use-agent.
  • Étape 2 : créez le fichier C:\Users\votreCompte\.gnupg\gpg-agent.conf et ajoutez-y la ligne suivante :
 
Sélectionnez
pinentry-program "C:\Program Files\Git\usr\bin\pinentry.exe"
  • Étape 3 : ouvrez votre Git Bash et exécutez la commande suivante :
 
Sélectionnez
echo RELOADAGENT | gpg-connect-agent

À ce stade, nous avons ainsi fait le tour. Enjoy !!!

V. Conclusion

Au terme de ce tutoriel, nous nous rendons compte que travailler dans un environnement sécurisé n'échappe pas au travail collaboratif avec Git, étant donné que les commandes commit and push et pull de ce dernier consistent à faire transiter des données sur un réseau. Nous avons abordé deux protocoles de communication SSH et GPG qui s'appuyant sur des techniques de cryptographie offrent la possibilité d'assurer la sécurité recherchée. Pour mettre en pratique ces protocoles, nous avons utilisé deux hébergeurs de repository Git que sont GitLab et GitHub qui donnent la possibilité de configurer ces derniers.

Il existe une autre politique de sécurité supportée par GitLab et GitHub que nous n'avons pas abordée ici : la Deploy Keys. Nous vous laissons le soin de vous documenter à son sujet pour aller plus loin. Nous espérons surtout que ce tutoriel vous a été utile.

VI. Remerciements

Je voudrais dire un merci infini aux messieurs suivants qui ont contribué au perfectionnement de cet article :
- Mickael Baron pour sa relecture technique et pour ses remarques ;
- ClaudeLeLoup pour sa relecture orthographique.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2020 Georges KEMAYO. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.