Tester les ACLs sur un cluster Consul avec Vagrant

J’ai eu l’occasion de mettre en place les ACLs (Access Control List) sur un système de production récemment. Leur objectif général est de compartimenter les accès suivant différents utilisateurs.

Dans mon cas client, Consul fonctionnant conjointement avec Nomad, c’était un besoin stratégique afin de donner des accès restreints aux clés/valeurs de Consul suivant différentes applications tournant dans des conteneurs, ainsi que de restreindre au maximum l’accès aux droits d’administration de l’outil.

Un petit guide est déjà fourni par Hashicorp pour un test rapide des ACLs.

Ici je vous propose quelque chose de plus complet, qui permet d’automatiser la construction d’un cluster de plusieurs machines de façon très proche des conditions réelles sur un environnement de test fonctionnant sur n’importe quelle machine (merci Vagrant !) et permettant d’expérimenter ce qui sera potentiellement la politique d’accès que vous voudrez mettre en production.

Mise en pratique

Nous allons lancer sur notre machine locale, dans un premier temps, un cluster simple, puis nous ajouterons les ACLs, sans perte de disponibilité du cluster.

Le seul prérequis est d’avoir installé Vagrant, ainsi qu’un provider associé, comme VirtualBox, ensuite je vous invite à récupérer le code du repository ici.

Une fois fait le cluster se lance simplement avec :

vagrant up

Ensuite on crée un tunnel SSH pour accéder à l’interface utilisateur :

vagrant ssh consulmaster1 -- -L 8500:localhost:8500

Vous avez désormais accès à l’interface Consul en accédant à localhost:8500.

Vous devriez voir les 3 masters ainsi que les 3 nodes comme ici :

C’est magique n’est-ce pas ? Voici ce qu’il vient de se passer, le fichier Vagrantfile contient le code d’instruction pour dire de lancer séquentiellement chacune des machines en utilisant le provider à disposition (par exemple VirtualBox).

Le Vagrantfile définit également les scripts lancés au démarrage des machines, qui font appel aux fichiers de configuration envoyés pour Consul.
Vous trouverez ces scripts respectivement dans les répertoires “scripts” et “configs” dans notre repository.

Nous allons maintenant nous intéresser à la mise en place des ACLs en elle-même.

Connectez-vous en ssh au master1, puis lancez le script “master-acl.sh”, le code suivant va s’exécuter, permettant de créer quelques clés/valeurs de test, puis définir les tokens pour le user anonymous (à qui on permet d’accéder globalement aux DNS, puis le token agent, que l’on va associer à chacun des nodes avec des droits larges pour les machines host, mais pas les droits d’administration) :

# Set some KVs
consul kv put var1 value1
consul kv put var2 value2
consul kv put var3 value3

# Set ACLs config
#
# Allow anonymous access for DNS
# https://www.consul.io/docs/commands/acl/token/update
##
consul acl policy create -name "dns-requests" -rules @/tmp/dns-request-policy.hcl
consul acl token update -id "00000000-0000-0000-0000-000000000002" -policy-name dns-requests
# Create agent token
# https://www.consul.io/docs/commands/acl/token/create
# https://www.consul.io/docs/commands/acl/set-agent-token
##
consul acl policy create -name "agent" -rules @/tmp/agent-policy.hcl
RES=$(consul acl token create -description "Agent Token" -policy-name agent)
AGENT_TOKEN=$(echo $RES  | cut -d" " -f4)
consul acl set-agent-token agent $AGENT_TOKEN

Vous noterez au passage que nous utilisons la dernière version des ACLs prévue pour Consul 1.8 (en vigueur depuis la 1.4) et qu’aucun redémarrage n’est nécessaire car nous passons simplement des instructions en lignes de commandes.

Maintenant, essayons d’accéder sur l’interface comme avant, en anonyme, sur la page des ACLs par exemple :

Et oui, nous sommes bloqués, l’utilisateur anonyme peut encore accéder aux services et aux nodes en lecture seule, comme spécifié dans sa policy.

Par contre, pour accéder aux clés/valeurs ou à la gestion des ACLs, il faut un utilisateur avec un peu plus de droits. L’agent, lui, a des droits d’écriture génériques comme nous l’avons demandé (c’est possible de restreindre), et le master token, lui, a encore tous les droits d’administration.

Afin d’administrer sur l’interface, vous pouvez vous connecter avec le master token, vous aurez à nouveau un accès complet, et vous pourrez voir les modifications faites sur les clés/valeurs et les ACLs.

Vous pouvez constater que les tokens sont bien renseignés, et piocher le token de l’agent, vous allez en avoir besoin pour lancer les commandes suivantes.

Maintenant, il s’agit de se connecter sur chacune des machines pour lancer le script “master_acls.sh” sur les deux autres, puis le script “node_acls.sh”, qui lanceront la même commande servant à associer les droits d’agent à la machine host :

consul acl set-agent-token agent $AGENT_TOKEN

Vous pouvez vérifier les logs dans /var/log/consul.log pour vous assurer que le cluster a un fonctionnement sain et que vous pouvez continuer à travailler avec.
Vous devriez recevoir un message positif de ce type :

Ensuite vous pouvez supprimer l’environnement avec un simple :

vagrant destroy -f

Conclusion

Vous avez vu et expérimenté une implémentation simple des ACLs sur un cluster Consul, libre à vous de configurer les droits exactement comme vous le souhaitez.

L’environnement peut très facilement être utilisé pour d’autres fonctionnalités concernant Consul (comme les Intentions ou Consul Connect par exemple).

N’hésitez pas à me faire des retours, ça serait avec grand plaisir d’y répondre. Au passage, je remercie mon cher collègue Teddy Ferdinand qui m’a bien inspiré pour utiliser Vagrant, avec son implémentation de K3S très pratique également.

Bon code à vous et portez-vous bien.