Un template…pour les cloner tous !
Pour que Ansible puisse agir sur des VMs fraichement déployées, il faut que ces dernières soient basées sur un template disposant du minimum nécessaire.
L’article ci-dessous va donc traiter de la préparation du modèle destiné à servir de référence pour la création des VMs composant un cluster Kubernetes.
PhotonOS
Cliquez sur l'image pour l'agrandir.
Le choix de l’OS retenu est PhotonOS.
Il s’agit d’une distribution Linux allégée et maintenue par VMware. Elle est cependant utilisable sur de nombreuses plateformes. De par sa faible empreinte mémoire, son kernel optimisé pour tourner sur l’hyperviseur ESXi et sa sécurité globale renforcée elle est une cible de choix pour exécuter des conteneurs.
Son usage ne convient pas forcément à tous les besoins, mais étant basée sur des packages RPM il est tout de même possible de l’exploiter pour des taches spécifiques.
Elle s’inscrit dans la ligne des « micro distributions ». Libre à chacun de retenir la cible de son choix. L’usage d’une microdistribution n’est pas obligatoire, mais si votre objectif est limité à faire tourner des conteneurs, alors autant sélectionner un OS spécialisé sur le sujet qui, limitera à la fois l’emprunte global de vos serveurs et sa surface d’attaque en exposant moins de composants.
Pour ceux qui seraient inquiets du lien entre VMware et PhotonOS, la distribution reste totalement open source. Si Broadcom décide de mettre fin au projet, un fork sera toujours possible si la communauté le décide.
La récupération de l’OS se fait par le téléchargement de l’image ISO (ou une OVA). Une image pour AWS, GCP et Azure sont disponibles. Il est même possible de trouver une image Raspberry.
À la date de rédaction de l’article, c’est la version 5.0 qu’il est possible de récupérer. Je vous invite à toujours vous assurer d’utiliser la dernière version disponible.
VM Hardware
Sous VMware
La création de la VM ne prend que quelques minutes. PhotonOS est directement disponible dans la liste des OS une fois la famille Linux retenue.
Cliquez sur l'image pour l'agrandir.
Il n’est pas forcément nécessaire de modifier les valeurs par défaut concernant la configuration matérielle. Personnellement j’agrandis simplement un peu le disque racine. De toute façon ces éléments pourront être modifiés lors des opérations de clonage.
Cliquez sur l'image pour l'agrandir.
À partir de là, la suite du tutoriel peut s’appliquer, peu importe le choix de votre hyperviseur.
Installation de l'OS
Cliquez sur l'image pour l'agrandir.
Une fois l’ISO chargée, hormis le minimal vitale comme le nom du serveur, sa config IP, il n’y a rien de compliqué.
Cliquez sur l'image pour l'agrandir.
Cliquez sur l'image pour l'agrandir.
À noter que plusieurs profils d’installation sont disponibles. Personnellement j’utilise Photon minimal, les autres options correspondent à des besoins spécifiques.
Cliquez sur l'image pour l'agrandir.
Il est possible de choisir entre deux Kernel, le premier generic, le second optimisé pour VMware. Étant donné que l’exemple est ici sous ESXi, c’est le choix numéro 2 que je retiens.
Cliquez sur l'image pour l'agrandir.
Attention cependant, j’ai déjà rencontré des problèmes par le passé avec ce kernel. Lorsqu’on utilise des binaires en dehors du repo par défaut de l’OS, il est possible que certaines incompatibilités apparaissent.
Retenez le kernel qui vous convient le mieux et restez sur un generic dans le cas d’un hyperviseur autre que ESXi.
Le clavier est aussi configuré par défaut en qwerty, soyez attentif lors du choix du password du compte root.
L’installation est extrêmement rapide, dans mon cas un tout petit peu plus de 1 min.
Cliquez sur l'image pour l'agrandir.
Configuration pour Ansible
Une fois l’installation terminée, il est nécessaire de « préparer » votre VM à être « templétisée », de manière à pouvoir être clonée à volonté pour créer rapidement de nouveaux nœuds Kubernetes.
update
Pour cela, la première étape consiste à mettre à jour votre OS.
Pour cela il vous suffit d’utiliser la commande :
tdnf update
Cliquez sur l'image pour l'agrandir.
tdnf correspond à Tiny DNF, une version allégée du gestionnaire de package DNF. La majorité des commandes connues associées fonctionne avec tdnf.
N’hésitez pas à redémarrer une fois l’update réalisé.
Creation des users et divers
Avant de poursuivre, il est préférable de mettre le clavier en azerty.
Pour cela il suffit de taper la commande.
localectl set-keymap fr
Cliquez sur l'image pour l'agrandir.
En lien direct avec ma configuration Ansible sous Windows , je crée mon utilisateur dédié à Ansible. Ainsi une fois déployé, je pourrais personnaliser l’installation de mes photonsOS basées sur ce template avec Ansible.
Dans mon cas, l’utilisateur est ansible-windows
useradd ansible-windows
mkdir /home/ansible-windows
chown -R ansible-windows /home/ansible-windows
Cliquez sur l'image pour l'agrandir.
Je prends ensuite l’identité de l’utilisateur pour générer sa configuration ssh.
su - ansible-windows
ssh-keygen
Cliquez sur l'image pour l'agrandir.
Je vais maintenant créer un second utilisateur, en l’occurrence mon user personnel pour me permettre de me connecter en SSH. Cela va me simplifier l’interaction avec le template en dehors de Ansible.
Même opération que pour pour le user ansible-windows, mais j’ajoute la commande passwd pour créer un password à l’utilisateur (ici bvivi57…ne me demander pas pourquoi…).
Cliquez sur l'image pour l'agrandir.
Dès lors, je vais pouvoir continuer la configuration via mon client SSH.
Cliquez sur l'image pour l'agrandir.
Je bascule en root.
su – root
Par défaut, photonOS impose une expiration du password pour les comptes locaux.
Vous pouvez vérifier ce point en root avec la commande.
chage -l root
Il est possible de changer cela avec la commande.
chage -I -1 -m 0 -M 99999 -E -1 root
Cliquez sur l'image pour l'agrandir.
Je fais de même avec mon utilisateur standard.
chage -I -1 -m 0 -M 99999 -E -1 bvivi57
Je sais que ce n’est pas une bonne pratique, et je ne vous encourage pas à le faire, surtout en entreprise. Néanmoins dans mon cas, ça simplifie mon usage. Attention, cela risque également de vous forcer à changer votre mot de passe à la prochaine connexion
Toujours en root, je modifie la conf NTP pour m’assurer d’avoir un template à l’heure. C’est mon contrôleur de domaine Windows qui me sert de source de référence.
Il suffit d’éditer le fichier /etc/systemd/timesyncd.conf .
vim /etc/systemd/timesyncd.conf
Cliquez sur l'image pour l'agrandir.
J’ajoute mon serveur via l’option NTP=
Je redémarre le service
systemctl restart systemd-timesyncd
Cliquez sur l'image pour l'agrandir.
Je termine par la bonne timezone via la commande
timedatectl set-timezone Europe/Paris
Je vérifie que tous est OK avec la commande timedatectl
Cliquez sur l'image pour l'agrandir.
Je profite d’être root et d’être sur mon template pour basculer à l’identité de mon utilisateur dédié à ansible ansible-windows
su – ansible-windows
Cliquez sur l'image pour l'agrandir.
Cliquez sur l'image pour l'agrandir.
Je viens ajouter la clef publique associée à ce même utilisateur, mais créée depuis mon poste de travail Windows à travers WSL.
Je copie donc cette clef depuis mon instance WSL du user ansible-windows, vers le fichier /home/ansible-windows/.ssh/authorized_keys du user ansible-windows mais de mon template sous photonOS.
Cliquez sur l'image pour l'agrandir.
(petite astuce pour ceux qui aurait des problèmes de copier-coller vers une instance SSH d’un photonOS avec vim, exécuter d’abord la commande suivante pour désactiver le mode visual de vim lors d’un clic droit echo "set mouse-=a" >> ~/.vimrc).
Enfin, je créer un fichier sudo, dans lequel j’autorise l’utilisateur ansible-windows de mon template à emprunter les droits root sans mot de passe.
vim /etc/sudoers.d/ansible-windows
ansible-windows ALL=(ALL) NOPASSWD:ALL
Cliquez sur l'image pour l'agrandir.
Cliquez sur l'image pour l'agrandir.
De cette manière, je peux, depuis mon PC Windows sur lequel j’ai installé Ansible via la couche WSL, piloter mon template PhotonOS sous l'identité du compte ansible-windows. Je vous invite à lire l’article sur la configuration d’Ansible sous Windows si cela ne vous parait pas assez clair.
Je dispose maintenant d’un template disposant du minimum vital pour être cloné et reproduit autant de fois que nécessaire afin de constituer mon cluster Kubernetes.
Étant donné qu’il dispose d’une configuration minimale pour être piloté par Ansible, chaque clone pourra également être configuré avec Ansible, et ceci depuis mon poste de travail Windows.
Cliquez sur l'image pour l'agrandir.
Le point cyber
Parce que même BFM vous parle cybersécurité, il faut bien une section sur le sujet.
La logique que j’ai retenue dans cet article est le pilotage d’un OS serveur depuis une instance Ansible locale à mon poste de travail. L’interaction se fait via une connexion SSH.
L’élément de sécurité le plus critique est donc la clef privée associée à mon utilisateur ansible-windows au sein de mon instance WSL.
Le vol de cette clef ou sa compromission , associés à un accès réseau au VLAN sur lequel mon template est déployé ainsi que les clones potentiels, rendraient possible le pilotage de l’ensemble par un tiers.
D’autres configurations sont envisagable, notamment l’usage d’un serveur Ansible dédié au sujet, avec par exemple l’hébergement d’une instance AWX, la GUI de Ansible. Dans ce cas, l’administrateur n’utilise pas directement son poste, mais s’authentifie sur AWX pour ensuite lancer ses playbooks Ansible. La ou les clefs privées (rien ne vous empêche d’exploiter des clefs différentes fonctions de vos environnements) sont dans ce cas portées par le serveur Ansible. C’est sans doute plus sécurisé dans un environnement d’entreprise.
Il est possible de renforcer la sécurité via quelques basiques qui pourront vous être donnés par n’importe quel modèle LLM d’IA à la chatGPT.
Générez vos clefs en 2048 bits, voire en 4096 bits, ou encore mieux utilisez ECDSA ou Ed25519 plutôt que RSA.
ssh-keygen -t ed25519 -C "votre_email@example.com"
Ne laissez pas vos clefs privées être accessibles par n’importe qui. Assurez-vous d’avoir des droits limités à vous-même.
Je ne l’ai pas fait ici, mais c’est une bonne pratique d’ajouter un mot de passe par dessus votre clef privée. Ainsi, son vol ne la rendra pas utilisable, mais cela vous obligera à rentrer le password à chaque usage. Un agent SSH comme Putty pageant peut vous aider pour cela.
Mettez en place des rotations de clefs. Par exemple, tous les trois mois régénérez de nouvelles clefs et mettez à jour les configurations.
Bref, j’entends souvent et avec raison qu’une authentification avec clef SSH est plus sécurisée qu’une authentification avec login et mot de passe. Mais je vois aussi beaucoup de mode « yolo » sur le sujet:
Comme pour les tokens API, les clefs JSON et autre mécanisme dépendant d’un fichier source, essayez toujours d’avoir un bon suivi de ces composants en entreprise et limiter le cas « Seigneur des anneaux » ou une clef pour les gouverner tous !
Comme pour les comptes de services, cibler vos besoins au plus juste, même si cela veut dire + de clefs !
Cliquez sur l'image pour l'agrandir.