Lorsqu'une VM est mise en place, et que le service qu'elle doit héberger est installé, il est grand temps de rendre ce service accessible à l'extérieur du réseau d'ATILLA.

• Idée générale
• Enregistrement du sous-domaine
• Mise en place des certificats SSL
• Mise en place de la configuration Nginx
  • Méthode manuelle
  • Méthode plus ou moins automatique

Idée générale

Avant de suivre les étapes de mise en place, c’est intéressant de comprendre ce qu’on va faire ^.

Dans l'infra d'ATILLA, les connexions à un service web (members.atilla.org, learn.atilla.org, …) passent en grande majorité par Bill, qui acte comme d'un frontal web : c’est lui qui réceptionne les connexions HTTP(s) et qui les renvoie aux bons services internes par la suite. On dit également que Bill joue le rôle de reverse-proxy.

En plus de cela, Bill gère la terminaison des connexions HTTPs : c’est à dire que lorsqu’une connexion HTTPs arrive sur Bill, elle est déchiffrée, puis renvoyée en HTTP à la machine virtuelle qui correspond. Cela permet de ne pas complexifier l’installation des services, et d’avoir un endroit central ou gérer les certificats SSL.

En pratique, Bill dispose d'un serveur Nginx, qui va avoir réceptionner toute requête HTTP(s) sur un des sites d'ATILLA et qui transfère cette requête à la VM qui héberge le service correspondant.

Enregistrement du sous-domaine

La première chose à faire est de déclarer au monde que le domaine sur lequel vous souhaitez déployer votre service existe. Il n’y a pas de convention à proprement parler sur le choix du sous-domaine. Si vous déployez un service de gestion de tickets (par exemple, GLPI), le domaine auquel ce service pourra être accessible peut très bien être glpi.atilla.org ou même tickets.atilla.org.

Pour déclarer ce domaine, rendez-vous sur la machine qui sert de DNS dans l’infra (aujourd’hui, il s’agit de Bill). Deux fichiers devront être édités :

• /etc/bind/internal/db.atilla.org : les entrées DNS qui sont exposées à tous les utilisateurs au sein du réseau d’ATILLA et de l’EISTI
• /etc/bind/external/db.atilla.org : les entrées DNS qui sont exposées à tous les utilisateurs venant de l’extérieur

Dans ces deux fichiers, rajoutez une ligne comme celle-ci (note : les sous-domaines sont triés par ordre alphabétique) :

… puis redémarrez le serveur DNS :

Cela aura pour effet de déclarer le sous-domaine monservice.atilla.org.

Si vous devez déclarer un service sur *.eistiens.net, il faudra éditer les fichiers db.eistiens.net dans les dossiers internal et external de la configuration du DNS.

Mise en place des certificats SSL

Maintenant qu’on a notre domaine, on va pouvoir récupérer des certificats SSL nous permettant de mettre en place le HTTPs sur ce domaine.

L’idée, c’est de récupérer des informations (en l’ocurrence, un certificat et sa clé) nous permettant d’attester que le frontal web est bien le serveur qui correspond au domaine monservice.atilla.org. Lorsqu’un utilisateur se connectera en HTTPs à ce domaine, la première action qui sera effectuée par le navigateur sera de vérifier que le serveur auquel il se connecte est bien le bon, et qu’il peut lui faire confiance.

Il existe plusieurs fournisseurs de certificats SSL dans le monde. ATILLA utilise Let’s Encrypt, qui nous permet, une fois le certificat mis en place une première fois, de ne pas avoir à se soucier de son renouvellement (le renouvellement de tous les certificats est ensuite effectué de manière automatique).

Let’s Encrypt vient avec un outil, appelé certbot, qui permet d’enregistrer de nouveaux certificats SSL. On va utiliser cet outil pour demander le nouveau certificat.

Pour la demande du nouveau certificat, utilisez la commande suivante. Lorsque certbot demande quelle méthode de vérification utiliser pour générer le certificat, choisissez Spin-up a temporary webserver.

Si certbot termine avec un message du type Congratulations! Your certificate and chain … bla bla bla, ça veut dire que c’est bon, le certificat a bien été enregistré. Il doit maintenant être stocké dans /etc/letsencrypt/live/monservice.atilla.org/.

Si vous n’avez pas ce genre de message, avant de démarrer tout diagnostique, assurez-vous de bien redémarrer le serveur Nginx, pour éviter toute interruption de service trop longue :

Mise en place de la configuration Nginx

Finalement, on va devoir mettre en place la configuration qui va tout lier ensemble, c’est elle qui va indiquer que, lorsqu’un utilisateur se connecte au service, on utilisera le certificat SSL qui a été généré plus haut, et on enverra les connexions à la machine voulue.

Méthode manuelle

Méthode plus ou moins automatique

On a un super projet sur GitLab qui permet d’effectuer les actions de la méthode manuelle de manière automatique. Ce projet est présent sur /root/nginx-config-generator sur Bill, voici comment l’utiliser rapidement. En cas de besoin, référez vous au README.md du projet.