Comment sécuriser Consul avec le chiffrement TLS sur Ubuntu 14.04

Consul est un outil de découverte de services qui permet de découvrir et de suivre facilement l’état de santé de divers services au sein de votre infrastructure. Vous pouvez utiliser consul pour gérer vos services et maintenir un système de contrôle distribué afin de pouvoir répondre lorsque des applications ou des serveurs tombent en panne.

Dans le https://www.digitalocean.com/community/tutorials/how-to-configure-consul-in-a-production-environment-on-ubuntu-14-04 (dernier guide), nous nous sommes concentrés sur l’obtention d’une production. - environnement prêt et prêt. Cela incluait la création de fichiers de configuration qui seraient lus au démarrage et aux scripts d’initialisation pour lancer les services.

Cela nous a pris la majeure partie du chemin jusqu’à notre configuration de base finale, mais nous n’avons pas encore complètement sécurisé notre configuration. Nous avons implémenté une solution de secret partagé simple, qui chiffre très facilement notre protocole de commérage.

Cependant, la communication RPC n’est toujours pas cryptée à ce stade. Pour résoudre ce problème, consul supporte nativement le cryptage TLS, sur lequel nous allons nous concentrer dans ce guide. Pour implémenter cela, nous devrons créer une autorité de certification et signer et distribuer des clés à nos nœuds.

Avant de terminer ce guide, vous devez disposer d’un système de serveurs consul, comme nous les avons laissés dans notre dernier guide, à l’adresse https://www.digitalocean.com/community/tutorials/how-to-configure-consul-in-a -production-environment-on-ubuntu-14-04 [mise en place d’une infrastructure de consul prête pour la production].

Les serveurs que nous avions pour ce guide avaient les propriétés suivantes:

Ce sont des serveurs Ubuntu 14.04 64 bits. Veuillez noter que chacun de ces serveurs réside dans le même domaine. Cela sera important pour la configuration que nous implémentons dans ce guide, car nous allons exploiter un certificat générique qui correspondra à tous les hôtes du domaine.

Dans ce guide, nous allons nous concentrer sur la création d’une autorité de certification TLS afin de signer des certificats pour chacun de nos serveurs. Cela permettra aux composants du consul de vérifier les identités et de chiffrer le trafic. Nous modifierons ensuite légèrement les fichiers de configuration pour forcer nos nœuds à chiffrer le trafic.

Pour commencer, nous allons configurer quelques fichiers et répertoires de base que nous utiliserons pour gérer nos clés.

Encore une fois, nous allons suivre toutes les procédures décrites dans ce guide à partir d’un shell root. Connectez-vous en tant que root ou utilisez + sudo -i + en tant qu’utilisateur disposant des privilèges sudo.

Sur chacun de vos membres consul, créez un répertoire + ssl + dans le répertoire + / etc / consul.d +. C’est là que nous conserverons les fichiers nécessaires au chiffrement du trafic RPC:

Sur le serveur que vous prévoyez d’utiliser comme autorité de certification, nous créerons un sous-répertoire dans ce répertoire pour héberger tous les fichiers nécessaires à la création et à la signature des certificats. Nous pouvons sélectionner n’importe lequel de nos serveurs pour héberger l’autorité de certification, mais pour nos besoins, nous utiliserons le + server1 + qui héberge également la configuration d’amorçage.

Sur ce serveur, créez un sous-répertoire nommé + CA + dans le répertoire que nous venons de créer:

Cela contiendra des données sensibles auxquelles nous ne voudrons probablement pas que d’autres personnes aient accès. Lançons donc le verrouillage des autorisations:

Déplacez-vous dans ce répertoire sur le serveur de l’autorité de certification.

Ici, nous allons créer quelques fichiers de base qui doivent être présents pour notre signature de certificat. Premièrement, nous devons créer un fichier qui sera incrémenté avec le prochain numéro de série disponible pour les certificats. Nous devons pré-ensemencer cela avec une valeur.

Pour ce faire, rappelez la valeur + 000a + au fichier série:

Nous devons également fournir un fichier dans lequel notre autorité de certification peut enregistrer les certificats qu’elle signe. Nous appellerons ce fichier + certindex +:

Pour commencer avec notre autorité de certification, la première étape consiste à créer un certificat racine auto-signé. Nous pouvons le faire avec la commande + openssl + qui est installée par défaut sur les machines Ubuntu.

La commande que nous allons utiliser pour créer le certificat est la suivante:

Voyons ce que cela signifie:

Au cours du processus de création du certificat, vous serez invité à saisir des informations sur l’hôte que vous certifiez. Vous pouvez remplir ce champ avec les informations pertinentes que vous souhaitez sur le serveur:

Pour le + Common Name +, qui sera important dans notre autre certificat, vous pouvez indiquer ce que vous voulez.

Lorsque vous avez terminé, vous devriez avoir un fichier de certificat + ca.cert +, ainsi qu’une clé associée appelée + privkey.pem +.

Maintenant que nous avons le certificat de l’autorité de certification racine, nous pouvons générer une demande de signature de certificat pour nos ordinateurs clients.

Dans ce cas, tous les membres de notre consul sont des clients, y compris le serveur sur lequel nous fonctionnons actuellement. Au lieu de générer un certificat unique pour chaque serveur et de le signer avec notre autorité de certification, nous allons créer un certificat générique qui sera valide pour tous les hôtes de notre domaine.

Le format général de la commande sera le même, avec quelques différences mineures:

La différence entre la demande de certificat d’autorité de certification racine auto-signée que nous avons créée et la nouvelle demande de signature de certificat que nous générons maintenant est la suivante:

De nouveau, nous serons invités à répondre à la demande de signature de certificat (CSR). Cela est plus important que les réponses fournies pour le certificat d’autorité de certification racine auto-signé. Ici, nous devrons utiliser un caractère générique + Common Name pour que votre certificat soit valide comme étant valide pour chacun de nos hôtes:

Comme vous pouvez le voir ici, nous avons utilisé notre domaine, avec un astérisque en tant qu’hôte pour indiquer que le certificat doit être considéré comme valide pour tout hôte du domaine. Vous pouvez ignorer en toute sécurité le mot de passe de challenge et les invites facultatives de nom de société qui sont ajoutées à la fin.

Nous avons maintenant notre fichier de certificat d’autorité de certification racine auto-signé et une demande de signature de certificat générique qui correspond à tous les hôtes de notre domaine. Avant de pouvoir signer la demande de signature avec notre certificat de CA, nous devons créer un fichier de configuration qui contrôlera comment cela se passe.

Nous appellerons le fichier que nous sommes en train de créer + myca.conf + qui contiendra les informations de notre autorité de certification. Ouvrez ce fichier maintenant:

Ce fichier utilise un INI format divisé en sections. La première section que nous définirons est la section + ca +. La seule chose que nous ferons ici est de pointer sur notre section définie par l’utilisateur avec les informations réelles de l’autorité de certification:

Ensuite, nous allons créer la section que nous venons de référencer. Cela contiendra l’essentiel des détails de la configuration de l’autorité de certification.

Nous préciserons que les informations saisies dans les invites de certificat ne doivent pas nécessairement être uniques. Nous indiquerons ensuite l’emplacement de tous les fichiers que nous avons créés et nécessaires au processus de signature. Nous indiquerons + openssl + de placer de nouveaux certificats dans le répertoire actuel.

Nous souhaitons également sélectionner certaines valeurs par défaut à utiliser lorsqu’aucune alternative n’est spécifiée sur la ligne de commande. Nous sélectionnerons les certificats signés comme valables pour 10 ans et utiliserons l’algorithme + sha1 +. Enfin, nous indiquerons quelques sections supplémentaires que nous allons créer pour définir des informations supplémentaires:

À présent, concentrons-nous sur la première section définie par l’utilisateur que nous venons de référencer, qui est utilisée pour décider des informations à fournir pour que le CSR soit accepté. Nous allons marquer certains champs comme requis et d’autres comme facultatifs. Nous ferons des choix assez standard pour les invites habituelles:

La dernière section définira les extensions x509 que nous souhaitons utiliser lors de la signature de certificats.

Tout d’abord, nous devons lui dire que le certificat que nous allons signer n’est pas un certificat d’autorité de certification. Nous allons utiliser la valeur standard de «hash» pour l’identifiant de clé de sujet, car les chaînes hexagonales (l’alternative) sont fortement déconseillées.

Nous allons définir l’identifiant de clé d’autorité sur «keyid» pour copier l’identifiant de clé sujet du cert parent. Nous spécifierons également que les clés peuvent être utilisées comme signature ou avec un protocole qui chiffre les clés. Nous allons spécifier que l’utilisation étendue des clés peut être pour l’authentification du serveur et du client:

Dans l’ensemble, le fichier ressemble à ceci:

Enregistrez et fermez le fichier lorsque vous avez terminé. Nous avons maintenant un fichier de configuration substantiel qui peut être utilisé pour signer la demande de signature de certificat que nous avons générée précédemment.

Maintenant, nous avons tous les composants nécessaires pour signer le CSR et générer un certificat. Nous avons juste besoin de référencer le fichier de configuration que nous venons de créer et de transmettre le CSR que nous avons généré.

La commande que nous allons utiliser est:

Les options que nous utilisons sont:

Les autres options spécifient les fichiers d’entrée et de sortie.

Cela produira un fichier nommé + consul.cert + dans le répertoire actuel. Il créera également de nouvelles versions des fichiers + serial + et + certindex +, en déplaçant les anciennes versions vers les fichiers de sauvegarde. Un fichier + .pem + sera également créé en fonction du numéro de série dans le fichier + serial +.

Nous avons maintenant tous les composants nécessaires dans le répertoire + / etc / consul.d / ssl / CA +. Nous voulons copier les trois fichiers nécessaires dans le répertoire + / etc / consul.d / ssl +, où nous les référencerons:

Notre machine + server1 + qui contient l’autorité de certification a maintenant le certificat nécessaire et les fichiers de clé au bon endroit.

Pour les mettre sur les autres machines de votre infrastructure, + scp + est un bon choix. À partir du répertoire + / etc / consul.d / ssl + sur + server1 +, vous pouvez envoyer les fichiers nécessaires aux autres serveurs en tapant:

Modifiez les adresses IP pour référencer chacune des machines de votre infrastructure.

Maintenant que nous avons notre fichier de certificat racine et une paire certificat / clé pour nos membres consul, nous pouvons modifier nos fichiers de configuration consul afin de référencer ces fichiers.

Ouvrez chacun des fichiers de configuration consul sur vos serveurs. Pour notre machine + server1 +, nous commencerons par le fichier de configuration d’amorçage:

Le fichier devrait ressembler à ceci:

La première chose à faire est d’utiliser les paramètres consul pour identifier chacun de nos nouveaux fichiers. Le paramètre + ca_file + fait référence à l’emplacement du fichier de certificat de l’autorité de certification. Les paramètres + cert_file + et + key_file + font respectivement référence au certificat du client et aux fichiers de clé.

Celles-ci ayant également trait au chiffrement, nous allons l’ajouter sous le paramètre + encrypt + pour plus de clarté:

Nous avons maintenant défini les emplacements de ces fichiers, mais nous n’avons pas dit au consul que nous voulions vérifier l’authenticité de chacun des hôtes utilisant ces fichiers. Nous pouvons le faire maintenant en demandant au consul de vérifier les connexions entrantes et sortantes:

Enregistrez et fermez le fichier lorsque vous avez terminé.

Apportez ces mêmes modifications à chacun des fichiers de configuration utilisés par vos membres du consul.

Sur + server1 +, vous devez apporter ces modifications à + ​​/ etc / consul.d / bootstrap / config.json et` + / etc / consul.d / server / config.json + `.

Sur vos autres serveurs, il vous suffira de modifier + / etc / consul.d / server / config.json +. Sur votre (vos) machine (s) client (s), vous devrez modifier + / etc / consul.d / client / config.json +.

Pour mettre en œuvre notre trafic crypté, vous devez redémarrer la session consul sur chacun de vos membres consul.

Sur chaque machine de votre infrastructure, arrêtez brièvement puis relancez consul:

Cela arrêtera le processus et le redémarrera momentanément.

Si vous faites cela tour à tour sur chacun des membres de votre consul, ils passeront à l’utilisation de SSL pour chiffrer le trafic RPC entre eux. Lorsque seulement quelques-uns d’entre eux sont basculés, des problèmes de communication peuvent exister brièvement, du fait que certains trafics sont refusés pour ne pas être cryptés.

Lorsque tous les membres sont redémarrés, le trafic RPC doit être entièrement chiffré.

À ce stade, vous devez disposer d’un système de découverte de service relativement sécurisé pour votre infrastructure. Nous avons exploité tous les systèmes de sécurité natifs disponibles avec consul pour verrouiller l’accès et empêcher l’usurpation d’identité de nos différentes machines.