IaC : HashiCorp tente de mêler simplicité et sécurité
Au cours du mois de mars, HashiCorp a réalisé plusieurs annonces consacrées aux mises à jour de ses produits phares, dont Terraform et Terraform Cloud. L’éditeur met l’accent sur la sécurité et sur une plus grande simplicité d’utilisation, au détriment de certains utilisateurs qui n’auraient pas suivi sa méthode.
Terraform 1.4 est une version mineure de l’outil d’infrastructure as code. Elle apporte quelques simplifications pour les utilisateurs de l’interface en ligne de commande associée. La mise à jour introduit toutefois un changement cassant concernant la mise à jour des providers au lancement d’une commande terraform init.
Pour rappel, un provider est une forme d’extension pour interagir avec l’infrastructure que l’on souhaite orchestrer à l’aide de Terraform. Après avoir spécifié ce provider et exécuté la commande terraform init, Terraform recherche la dernière version de ce provider certifié auprès des fournisseurs cloud. Par défaut, ces fichiers sont téléchargés et stockés localement sur la machine du développeur ou de l’Ops ou dans un dépôt Git.
Si le provider est à jour, celui-ci est directement appelé, après une étape de vérification reliée à un « mécanisme de verrouillage des sommes de contrôle ».
Ce mécanisme dépend d’un système de fichier de verrouillage de dépendances. Chaque vérification crée ou met à jour un fichier pour vérifier ce qui est installé au moment d’exécuter la commande terraform init.
HashiCorp impose sa méthode de vérification des providers
De manière optionnelle, Terraform propose de longue date un mécanisme de mise en cache global des paquets des providers. Il présente l’intérêt de ne pas avoir à retélécharger toutes les dépendances pour un groupe d’utilisateurs utilisant les mêmes répertoires. Or, il pose un problème de compatibilité avec la vérification automatique des paquets puisque le système de cache global, plus ancien, n’utilise pas le même protocole de signature que celui utilisé localement.
Cela induisait une vérification partielle des dépendances des providers, rendant le fichier de verrouillage des dépendances « non portable », « un problème pour n’importe quelle équipe qui utilise la même configuration Terraform sur plusieurs plateformes ».
Certaines équipes, s’appuyant largement sur le mécanisme de cache partagé pour ne pas avoir à retélécharger et à revérifier des milliers de dépendances à chaque exécution de Terraform, n’utilisaient pas le fichier de verrouillage.
La version 1.4 ignore désormais les entrées du répertoire dans le cache global « à moins qu’elles ne correspondent à une somme de contrôle déjà suivie dans le fichier de verrouillage des dépendances de la configuration actuelle ».
Si l’élément du fichier de verrouillage faisant référence à une version d’un provider est déjà dans le cache global, Terraform utilise la version en cache.
En clair, Terraform impose désormais la vérification des dépendances, un « compromis acceptable », juge l’éditeur.
« Ce nouveau comportement est meilleur pour ceux qui utilisent Terraform selon nos recommandations, en vérifiant leurs fichiers de verrouillage dans leur système de contrôle de version », écrit Martin Atkins, ingénieur logiciel principal chez HashiCorp, en réponse aux questions de développeurs passablement agacés sur GitHub.
Or, ceux qui n’avaient pas mis en place le système de vérification parce qu’ils avaient trop de dépendances à (re) télécharger ne veulent pas forcément se plier à la pratique de l’éditeur qui semble plus sécurisée.
Pour les réfractaires, HashiCorp propose un contournement « temporaire » en passant par une configuration CLI. Elle s’appuie sur une vérification partielle des dépendances. Cela peut aussi poser quelques questions à ceux qui souhaitent migrer d’une version antérieure de Terraform qui n’imposait pas la vérification des dépendances.
Les autres ajustements de Terraform 1.4 doivent permettre de propulser une nouvelle interface dans Terraform Cloud. Désormais, l’interface permet de visualiser l’initiateur d’un plan, l’outil utilisé pour cela (par exemple un CLI) et quand il a été exécuté.
Sentinel contre Open Policy Agent : HashiCorp ne s’avoue pas vaincu
En regard des enjeux de sécurité, HashiCorp a également lancé ce mois-ci la disponibilité générale d’Open Policy Agent (OPA) dans Terraform Cloud, le système de policy as code open source imaginé par la startup Styra, un projet rattaché à la CNCF.
HashiCorp proposait déjà Sentinel, son propre moteur de règles de conformité, mais OPA gagne rapidement en popularité.
« Nous avons mis au point Sentinel en 2017, quand OPA n’existait pas », rappelle Armon Dagdar, cofondateur et CTO de HashiCorp au MagIT. « Sentinel est une fonction. Nous ne la vendons pas. Si vous préférez OPA, pas de problème, nous voulons supporter les deux technologies de la même manière », ajoute-t-il.
Même si le projet OPA est sous l’ombrelle de la CNCF, Armon Dagdar craint que le soutien d’une startup, Styra, ne suffise pas. « C’est une petite startup, je ne suis pas sûr qu’elle se porte très bien commercialement », lance-t-il.
« La plupart des grands projets open source qui tiennent sur la durée sont soutenus par de grands sponsors commerciaux. Il suffit de voir Apache Kafka, Spark, Kubernetes ou encore Linux. Un projet open source peut survivre sans un grand sponsor, mais c’est difficile », ajoute-t-il.
OPA est toutefois utilisée par un bon nombre de grands groupes technologiques dont Google, Netflix, Cisco, T-Mobile, Cloudflare, Atlassian ou encore Intuit. Red Hat, VMware, Fuge, Snyk et d’autres proposent ou commencent à proposer le support de cette technologie.
« Un projet open source peut survivre sans un grand sponsor, mais c’est difficile. »
Armon DagdarCofondateur et CTO de HashiCorp
« Nous la prenons en charge également, mais il faudra surveiller de près son évolution », prévient Armon Dagdar.
Dans un même temps, HashiCorp a lancé une refonte de l’interface utilisateur de Sentinel, d’abord disponible en bêta. Il s’agit de repérer plus facilement les problèmes de conformité qui affectent une infrastructure en ajoutant des filtres par statut, et des classements par importance.
En lien avec HashiCorp Vault, l’outil de gestion des secrets de l’éditeur prend désormais en charge les fournisseurs d’identifiants dynamiques. Cette fonctionnalité introduite en bêta en janvier dernier permet de créer des identifiants éphémères (des clés de chiffrement Just in Time) pour utiliser les services d’AWS, GCP et Azure. Ces secrets sont créés à la demande, et ne réclament donc pas de rotation ou de révocation. Ces identifiants just in time s’appuient sur une implémentation du standard Open ID Connect. Ce modèle fait largement penser au framework Sigstore. « Je pense que c’est une des fonctionnalités clés pour éviter la fuite des secrets », commente le CTO. « Maintenant, il faut que nous rendions ce mécanisme compatible avec le plus grand nombre de logiciels possible ».
L’éditeur veut aussi s’étendre au-delà du périmètre habituel de l’infrastructure as code. Après avoir renforcé la détection des dérives d’infrastructure, HashiCorp s’intéresse également à la validation continue avec les pré et postconditions, une fonctionnalité présentée en octobre dernier. Cette capacité est habituellement mise en œuvre à l’aide d’Argo CD et Flux. « La validation continue est un terrain intéressant pour Terraform Cloud », assure Armon Dagdar.
CDK : la réponse à Pulumi gagne en traction, selon le CTO d’HashiCorp
L’autre ère d’investissement pour HashiCorp concerne CDK, un projet lancé en 2020. Cloud Development Kit permet aux développeurs qui ne veulent pas forcément apprendre le DSL de Terraform, HCL (HashiCorp Configuration Language), de définir leurs infrastructures dans quelques langages populaires : TypeScript, Python, Java, C# et Go.
« Pulumi est probablement l’un des autres outils de provisionning important sur la place, avec ceux des fournisseurs de cloud », avance Armon Dagdar. « Depuis que nous avons lancé Terraform CDK, nous les voyons moins apparaître dans les conversations avec les clients ».
Selon le CTO, la grande différence entre Pulumi et Terraform résidait justement dans le fait que les développeurs n’ont pas à s’appuyer sur un langage de programmation spécifique. « Désormais, la différence se joue dans le nombre de providers disponibles : nous en avons plus de 2 500 providers, tandis que Pulumi en a peut-être 50 », vante le CTO.
Le 23 mars 2023, sur son site Web, Pulumi mentionne l’existence de 130 packages, dont au moins 110 sont officiellement supportés par Pulumi ou par des partenaires. Sur les 3 023 providers Terraform recensés, seulement 299 d’entre eux sont maintenus par Terraform ou ses partenaires. Les 2 724 autres proviennent de la communauté. Pulumi prend en charge d’autres langages (JavaScript, .Net et YAML) et ne manque pas non plus de rappeler que sa solution polyglotte est utilisée par 1 500 clients.
« CDK est devenu très populaire », assure Armon Dagdar.
Pourtant, CDK n’est pas encore un projet mature, préviennent les ingénieurs d’HashiCorp. « Terraform CDK pourrait subir des changements cassants d’ici à la disponibilité de la version 1.0 », notent-ils dans la documentation. CDK est pour l’instant disponible en version 0.15.
Il n’en reste pas moins qu’avec son portfolio grandissant (Terraform Cloud, Consul, Vault, Packer, Boundary, etc.), HashiCorp enregistre des progrès significatifs lors de son exercice financier 2023. Selon les résultats présentés le 9 mars dernier, l’éditeur a généré 475,9 millions de dollars sur cette période, soit une hausse de 48 % de son chiffre d’affaires par rapport à l’an passé. HashiCorp fait tout de même part de 274,2 millions de pertes nettes, contre 290,1 millions de dollars l’année précédente. À la fin du quatrième trimestre 2023, le 31 janvier 2023, l’entreprise dénombrait 4 131 clients, contre 2 715 à la fin du T4 2 022.
Pour approfondir sur Administration et supervision du Cloud
