Ce billet de blog traite de la façon dont un GitLab peut être construit derrière un OpenVPN. Souvent il y a beaucoup de travail et donc beaucoup d’énergie, de temps et d’argent dans les données qui sont dans un dépôt git. Si vous ne voulez pas seulement compter sur le login de GitLab mais que vous voulez avoir une protection supplémentaire contre lui, vous pouvez le faire avec OpenVPN, par exemple. L’idée est que l’accès au GitLab n’est possible que dans le VPN.
Pour simplifier l’administration des utilisateurs, le serveur OpenVPN est connecté à la base de données des utilisateurs GitLab.

Impact

Comme point négatif, les utilisateurs doivent d’abord avoir un compte avec un mot de passe avant de pouvoir se connecter au GitLab. Si les utilisateurs sont gérés par un administrateur, ce dernier ne crée que les comptes, mais pas les mots de passe, puisque GitLab envoie un lien de réinitialisation de mot de passe. Ceci empêche l’utilisateur de se connecter au système pour définir son mot de passe. Cela signifie que dans un premier temps, soit le mot de passe doit être défini par l’administrateur (en utilisant sa propre adresse e-mail et en la modifiant ultérieurement), soit l’utilisateur peut initialiser son mot de passe via une connexion VPN déjà existante (par exemple en utilisant les identifiants d’un compte déjà existant).

Réalisation

Ici, nous travaillons avec une Debian 8, mais toutes les autres distributions Linux actuelles devraient se comporter de manière très similaire.
D’abord un GitLab est installé, ceci est déjà documenté sur leSite Web de GitLab (voirInstallation GitLab-CE).
Installez ensuite un serveur OpenVPN en utilisant apt-get install openvpn.

Créer des certificats

Nous créons des clés et des certificats pour une AC et pour le serveur VPN. Ceci se fait de préférence directement dans le répertoire dans lequel se trouve la configuration OpenVPN (par défaut /etc/openvpn).
Tout d’abord, nous générons la clé privée et le certificat de l’AC.

openssl req -x509 -sha256 -nodes -nodes -newkey rsa:4096 -keyout ca.keyout -jours 3650 -out ca.pem

Ensuite, nous créons une clé privée et une demande de signature de certificat pour le serveur et nous la signons avec l’AC.

$ openssl req -new -sha256 -nodes -newkey rsa:4096 -keyout server.key -out server.csr  
$ openssl x509 -req -sha256 -CA ca.pem -CAkey ca.key -days 730 -CAcreateserial -CAserial ca.srl -in server.csr -out server.pem  

Vous devez vous assurer que les deux clés privées (.key-Files) ne peuvent être lues que par l’utilisateur requis (dans cet exemple git).

Configuration du serveur OpenVPN

Le serveur OpenVPN est créé avec la configuration suivante :

port 1194
proto udp
dev tun
ca ca.pem
cert server.pem
key server.key
dh dh4096.pem
serveur 10.8.8.0.0 255.255.255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
cryptogramme AES-256-CBC
comp-lzo
git utilisateur
git de groupe
clé persistante
obstiné
status /var/log/openvpn/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn/openvpn-debug.log
verbe 3
auth-user-pass-verify /etc/openvpn/auth-user.rb via-env
script-security 3
client - concert - non requis

Dans la configuration décrite ci-dessus, le serveur OpenVPN n’attendra aucun certificat du client, puisque les utilisateurs doivent seulement se connecter avec un mot de passe.
Le client OpenVPN vérifie le serveur à l’aide de son certificat, qui doit être connu de chaque client.
La vérification de la combinaison nom d’utilisateur/mot de passe est résolue à l’aide d’un script externe. Ce script doit retourner 0 si la combinaison nom d’utilisateur/mot de passe est valide et 1 sinon. En raison du Runner gitlab-rails, le script doit être spécifié avec un chemin absolu dans la configuration OpenVPN, sinon le Runner ne trouvera pas le script.
Le script ressemble à ceci :
“Ruby

#!/usr/bin/gitlab-rails runner

begin
    if ((User.find_by_username! ENV['username']).valid_password? ENV['password'])
        exit 0
    end
rescue
    exit 1
end

exit 1

ADN

Deux entrées DNS doivent être présentes pour que cette configuration fonctionne. La première entrée est nécessaire pour que le client VPN se connecte au serveur et la seconde est utilisée pour se connecter au GitLab.
L’entrée DNS du serveur VPN a stocké l’adresse IP publique du serveur. L’entrée DNS pour GitLab indique l’adresse IP dans le tunnel VPN, dans l’exemple ci-dessus c’est la première adresse IP du pool IP 10.8.0.1.

vpn.example.com.    IN    A    <Server Public IP>
git.example.com.    IN    A    10.8.0.1

Configuration utilisateur OpenVPN (basée sur CLI)

L’utilisateur peut se connecter au serveur VPN avec la configuration suivante. En plus de la configuration, il doit également avoir le certificat CA ca.pem pour pouvoir vérifier le serveur.
10.8.0.0.1.

dev tun
remote vpn.example.com 1194
nobind
ca ca.pem
tls-client
persist-key
persist-tun
comp-lzo
cipher AES-256-CBC
pull
auth-user-pass
verb 3

Configuration utilisateur OpenVPN (NetworkManager)

Une nouvelle configuration OpenVPN est créée dans le gestionnaire de réseau.
La configuration “Identité” doit se présenter comme suit (la passerelle, le nom d’utilisateur et le mot de passe doivent être adaptés et le certificat de l’AC doit être chargé comme certificat de l’AC) :

Cliquez ensuite sur le bouton “Avancé…” pour ouvrir la fenêtre des options avancées.
Là, l’onglet “Général” est réglé comme suit (important est Use LZO data compression) :

et l’onglet “Sécurité” comme suit (“Personnaliser le chiffrement”) :

Ensuite, la fenêtre Options avancées se referme avec “OK”.

La configuration IPv4 doit se présenter comme suit (“DNS” est désactivé ici, il est particulièrement important qu’IPv4 soit activé avec “DHCP” et que les routes soient configurées automatiquement) :

Et enfin, éteignez la configuration IPv6 :

Après l’enregistrement, une connexion au serveur OpenVPN peut être établie et ensuite surfer dans le canal VPN du serveur GitLab.