1 00:00:00,000 --> 00:00:14,000 [Musique] 2 00:00:14,000 --> 00:00:19,000 Bonjour à toutes et à tous, et bienvenue sur le podcast Yakafokon. 3 00:00:19,000 --> 00:00:25,000 Yakafokon est un podcast traitant de la sécurité de l'information, et de son implantation, notamment dans les pratiques DevOps. 4 00:00:25,000 --> 00:00:28,000 Je suis Florian Maury, et je bosse dans l'IT depuis 20 ans. 5 00:00:28,000 --> 00:00:35,000 J'ai occupé tout plein de postes, de développeur à architecte système ou architecte réseau, et même auditeur en sécurité. 6 00:00:35,000 --> 00:00:42,000 Je n'ai cependant que récemment embrassé les outils d'infrastructure codifiée et développé un système d'information dans sa globalité. 7 00:00:42,000 --> 00:00:48,000 Je suis actuellement freelance, et ce podcast est une manière de partager mes connaissances et réflexions avec la communauté, 8 00:00:48,000 --> 00:00:53,000 dans l'espoir d'initier des échanges constructifs et pourquoi pas faire évoluer la doctrine ! 9 00:00:53,000 --> 00:00:59,000 Côté philosophie, j'ai rapidement fait mienne l'idée que l'immuabilité est une propriété désirable pour une infrastructure. 10 00:00:59,000 --> 00:01:05,000 Peut-être est-ce du à mes expériences en développement qui m'ont permis d'apprendre la valeur de cette propriété dans des languages comme Ocaml ou Rust. 11 00:01:05,000 --> 00:01:12,000 Peut-être est-ce les mauvaises expériences que j'ai eu avec Ansible et les gestionnaires de configuration par mutation. 12 00:01:12,000 --> 00:01:19,000 Dans ce premier épisode de Yakafokon, je vais donc vous partager mon expérience avec Ansible pour la configuration d'une infrastructure par mutation. 13 00:01:19,000 --> 00:01:25,000 Cela servira de base pour la suite des discussions sur la pertinence de l'immuabilité, et les contraintes qui en découlent. 14 00:01:25,000 --> 00:01:32,000 Ce podcast est chapitré, de façon à permettre aux auditeurs et auditrices de zapper les chapitres qui ne les intéressent pas. 15 00:01:32,000 --> 00:01:37,000 Je vais commencer par rappeler ce qu'est Ansible. Il s'agit d'un outil de gestion de configuration. 16 00:01:37,000 --> 00:01:46,000 Les configurations sont exprimées en YAML et consistent en une succession d'actions, appelées tâches, à effectuer sur le ou les machines cibles. 17 00:01:46,000 --> 00:01:50,000 Chaque action consiste en l'appel d'un module avec des paramètres. 18 00:01:50,000 --> 00:01:56,000 Les modules Ansible sont développés en Python. Il en existe une multitude qui sont fournis par Ansible ou téléchargeables. 19 00:01:56,000 --> 00:02:00,000 Les différentes actions à réaliser peuvent être listées dans des rôles Ansible. 20 00:02:00,000 --> 00:02:04,000 Ces rôles sont des collections d'actions réutilisables et paramétrables. 21 00:02:04,000 --> 00:02:11,000 Des rôles sont publiés par la communauté sur des serveurs de distribution comme Ansible Galaxy, une sorte d'annuaires de rôles. 22 00:02:11,000 --> 00:02:21,000 Ces rôles peuvent ensuite être énumérés dans un fichier appelé playbook, qui décrit l'ensemble des rôles et tâches s'appliquant pour la réalisation d'un objectif spécifique à ce playbook. 23 00:02:21,000 --> 00:02:27,000 Passons maintenant aux problèmes que j'ai avec Ansible en tant qu'outil de gestion des configurations d'un parc de machines. 24 00:02:27,000 --> 00:02:34,000 Le premier point, probablement l'un des plus problématiques en tant que freelancer et chef d'entreprise, est celui de la licence. 25 00:02:34,000 --> 00:02:42,000 Ansible est publié sous licence GPL v3. Ses collections de modules sont publiées sous leurs propres licences, généralement GPL v3. 26 00:02:42,000 --> 00:02:47,000 Certaines sont publiées sous des licences plus libres, comme MIT ou BSD. 27 00:02:47,000 --> 00:02:55,000 Cet état de fait est déjà surprenant puisque certaines publiées sous des licences autres, utilisent en leur sein des bibliothèques issues du code source d'Ansible. 28 00:02:55,000 --> 00:03:00,000 Elles devraient donc être contaminées par la GPL v3 et devraient être publiées également sous cette licence. 29 00:03:00,000 --> 00:03:04,000 Le problème de la contamination de GPL v3 ne s'arrête cependant pas aux modules. 30 00:03:04,000 --> 00:03:11,000 Ainsi, il n'est pas clair si les configurations décrites en YAML et interprétées par Ansible sont elles-mêmes contaminées par GPL v3. 31 00:03:11,000 --> 00:03:16,000 Après tout, comme décrit précedemment, les modules sont appelés et paramétrés par la configuration. 32 00:03:16,000 --> 00:03:23,000 Cela pourrait donc tomber sous le coup de la licence GPL v3, à l'image d'un appel de fonction d'une bibliothèque publiée sous cette licence. 33 00:03:23,000 --> 00:03:29,000 Pour aller plus loin, des rôles publiés sur Ansible Galaxy sont eux-mêmes publiés sous une licence GPL v3. 34 00:03:29,000 --> 00:03:34,000 En conséquence, faire usage de ces rôles dans un playbook pourrait contaminer le playbook. 35 00:03:34,000 --> 00:03:42,000 En tant que développeur d'infrastructure codifiée, les playbooks et rôles que je pourrais développer pour ma société et que je pourrais ensuite revendre à mes clients, 36 00:03:42,000 --> 00:03:45,000 courent le risque d'être contaminés par la GPL v3. 37 00:03:45,000 --> 00:03:54,000 Il en résulterait alors une possible perte sèche de cet investissement, si mes clients décidaient de le publier librement sur Internet, comme le leur permet la licence ! 38 00:03:54,000 --> 00:04:00,000 Un autre problème d'Ansible, technique cette fois-ci, a rapport avec l'idempotence. 39 00:04:00,000 --> 00:04:07,000 L'idempotence est la propriété de pouvoir exécuter plusieurs fois une même action et de toujours obtenir le même résultat ou état final. 40 00:04:07,000 --> 00:04:10,000 L'exemple typique est celui d'une action de copie d'un fichier. 41 00:04:10,000 --> 00:04:17,000 Copier plusieurs fois le même fichier au même endroit devrait toujours résulter en un fichier à l'endroit indiqué, avec le contenu prévu. 42 00:04:17,000 --> 00:04:23,000 Ansible indique que la plupart des modules devraient avoir un comportement idempotent. 43 00:04:23,000 --> 00:04:26,000 Le coeur du problème se situe dans cet emploi du conditionnel. 44 00:04:26,000 --> 00:04:35,000 Il n'y a aucun engagem ent d'idempotence, et Ansible recommande même de "tester" pour savoir si une action est idempotente ou non, "en cas de doute". 45 00:04:35,000 --> 00:04:39,000 En outre, l'idempotence d'Ansible se limite à ses modules. 46 00:04:39,000 --> 00:04:45,000 Si ces modules installent des outils qui ne sont pas idempotents, par exemple l'utilitaire apt, 47 00:04:45,000 --> 00:04:48,000 alors le résultat ne sera pas nécessairement identique. 48 00:04:48,000 --> 00:04:55,000 Par exemple, apt installe, par défaut, la dernière version disponible d'un paquet Debian ; pas une version fixe. 49 00:04:55,000 --> 00:05:02,000 Il est possible de forcer apt à installer une version spécifique, mais c'est souvent la recette pour des problèmes de dépendances cassées. 50 00:05:02,000 --> 00:05:11,000 Pire, même si l'on utilise exclusivement des modules testés et dont on a pu confirmer l'idempotence, cela ne dit rien vis-à-vis de l'intégrité des modifications apportées par le playbook. 51 00:05:11,000 --> 00:05:20,000 En cas d'incident, par exemple réseau, au milieu de l'exécution d'un playbook, la machine cible restera dans un état intermédiaire jusqu'à ce que l'incident soit terminé. 52 00:05:20,000 --> 00:05:25,000 Certains systèmes de configuration utilisent une approche transactionnelle pour éviter ce genre d'écueil ; 53 00:05:25,000 --> 00:05:30,000 la nouvelle configuration n'est appliquée qu'une fois que toutes les modifications programmées ont été effectuées. 54 00:05:30,000 --> 00:05:37,000 C'est le cas, par exemple, de la distribution Suse Aeon, mais nous reviendrons ultérieurement dans ce podcast sur les distributions Linux dites "immuables". 55 00:05:37,000 --> 00:05:46,000 En outre, et même en faisant abstraction de l'absence de promesse d'idempotence, Ansible n'a qu'une connaissance très partielle de l'état réel d'un système ; 56 00:05:46,000 --> 00:05:52,000 il n'a connaissance que ce qui est décrit dans ses propres fichiers de configuration, et dans les faits qui sont récoltés pendant l'exécution du playbook. 57 00:05:52,000 --> 00:05:58,000 Si des modifications parasites ont été effectuées manuellement, ou de manière automatisés par des composants système, 58 00:05:58,000 --> 00:06:07,000 alors Ansible n'en saura rien, et n'y apportera aucune rémédiation, à moins qu'il s'agisse d'une ressource à laquelle le playbook a prévu d'apporter une modification ou d'en vérifier l'état. 59 00:06:07,000 --> 00:06:17,000 Ansible n'est donc pas une solution viable pour prévenir les serveurs "flocons de neige" comme sont appelés les serveurs dont la configuration a dérivé de celle de l'outil d'infrastructure codifiée. 60 00:06:17,000 --> 00:06:24,000 Finalement, le dernier point majeur me posant problème avec Ansible est la gestion des dépendences. 61 00:06:24,000 --> 00:06:28,000 Ces dernières années, les attaques sur les chaines d'approvisionnement sont devenues un point de préoccupation majeur. 62 00:06:28,000 --> 00:06:34,000 Ces attaques sont d'autant plus pertinentes que les systèmes d'information se complexifient et se densifient. 63 00:06:34,000 --> 00:06:39,000 Il peut devenir de plus en plus difficile d'avoir un inventaire clair des logiciels utilisés dans une infrastructure. 64 00:06:39,000 --> 00:06:50,000 Pour réduire les risques liés à ce type d'attaques, de nombreuses solutions ont été développées, à commencer par des inventaires des dépendances, avec un épinglage par numéros de version et par empreintes cryptographiques. 65 00:06:50,000 --> 00:06:57,000 Des projets comme cosign ont également vu le jour afin d'apporter de la transparence sur les clés cryptographiques pouvant être employées pour signer des artefacts. 66 00:06:57,000 --> 00:07:07,000 Ansible n'a pas du tout suivi ce chemin, et utilise encore un fichier requirements.yml pour référencer la liste des rôles et des collections de modules pouvant être utilisés dans un playbook. 67 00:07:07,000 --> 00:07:14,000 Ce fichier ne contient que des numéros de version et il n'est pas possible d'épingler cryptographiquement une version, sauf à utiliser une syntaxe baroque d'URL git ; 68 00:07:14,000 --> 00:07:26,000 au mieux, il existe un système de signatures GnuPG qui n'est fonctionnel qu'avec certains serveurs de distribution de roles et les collections, et notamment pas avec celui appelé Ansible Galaxy. 69 00:07:26,000 --> 00:07:36,000 En outre, on sait que cette approche avec de simples signatures s'est déja révélée insuffisante dans d'autres dépots de code, que ce soit npm pour Javascript ou pypi pour Python. 70 00:07:36,000 --> 00:07:42,000 Voilà. Je pense avoir fait le tour des problèmes que je vois à l'utilisation d'Ansible dans une infrastructure codifiée. 71 00:07:42,000 --> 00:07:53,000 Pour le résumer un peu brutalement, on ne sait pas ce qu'on utilise, on ne sait pas vraiment ce qui sera fait, et en plus, on peut être contraint de publier son code sous GPL v3 pour de sombres histoires de licence ! 72 00:07:53,000 --> 00:08:01,000 Alors peut-être que certaines ou certains me diront : "fort bien, et on utilise quoi du coup ? Salt Stack, Chef, Puppet, ou que sais-je ?" 73 00:08:01,000 --> 00:08:06,000 Eh bien, non. Cela ne résoud pas le problème et cela reste des outils de configuration par mutation. 74 00:08:06,000 --> 00:08:13,000 Dans le prochain épisode de ce podcast, je vous présenterai la solution que je privilégie pour l'heure : ignition et la distribution Linux Fedora Core OS. 74 00:08:13,000 --> 00:08:17,000 Les épisodes suivants seront consacrés aux sauvegardes, et à la gestion des secrets. 75 00:08:17,000 --> 00:08:22,000 En attendant ces prochains épisodes, n'hésitez pas à réagir et à commenter celui-ci ; 76 00:08:22,000 --> 00:08:25,000 vous pouvez le faire depuis n'importe quel compte sur le fédiverse. 77 00:08:25,000 --> 00:08:31,000 C'est mon premier podcast maison ; il y a surement des trucs à améliorer. Alors, à vos claviers ! Et merci pour votre écoute. 78 00:08:31,000 --> 00:08:32,000 À bientôt.