TOC

Comment sécuriser GitLab avec Let’s Encrypt sur Ubuntu 16.04

introduction

GitLab, en particulier GitLab CE (Community Edition), est une application open source principalement utilisée pour héberger des référentiels Git, avec des fonctionnalités supplémentaires liées au développement, telles que le suivi des problèmes. Le projet GitLab rend relativement simple la configuration d’une instance GitLab sur votre propre matériel avec un mécanisme d’installation simple.

Par défaut, GitLab sert les pages sur HTTP pur et non chiffré. Comme toute application Web qui traite des informations sensibles telles que les identifiants de connexion, GitLab doit être configuré pour servir des pages sur TLS / SSL pour chiffrer les données en transit. C’est extrêmement important avec GitLab car le code de votre projet pourrait être modifié par une personne capable d’intercepter vos informations de connexion.

Le projet Let’s Encrypt peut être utilisé pour obtenir facilement des certificats SSL de confiance pour n’importe quel site Web ou application Web. Let’s Encrypt propose des certificats signés par leur autorité de certification, approuvée par tous les navigateurs Web modernes, si vous pouvez prouver que vous êtes le propriétaire du domaine pour lequel vous demandez un certificat.

Dans ce guide, nous montrerons comment configurer une instance GitLab installée sur Ubuntu 16.04 pour qu’elle utilise un certificat SSL de confiance obtenu auprès de Let’s Encrypt. Cela sécurisera toutes les communications sortantes avec les utilisateurs et garantira que les mots de passe, le code et toute autre communication sont protégés contre la lecture ou la falsification par des tiers.

Conditions préalables

Pour compléter ce guide, vous devez avoir une instance de GitLab installée sur un serveur Ubuntu 16.04. Nous supposerons que vous avez suivi notre how pour installer et configurer GitLab sur Ubuntu. 16.04 guide pour obtenir cette configuration.

Pour obtenir un certificat de Let’s Encrypt, votre serveur doit être configuré avec un nom de domaine complet (FQDN). Si vous ne possédez pas déjà un nom de domaine enregistré, vous pouvez en enregistrer un auprès d’un des nombreux bureaux d’enregistrement de noms de domaine (par exemple, Namecheap, GoDaddy, etc.).

Si ce n’est déjà fait, veillez à créer un * enregistrement A * qui pointe votre domaine vers l’adresse IP publique de votre serveur. Cela est nécessaire en raison de la façon dont Let’s Encrypt a confirmé que vous êtes propriétaire du domaine pour lequel il émet un certificat. Par exemple, si vous souhaitez obtenir un certificat pour + gitlab.example.com +, ce domaine doit être résolu sur votre serveur pour que le processus de validation fonctionne. Vous aurez besoin d’un domaine réel avec des enregistrements DNS valides pointant sur votre serveur pour pouvoir mener à bien ce guide.

Installez Certbot, le client Let’s Encrypt

Avant que nous puissions obtenir un certificat SSL pour notre installation GitLab, nous devrons télécharger et installer Certbot, le client officiel Let’s Encrypt.

Les développeurs de Certbot gèrent leur propre référentiel de logiciels Ubuntu avec des versions à jour du logiciel. Étant donné le développement actif de Certbot, il est intéressant d’utiliser ce référentiel pour installer un Certbot plus récent que celui fourni par Ubuntu.

Tout d’abord, ajoutez le référentiel:

sudo add-apt-repository ppa:certbot/certbot

Vous devrez appuyer sur + ENTER pour accepter. Ensuite, mettez à jour la liste des packages pour récupérer les informations de package du nouveau référentiel:

sudo apt-get update

Et enfin, installez Certbot avec + apt-get:

sudo apt-get install certbot

Maintenant que Certbot est installé, nous pouvons préparer notre serveur afin qu’il puisse répondre correctement aux tests de vérification de la propriété du domaine requis par Let’s Encrypt avant d’émettre un certificat.

Préparer la vérification du domaine racine de Web Encrypt

Pour recevoir un certificat SSL de l’autorité de certification Let’Secrypt, nous devons prouver que nous possédons le domaine pour lequel le certificat sera fourni. Il existe plusieurs méthodes pour prouver la propriété du domaine, chacune nécessitant un accès root ou administrateur au serveur.

GitLab contient un serveur Web Nginx géré en interne pour servir l’application elle-même. Cela rend l’installation plutôt autonome, mais cela ajoute une couche supplémentaire de complexité lorsque vous tentez de modifier le serveur Web lui-même.

Comme Nginx intégré est actuellement utilisé pour servir GitLab lui-même, la meilleure méthode de validation de domaine est la méthode racine Web. Certbot utilisera le serveur Web existant pour servir un fichier connu du serveur sur le port 80. Cela prouve à l’autorité de certification que la personne qui demande le certificat a le contrôle administratif sur le serveur Web, ce qui prouve de manière effective la propriété du serveur et du domaine.

Pour configurer la validation du domaine racine Web pour GitLab, notre première étape sera de créer une racine fictive de document:

sudo mkdir -p /var/www/letsencrypt

Cela sera inutilisé par les opérations Nginx normales, mais sera utilisé par Certbot pour la vérification de domaine.

Ensuite, nous devons ajuster la configuration de GitLab Nginx pour utiliser ce répertoire. Ouvrez le fichier de configuration principal de GitLab en tapant:

sudo nano /etc/gitlab/gitlab.rb

À l’intérieur, nous devons ajouter une ligne qui injectera une directive personnalisée dans le fichier de configuration de GitLab Nginx. Il est probablement préférable de faire défiler la liste jusqu’à la section * GitLab Nginx * du fichier, mais la ligne peut être placée n’importe où.

Collez dans la ligne suivante:

/etc/gitlab/gitlab.rb

. . .
nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/letsencrypt; }"
. . .

La méthode de vérification de la racine Web Let’s Encrypt place un fichier dans un répertoire + .well + + + 'de la racine du document afin que l’autorité de certification puisse le valider. Cette ligne indique à Nginx de répondre aux demandes de `+ /. Notables + à partir de la racine Web que nous avons créée il y a un instant.

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Ensuite, appliquez les modifications à la configuration Nginx de GitLab en reconfigurant à nouveau l’application:

sudo gitlab-ctl reconfigure

Le serveur doit maintenant être configuré pour valider votre domaine.

Demander un certificat avec Certbot

Maintenant que l’instance Nginx de GitLab est configurée avec le bloc d’emplacement nécessaire, nous pouvons utiliser Certbot pour valider notre nom de domaine et demander un certificat.

Comme nous souhaitons uniquement un certificat et ne souhaitons pas configurer automatiquement le serveur Web, nous utiliserons la sous-commande + certonly. Nous allons spécifier trois options. Nous devons choisir l’authentificateur de la racine Web (+ - webroot +), transmettre la racine du document (+ - webroot-path = / var / www / letsencrypt +) et utiliser la commande + -d + pour passer notre nom de domaine:

sudo certbot certonly --webroot --webroot-path=/var/www/letsencrypt -d

Vous serez invité à fournir une adresse e-mail. Il est important d’inclure une adresse e-mail valide car c’est le seul moyen de recevoir de manière fiable des e-mails sur les expirations de certificats et d’autres informations importantes. Vous serez également invité à accepter les conditions d’utilisation de Let’s Encrypt.

Une fois que vous avez terminé, Let’Secrypt devrait vous délivrer un certificat pour le domaine s’il était capable de valider correctement la propriété. Vous devriez voir une sortie qui ressemble à ceci:

OutputIMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
  /etc/letsencrypt/live/gitlab.example.com/fullchain.pem. Your cert
  will expire on 2017-07-26. To obtain a new or tweaked version of
  this certificate in the future, simply run certbot again. To
  non-interactively renew *all* of your certificates, run "certbot
  renew"
- If you lose your account credentials, you can recover through
  e-mails sent to [email protected].
- Your account credentials have been saved in your Certbot
  configuration directory at /etc/letsencrypt. You should make a
  secure backup of this folder now. This configuration directory will
  also contain certificates and private keys obtained by Certbot so
  making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

  Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
  Donating to EFF:                    https://eff.org/donate-le

Vous pouvez trouver tous les certificats et les clés créés en consultant le répertoire + / etc / letsencrypt / live / + avec les privilèges + sudo +:

sudo ls /etc/letsencrypt/live/
Outputcert.pem  chain.pem  fullchain.pem  privkey.pem

Pour notre configuration, nous aurons seulement besoin de connaître le chemin complet des fichiers + fullchain.pem + et + privkey.pem +.

Configurer GitLab pour utiliser les certificats Let’s Encrypt

Maintenant que nous avons obtenu des certificats de confiance auprès de Let’s Encrypt, nous pouvons configurer GitLab pour utiliser TLS / SSL pour l’ensemble de son trafic.

Editer la configuration de GitLab

Commencez par ouvrir à nouveau le fichier de configuration GitLab:

sudo nano /etc/gitlab/gitlab.rb

Au sommet, changez le + external_url. Actuellement, il pointe probablement vers + http: // +. Nous avons juste besoin de changer le + http en` + https`:

/etc/gitlab/gitlab.rb

. . .
external_url 'http://'
. . .

Ensuite, faites défiler vers le bas jusqu’à la section * GitLab Nginx *. Décommentez et modifiez ou ajoutez simplement les lignes suivantes.

La ligne de redirection indique à Nginx de rediriger automatiquement les requêtes effectuées sur le port HTTP 80 vers le port HTTPS 443. La ligne + ssl_certificate + devrait pointer vers le chemin complet du fichier + fullchain.pem +, tandis que la ligne + ssl_certificate_key + devrait pointer vers le chemin complet du fichier + privkey.pem +:

/etc/gitlab/gitlab.rb

. . .
nginx['redirect_http_to_https'] =
. . .
nginx['ssl_certificate'] = "/etc/letsencrypt/live//fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live//privkey.pem"
. . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Autoriser le trafic HTTPS à travers le pare-feu

Ensuite, avant de recharger la configuration de GitLab Nginx, assurez-vous que le trafic HTTPS est autorisé via le pare-feu de votre serveur. Vous pouvez ouvrir le port 443 à cette fin en tapant:

sudo ufw allow https
OutputRule added
Rule added (v6)

Vérifiez que le port 443 est ouvert en tapant:

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
80                         ALLOW       Anywhere

OpenSSH (v6)               ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)

Comme vous pouvez le constater, le port 443 est maintenant exposé.

Reconfigurer GitLab pour activer SSL

Maintenant, reconfigurez GitLab pour implémenter vos modifications:

sudo gitlab-ctl reconfigure

Votre instance GitLab devrait maintenant être accessible via HTTPS à l’aide de votre certificat de confiance Let’s Encrypt. Vous pouvez le tester en visitant le nom de domaine de votre serveur GitLab. Puisque nous redirigeons HTTP vers HTTPS, cela devrait fonctionner sans spécifier explicitement un protocole:

http://

Votre navigateur devrait automatiquement vous rediriger pour utiliser HTTPS. Vous devriez voir une indication que le site est sécurisé dans la barre d’adresse:

image: https: //assets.digitalocean.com/articles/gitlab_lets_encrypt_1604/https_connection_verification.png [Vérification SSL GitLab]

Votre installation GitLab est maintenant protégée par un certificat TLS / SSL.

Vérification du renouvellement automatique de Certbot

Les certificats de Let Encrypt ne sont valables que quatre-vingt-dix jours. Cela encourage les utilisateurs à automatiser leur processus de renouvellement des certificats. Le paquetage «+ certbot » que nous avons installé s’occupe de cela en exécutant «certbot renew» deux fois par jour via une minuterie systemd. Sur les distributions non-systemd, cette fonctionnalité est fournie par un script placé dans ` / etc / cron.d +`. Cette tâche est exécutée deux fois par jour et renouvelle tout certificat dans les trente jours suivant son expiration.

Pour tester le processus de renouvellement, vous pouvez effectuer un essai à blanc avec + certbot +:

sudo certbot renew --dry-run

Si vous ne voyez aucune erreur, vous êtes tous ensemble. Si nécessaire, Certbot renouvellera vos certificats et rechargera Nginx pour prendre en compte les modifications. En cas d’échec du processus de renouvellement automatique, Let’s Encrypt enverra un message au courrier électronique que vous avez spécifié pour vous avertir de l’expiration de votre certificat.

Conclusion

Votre instance GitLab devrait maintenant être protégée par un certificat sécurisé TLS / SSL approuvé par tous les navigateurs modernes. La configuration de l’instance intégrée de Nginx est un peu plus complexe que celle d’un serveur Web Nginx autonome, car GitLab expose la fonctionnalité permettant de personnaliser les blocs d’emplacement dans son fichier de configuration. Il est donc facile de contourner ce problème.

Maintenant que votre instance GitLab est sécurisée, vous pouvez l’utiliser en toute sécurité pour gérer des projets, des référentiels de code hôte et configurer une intégration continue. Vous pouvez en apprendre davantage sur l’utilisation de GitLab pour tester automatiquement chaque commit sur votre référentiel dans notre article sur https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-pipelines-with-gitlab- ci-on-ubuntu-16-04 [configuration de pipelines d’intégration continue avec GitLab CI].

Related