Ansible est un outil qui permet de faire de l’IaC (Infrastructure as Code) et donc d’automatiser les configurations systèmes de serveurs, machines, VMs et autres. C’est un outil important dans l’univers DevOps, et qui permet d’administrer efficacement des systèmes d’informations plus ou moins hétérogènes (Linux et Windows par exemple). Son architecture est relativement simple, avec un contrôleur Ansible (il s'agit du master) qui contient les fichiers de configurations à appliquer sur les hôtes cibles. À noter qu’il fonctionne en mode push, et ne possède pas d’état courant comme c’est le cas pour Terraform.
Kerberos est un protocole qui permet à des utilisateurs de s’authentifier et d’accéder à des services sur le réseau. Au lieu de propager des mots de passes entre les différentes entités, un mécanisme de clés secrètes et de tickets est mis en place pour éviter toute fuite de données sensibles.
Kerberos repose sur trois composants majeurs :
Afin de permettre à une personne d’accéder à un service une fois authentifiée, voici les grandes étapes (simplifiées) du protocole Kerberos :
Le KDC se compose de deux services, l’AS (Authentication Server) et le TGS (Ticket-Granting Service). Le premier permet d’authentifier le client, et va lui fournir un ticket TGT (Ticket-Granting Ticket) pour communiquer avec le TGS en cas d’authentification réussie. Le TGS délivre quant à lui des tickets ST (Service Ticket) pour permettre au client de communiquer avec le service demandé.
Pour une meilleure compréhension, je vous invite vous renseigner sur le fonctionnement du protocole Kerberos.
Par défaut, le contrôleur Ansible utilise le protocole SSH pour communiquer avec les différents hôtes cibles. Néanmoins, lorsque ces derniers ont comme OS Windows, on préfère utiliser le service WinRM (Windows Remote Management) qui est installé par défaut, et qu’il suffit d’activer. Dans notre cas, nous avons choisi PSRP (PowerShell Remoting Protocol) qui est un protocole reposant sur celui de WinRM, car il permet de faire des déploiements à travers un bastion plus facilement.
Ainsi, lorsque nous administrons des hôtes cibles sous Windows, nous avons la possibilité d’utiliser différents modes d’authentification avec le protocole PSRP/WinRM dont Kerberos. D’ailleurs, Ansible recommande d’utiliser ce mode lorsque nous travaillons dans un domaine Windows (au sens Active Directory du terme). En outre, Kerberos est fortement conseillé dans un environnement de production, pour des raisons de sécurité.
Pour donner un peu plus de contexte, nous avons utilisé le protocole Kerberos avec Ansible pour déployer des VMs sur des HyperV Windows. L’ensemble de ces derniers étaient configurés et enregistrés dans le domaine Windows de l’Active Directory, d’où ce choix.
Afin de s’authentifier auprès du KDC avec nos comptes AD pour se connecter ensuite aux HyperV, nous avons dû mettre en place les configurations suivantes :
Il faut installer les paquets suivants sur votre contrôleur Ansible (dans notre cas il s'agit d’un serveur Ubuntu) :
apt install libkrb5-dev
pip3 install gssapi
Nous avons un fichier hyperv.yaml pour le groupe associé, et qui contient les variables suivantes :
$ansible-vault encrypt credentials.yaml
$ansible-playbook -i hosts.ini -l my-new-vm --vault-id vault@prompt -e ‘@credentials.yaml’ my-playbook-deploy-vm
Même si l’implémentation du protocole Kerberos se fait relativement sans trop de configuration, il est souvent rare de le faire fonctionner du premier coup,surtout dans une infrastructure complexe. Et c’est ce qui nous est arrivé
Voici quelques astuces pour débugger ce genre de connexion :
Même si l’intégration du protocole Kerberos avec Ansible ne nécessite pas beaucoup de configuration supplémentaire, ce mécanisme reste complexe et peut nécessiter un peu de debug pour faire fonctionner l’ensemble correctement. En revanche, il permet de renforcer la sécurité de vos déploiements avec Ansible grâce à l’authentification des clients et des services au sein de votre réseau.