Pour ceux qui ne connaissent pas déjà Gitlab, il s’agit d’une forge informatique. Une application qui permet de centraliser tous les outils pour faciliter le développement d’autres applications : gestion du code source (avec git), de la documentation (avec un wiki), des bogues, de l’intégration/déploiement continu, et tout un tas d’autres fonctionnalités annexes bien pratiques.

L’intérêt de Gitlab, enfin, surtout pour cet article, c’est qu’il peut s’installer à la maison :

• Le bon côté : vos données resteront sous votre autorité sans ingérence étrangère,
• Le moins bon côté : vous devrez vous assurez vous même de la sécurité du système.

Vous pouvez aussi y voir d’autres intérêts comme le fait de n’utiliser que votre réseau interne et ne pas dépendre d’une connexion externe capricieuse, mais aussi l’utilisation de votre propre annuaire d’utilisateurs (i.e. LDAP).

Aujourd’hui, nous allons donc configurer la connexion HTTPS avec de vrais certificats plutôt que des auto-signés qui ne sécurisent rien du tout.

Car pour vos utilisateurs, il sera impossible de distinguer votre certificat auto-signé de celui fourni par un attaquant.

Activer HTTPS

Je pars du principe que votre instance est installée sur votre serveur et fonctionne. L’étape suivante est d’adapter la configuration de votre application à vos besoins spécifiques. Presque tout va se passer dans le fichier de configuration /etc/gitlab/gitlab.rb.

Pour activer HTTPS, rien de plus facile, dans le fichier de configuration, vous allez chercher les directives concernant le nom de domaine pour joindre les services et les modifier pour mentionner HTTPS (on vous laisse adapter avec vos propres noms de domaine) :

external_url            "https://gitlab.example.com"
registry_external_url   "https://registry.example.com"
mattermost_external_url "https://mattermost.example.com"

En vrai, elles ne sont pas les unes à côté des autres et vous pouvez ne pas avoir besoin des trois :

• external_url concerne l’application Gitlab de base, vous devez donc l’utiliser,
• registry_external_url concerne le registre docker permettant de stocker et distribuer les images dockers (utiles pour l’intégration et le déploiement continu), facultatif mais bien pratique,
• mattermost_external_url concerne l’application de discussion en temps réelle, personnellement, je préfère IRC.

Ensuite, et si ça n’est pas déjà configuré, je vous conseille d’activer la redirection automatique de HTTP vers HTTPS, ça évitera à des distraits de se tromper :

nginx['redirect_http_to_https'] = true

Les certificats

Maintenant que le système sait qu’il faut utiliser HTTPS, on va s’attaquer aux certificats. Pour ça, Gitlab propose deux alternatives, chacune ayant ses propres avantages sur l’autre :

• Utiliser ses propres certificats : vous permet de contrôler finement votre PKI et la confiance à l’intérieur de votre SI, sans dépendre d’entités externes,
• Utiliser des certificats Let’s Encrypt™ : vous fournit des certificats valides sur tous les systèmes (cette PKI est pré-installée partout), mais nécessite que votre application soit joignable depuis l’extérieur…

Depuis la version 10.2 Les certificats Let’s Encrypt™ sont configuré par défaut et si votre domaine est joignable par Internet, vos certificats seront automatiquement générés, signés validés par leur PKI. Si votre serveur n’est pas joignable, il est plus pertinent d’installer quand même des certificats signés, par votre propre PKI.

Si vous avez une version inférieure, vous devriez sérieusement penser à mettre à jours. Depuis novembre 2017, plein de choses ont été améliorée et surtout, plein de vulnérabilités ont été corrigées.

Utiliser sa propre PKI

De manière générale, je trouve la documentation officielle assez bien faite (si ce n’est qu’elle est en anglais). Je part du principe que vous savez déjà générés vos clés et certificats.

Désactiver les certificats Lets Encrypt™ Si vous avez une version 10.2 (ou supérieure), il est conseillé de le désactiver pour qu’il n’écrase pas vos fichiers. Ça n’arrivera que si votre serveur est joignable de l’extérieur, donc s’il ne l’est pas, c’est pas essentiel, mais on est jamais à l’abri d’un changement de politique…

letsencrypt['enable'] = false

Déployer les clés et les certificats Pour trouver ces fichiers, Gitlab impose de les placer dans /etc/gitlab/ssl/ et de les nommer d’après le nom de domaine de l’application correspondante (avec une extension .key pour les clés et .crt pour les certificats). Si on reprend l’exemple précédent, on a les noms suivants :

• Gitlab (https://gitlab.example.com) : la clé dans gitlab.example.com.key et le certificat dans gitlab.example.com.crt,
• Registre Docker (https://docker.example.com) : la clé dans docker.example.com.key et le certificat dans docker.example.com.crt,
• Mattermost (https://mattermost.example.com) : la clé dans mattermost.example.com.key et le certificat dans mattermost.example.com.crt.

Si vous ne configurez que gitlab et disposez des fichiers dans le répertoire courant, voici les commandes à lancer :

sudo cp gitlab.example.com.key gitlab.example.com.crt /etc/gitlab/ssl/

Techniquement, il est possible de spécifier le fichier exact qui servira de clé et de certificat pour Gitlab via les deux clés de configuration suivantes :

nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.example.com.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.example.com.key"

Dans ce cas, il faudra que votre certificat soit valide pour l’ensemble des sites hébergés (et pas un seul à la fois). Pour ça, il faudra configurer le champ Subject ALternative Name et les mentionner tous.

Configurer les certificats Let’s Encrypt™

Comme précédement, la documentation officielle est bien faite (et toujours en anglais).

Pour que cette méthode fonctionne, il faut que les services concernés soient joignables depuis Internet via leur nom de domaine respectif. Sinon, les robots Let’s Encrypt™ ne pourront pas valider vos certificats et donc les signer.

[.caption}

Les versions 10.2 et supérieures utilisent les certificats Let’s Encrypt™ par défaut et il n’est donc pas nécessaire de le configurer. Pour les plus anciens, voici les deux lignes à adapter dans /etc/gitlab/gitlab.rb :

letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['foo@email.com']

L’adresse mail est facultative mais peut être utile pour que les robots Let’s Encrypt™ vous prévienne lorsqu’un certificat va expirer.

La mise à jours automatique est déjà configurée par défaut pour se lancer à minuit du 4^ème jour du mois (la minute étant dérivée à partir du nom de domaine pour répartir la charge). Si vous voulez spécifier votre propre rythme, voici les clés à configurer et une valeur d’exemple :

# Tous les 7ème jours à 12h30
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"

Et si, pour une raison obscure, vous souhaitez désactiver le renouvellement automatique des certificats, voici la clé à configurer :

letsencrypt['auto_renew'] = false

Et si vous voulez lancer un renouvellement manuellement, voici la commande à lancer :

sudo gitlab-ctl renew-le-certs

Relancer le service

Maintenant que vos clés et vos certificats sont configurés, que ce soit votre propre PKI ou via les certificats Let’s Encrypt™, vous pouvez maintenant relancer les services (pour qu’ils rechargent leur configuration) avec la commande habituelle :

Oui, c’est un peu pénible de rajouter ™ chaque fois mais c’est leur choix…

sudo gitlab-ctl reconfigure

Et après ?

C’est quoi une PKI ?

19 septemre 2019 À force d’en parler, c’est presque devenu un buzzword vide de sens. Démystifions donc ce concept pour voir ce qu’il apporte et comment s’en servir à propos.

Créer une PKI avec XCA

26 Septembre 2019 Parce que la création des certificat est plutôt complexe, je préfère utiliser des outils graphiques plus intuitifs. Aujourd’hui, je vous montre comment créer une autorité de certification (CA) et un certificat pour serveur web.

Déployer un site web via sftp et Gitlab

10 juin 2019 Avec notre nouvel hébergement, nous avons du revoir nos scripts de déploiement continu. Remplacer rsync par lftp n’est pas compliqué mais nécessite de fournir les données d’authentifications à l’environnement de déploiement. Heureusement, Gitlab fournit une méthode sécurisée pour protéger ces informations sensibles.