Déployer un service Consul, mais surtout le sécuriser !

Cet article a été publié il y a 4 ans 3 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Maintenant que j’ai récupéré la main complète sur le destin de l’infrastructure publique dont fait partie le serveur qui héberge le blog, je prépare le futur, et ce futur passe par de l’infrastructure as code, notamment avec Terraform et Ansible. Pour le premier, un élément important du résultat est le fichier d’état de l’infrastructure, le fameux « tfstate ». Et pour le garder au chaud, j’ai voulu utiliser, plutôt qu’un fichier texte sur le pc, un service Consul. Mais il ne faut pas faire n’importe quoi avec.

Le parfait compagnon de Terraform

Consul fait partie d’une famille qu’on appelle service de stockage dit clé-valeur, comme Redis, même si ce dernier a une forte orientation « temporaire » car il sert souvent de mémoire cache. Il est développé par Hashicorp, la même boite qui s’occupe aussi de Terraform. Il est donc nativement inclus comme backend de stockage pour y conserver son précieux fichier tfstate.

Vous pourrez également y stocker quantité de données qui pourront être réutilisées par la suite. Un de nos clients chez Linkbynet l’utilise par exemple pour y enregistrer ses besoins en termes de projets et d’infrastructures liées (nom du projet, nombre de machines, dimensionnements, nommages des ressources), et on n’a plus qu’à lancer un pipeline qui va lire les valeurs et déployer l’infrastructure en fonction de ces données. Les usages sont donc multiples.

Évidemment, disposer d’un « serveur » consul n’a de sens que si on doit accéder à plusieurs machines à ces données, l’avoir en local est pratique pour faire des tests, mais superflu par rapport à un fichier plat local, notamment dans le cadre de Terraform.

Un déploiement sur Docker Swarm très rapide

Le service n’a pas besoin d’être répliqué vu l’usage basique, les volumes persistants ont été créés sur le NAS, et la stack est presque basique, je la partage quand même :

La partie importante pour un déploiement « docker prod ready », c’est l’entrypoint qui contient les commandes permettant de bien faire prendre en compte l’initialisation des ACL et l’activation du mode « bootstrap » qui sinon laisse le serveur en mode « dev », avec moults messages de debug pratique, mais surtout un mode « in-memory » qui va un peu à l’envers de ce qu’on cherche à faire à savoir disposer d’un stockage persistant.

Données précieuses, sécurité adaptée

En effet, par défaut, c’est grand ouvert. Quelque soit le mode de déploiement, vous lancez, deux secondes après vous pouvez enregistrer votre première clé. On va pas se mentir, c’est pas dingue. Si quelqu’un vient foutre le bordel, notamment sur votre fichier d’état, vous serez bon pour tout reprendre à la main. Pour un ou deux serveurs, c’est pas grave, quand vous déployez plusieurs dizaines de ressources différentes d’un coup, ça fait bien mal au cul. Il est donc nécessaire de mettre en place un certain niveau de protection.

Le transport

Tout d’abord, il faut garder à l’esprit que les communications se font en HTTP. C’est donc un minimum que de chiffrer le transport. Plusieurs options sont possibles en fonction du contexte.

Pour un serveur qui restera dans un réseau un peu privé et un accès semi-manuel (exécution d’outils sur son poste), on pourra utiliser un tunnel SSH avec transfert de port. On utilisera la forme suivante :

Ensuite, si vous interrogez le port local 8500, la connexion sera renvoyée à travers la connexion SSH pour interroger le port 8500 en face.

Dans mon cas, comme j’ai déployé le consul dans mon cluster Docker swarm, j’ai voulu passer par le reverse-proxy plutôt que le SSH. J’ai donc déployé du HTTPS avec un sous-domaine dédié et du Let’s Encrypt. C’est plus pratique dans ce dernier cas car consul peut être accédé par des outils tiers, comme un runner gitlab, et aussi, je peux utiliser n’importe quel PC sans forcément avoir mes clés SSH sur moi. Notez que dans un cas comme dans l’autre (SSH ou TLS), on est généralement sur des hauts niveaux de protection donc ça va.

L’authentification

Bien, le transport est chiffré, mais dans le cas d’HTTPS par exemple, ça ne résout pas un problème fondamental : si on connaît l’adresse, on fait ce qu’on veut du serveur. Fort heureusement, il est possible de mettre plusieurs choses en place.

La première qui est presque systématique sur les services que j’expose sur mon cluster Swarm, je met en place une authentification HTTP basique, qui repose sur un couple user/password que je génère quand je déploie le vhost sur le reverse-proxy. Sans ce couple, vous prenez une erreur 401 de la part d’Nginx. Les règles classiques se posent alors, entre longueur de mots de passe et complexité. Dans le cas présent où c’est conçu d’abord pour être exploité via des outils, la saisie manuelle n’étant pas nécessaire tout le temps je conseille de ne pas lésiner sur la longueur, pas de problème à disposer de couples de 32 caractères chacun, le tout bien aléatoire avec une palette étendue (alphanumérique, majuscule/minuscules, ponctuation). On évite quand même les emoji dans les login ou mots de passe qu’on commence à voir apparaître, déjà c’est pénible à taper sans clavier adapté, et croyez-le ou non ça a tendance à bien faire bugger les programmes, malgré les promesses d’UTF-8.

Consul de son côté dispose d’un système d’ACL qui semble bien fourni, mais que j’ai pour l’instant bien du mal à mettre en place. La faute à une documentation bien moins fournie et claire que peut l’être celle de Terraform, ou mieux celle d’Ansible qui regorge d’exemple pour tous les modules supportés permettant de mieux comprendre leur fonctionnement. Là si l’activation du moteur ACL est assez facile, la mise en place des règles de contrôle d’accès, et la création du token, semblent plus compliqués, sans parler de tester manuellement derrière, avec curl entre autres. Mais ceci dit, les ACL vous permettront notamment de limiter les actions d’une clé à certaines portions du serveur consul, ce qui permet d’éviter d’aller polluer les voisins.

À retenir, vous pouvez tout à fait activer les deux méthodes en même temps, Terraform permet de renseigner les informations pour les deux types de protection, il suffit d’initialiser le backend avec les options suivantes :

Un outil versatile

Ici vous n’avez entrevu qu’un usage de Consul, mais il a plusieurs autres qualités que je vous laisse découvrir avec le site officiel. Je lâche pas l’affaire sur les ACL, j’ai beau reconnaître l’avantage de ce système de gestion de permissions, j’ai toujours du mal avec les différentes implémentations, j’ai pleuré avec celles de Mumble par exemple, pareil pour Teamspeak 3, donc autant dire que ça va mettre un peu de temps. Mais je désespère pas 🙂