Afin d’assurer la confidentialité des données relatives à l’activité de l’infrastructure, et ainsi, assurer une protection maximale des services de l’infrastructure Picasoft, il est très important d’utiliser SSL/TLS pour éviter que les messages de log transitent “en clair” sur le réseau.

De très bonnes ressources (en anglais) expliquant le fonctionnement et les différents messages délivrés lors d’échanges sécurisés avec SSL/TLS, sont disponibles ici

En bref, le but de TLS est d’être sûr que l’on échange des données “sensibles” avec le bon destinataire (pour se prémunir d’attaques du type "man in the middle". L’idée, en plus d’être sûr de l’idée de notre interlocuteur est de chiffrer les données à l’aide de clés cryptographiques de sorte à chiffrer les messages envoyés (comme on fermerait un coffre). Ainsi, ces messages ne peuvent être exploités que par notre interlocuteur qui lui possède également la clé. Toute interception de messages par un pair malveillant serait sans aucun risque puisque ce dernier ne possède pas la clé nécessaire au déchiffrement des messages (cela revient, à tenter d’ouvrir un coffre blindé sans avoir la clé). Ainsi, à l’initiation d’un échange TLS, le serveur doit prouver son identité via un certificat. Ce certificat est signé par une autorité de certification attestant d’une part que le certificat est valide, et d’autre part, que le serveur est digne de confiance, donc que l’utilisateur peut croire son identité. Ce certificat est envoyé au client en guise de preuve que le serveur est digne de confiance et peut recevoir des données “sensibles”. Suite à cela, le serveur envoie au client une clé publique (qui peut être partagée sans risque sur le réseau) avec laquelle il pourra chiffrer les données pour les envoyer au serveur. En revanche, ces données chiffrées avec la clé publique ne sont exploitables que si le destinataire détient une clé privée. En effet, le chiffrement s’effectue avec une clé publique (tout le monde peut “parler” au serveur), mais le déchiffrement ne se fait qu’avec la clé privée (gardée secrète par le serveur). De ce fait, seul le serveur authentifié et digne de confiance peut lire les données.

Cette vue globale de TLS est relativement simplifiée, mais devrait suffire pour comprendre la suite de cette page.

Dans le cas de l’infrastructure de monitoring, le serveur qui nécessite de posséder un certificat est Logstash, car c’est ce service qui reçoit les messages de logs et qui doit prouver aux conteneurs Logspout de chaque VM qu’il est digne de confiance. En revanche, Logstash ne gère pas (comme le fait Traefik), la gestion des certificats avec Let’s Encrypt. Ainsi, Logstash ne peut pas, lui-même, s’occuper de ses certificats.

De ce fait, nous avons décidé de générer un certificat sur la machine hôte, à l’aide de certbot. Or, comme le démon Docker de la VM de monitoring contient un conteneur Traefik écoutant sur le port 80, et que certbot a besoin de ce port là pour faire la demande de certificat auprès de Let’s Encrypt, il est nécessaire de stopper le conteneur Traefik pour quelques instants, le temps de la génération du certificat. Le but est ensuite de relancer Logstash de sorte à ce que ce dernier recharge sa configuration et prenne en charge le renouvellement du certificat. Pour l’instant, cette manipulation n’a été testée que manuellement. Toutefois, les certificats délivrés par l’autorité Let’s Encrypt n’étant valables que pour que durée de 3 mois, il serait nécessaire, si une solution était trouvée, d’écrire un script assurant le renouvellement des certificats, en suivant les étapes suivantes:

• Arrêt du conteneur Traefik
• Génération du nouveau certificat avec: certbot certonly –standalone -d monitoring.picasoft.net
• Redémarrage du conteneur Logstash pour prendre en compte le renouvellement du certificat
• Redémarrage du conteneur Traefik

En plus de cette manipulation, il est nécessaire de modifier dans les fichiers docker-compose de chacune des autres VMs, la ligne suivante:

syslog+tcp://monitoring.picasoft.net:1234

au niveau de la partie concernant Logspout, par:

syslog+tls://monitoring.picasoft.net:1234

Ainsi, on configure Logspout pour router les messages de Logs en utilisant, non plus simplement TCP, mais TLS.

En effectuant ces manipulations, l’erreur que nous avons eue, et que nous n’avons pas réussi à résoudre est la suivante:

x509: certificate signed by unknown authority

Elle est renvoyée par Logspout lorsqu’il reçoit le certificat de préalablement généré pour Logstash.

La résolution de ce problème permettrait d’utiliser TLS pour l’envoi des messages de logs et améliorerait grandement la sécurité de l’infrastructure.