IaC : la bêta d’OpenTofu 1.7 provoque l’ire d’HashiCorp
Défiant la lettre de cessation et de désistement envoyée par HashiCorp, OpenTofu 1.7 bêta est livré avec la fonctionnalité de blocs retirés et le support du chiffrement des états côté client, réclamé depuis longtemps par la communauté Terraform.
La dernière bêta en date d’OpenTofu est vécue comme un affront par les créateurs originaux de Terraform. Non seulement elle inclut une fonctionnalité que Hashicorp a présentée comme une copie illégale de son propre travail, mais elle contient aussi une capacité inédite que l’éditeur n’a pas voulu prendre en charge.
Dans la controverse qui s’en est ensuivie, un consortium de ces concurrents et d’autres membres de la communauté open source ont lancé un projet de fork basé sur la dernière version sous licence Mozilla Public License v2.0 (MPL 2.0) de l’outil. Le projet a ensuite été admis au sein de la Fondation Linux, et sa première version stable prête à la production, OpenTofu 1.6, a été lancée en janvier.
Entretemps, en novembre dernier, HashiCorp a publié une mise à jour de Terraform sous BSL qui affine le processus par lequel les utilisateurs peuvent remanier le code de configuration sans détruire de façon permanente les ressources d’infrastructure sauvegardées dans les fichiers d’état de Terraform. Selon l’éditeur, cela faisait partie d’un processus remanié en vue d’intégrer une « nouvelle méthode plus rapide et moins sujette aux erreurs » dans le cadre de la révision des déploiements de Terraform 1.8. Ces fonctionnalités sont basées sur de nouveaux blocs de code Terraform appelés « blocs retirés » (removed blocks en VO).
En février, une pull request GitHub titrée « Add support for removed block » est apparue dans les dépôts d’OpenTofu, et la fonctionnalité a été ajoutée à la version alpha de la version 1.7 en mars. Le 3 avril, HashiCorp a envoyé à OpenTofu, par l’intermédiaire de ses avocats, une lettre de cessation et de désistement, affirmant qu’OpenTofu avait violé les conditions de son BSL en copiant le code du système de blocs retirés.
Les contributeurs principaux d’OpenTofu ont répondu publiquement le 11 avril en réfutant ces allégations de manière détaillée. Leur ligne de défense tient dans une analyse du code source ligne par ligne, qui indique que les blocs retirés ont été développés sur la base de la version open source de Terraform, et non de la version BSL.
Dans une tribune publiée dans un autre média IT, un professionnel – employé par un éditeur ayant, lui aussi, changé la licence de son produit autrefois open source – a tenu en son nom les mêmes allégations que Hashicorp. Après la réponse d’OpenTofu, l’éditeur de la publication a mis à jour la tribune avec une note précisant que l’accusation semble infondée et l’auteur du texte a publié un désaveu public sur les réseaux sociaux.
Les deux fonctions de blocs retirés ont les mêmes objectifs du point de vue de l’utilisateur – modifier les configurations des ressources sans supprimer l’état des ressources –, mais ont pris des chemins fonctionnellement différents pour y parvenir, avance Sebastian Stadil, fondateur et PDG de Scalr et membre de l’équipe centrale d’OpenTofu, dans des entretiens accordés à SearchITOperations, une publication sœur du MagIT.
« De manière générale, nous rédigeons la feuille de route du projet en fonction des commentaires et des besoins de la communauté », déclare Sebastian Stadil. « Certaines fonctionnalités sont similaires à ce que propose Terraform, d’autres sont exclusives aux utilisateurs d’OpenTofu ».
Sebastian Stadil ajoute qu’il n’y a pas eu d’autres échanges avec HashiCorp depuis la réponse publique d’OpenTofu, et les responsables du projet sont en train de répondre aux avis de retrait des repos envoyés à GitHub par HashiCorp, en vertu du Digital Millenium Copyright Act (DMCA). Jusqu’à présent, aucun dépôt n’a été supprimé.
Les représentants de HashiCorp n’ont pas répondu à une demande de commentaire envoyée la semaine dernière.
OpenTofu 1.7 s’attaque au chiffrement des états
La version 1.7 d’OpenTofu, publiée en version bêta jeudi dernier, contient également la première capacité d’un ensemble prévu de « fonctionnalités phares » qu’OpenTofu prendra en charge contrairement à Terraform, assure M. Stadil.
« Avec OpenTofu 1.7, vous avez la meilleure option gratuite et en open source, tandis qu’avec Terraform, vous avez une option inférieure moyennant des frais », lance-t-il.
Cette fonctionnalité, le chiffrement des états côté client, est réclamée par les membres de la communauté Terraform depuis 2016, mais n’a pas été incorporée dans le projet HashiCorp. La version de HashiCorp prend en charge le chiffrement de l’état – un ensemble de fichiers que Terraform utilise pour mapper les configurations aux ressources d’infrastructure et suivre les métadonnées – lorsqu’il est hébergé à distance sur un back-end en cloud, notamment sur son propre Terraform Cloud et sur ceux de ses partenaires fournisseurs de cloud. Les utilisateurs peuvent également masquer des données spécifiques dans les fichiers d’état, à l’aide d’un indicateur « sensible ».
La documentation de HashiCorp déconseille explicitement le chiffrement des états côté client.
« Une des expériences qui a été tentée consiste à permettre à l’utilisateur de fournir une clé PGP et un texte chiffré, et à déchiffrer la valeur dans le code du fournisseur avant de l’utiliser, en ne stockant que le texte chiffré dans l’état », peut-on lire dans la documentation. « Même sans le comparer au chiffrement intégral de l’état, le chiffrement par clé PGP présente des inconvénients majeurs. Les valeurs chiffrées avec une clé PGP ne peuvent pas être interpolées de manière fiable, Terraform n’est pas conçu pour fournir une bonne expérience utilisateur pour le moment quand une clé PGP manque, et l’approche nécessite de sérieuses modifications pour ne pas violer les exigences du protocole pour Terraform 0.12 et à l’avenir. ».
L’état stocké localement n’est donc pas chiffré, mais la documentation de Terraform indique que cette stratégie « était adaptée à une époque où l’état de Terraform devait être stocké en clair sur n’importe quelle machine exécutant terraform apply ». Ce n’est plus le cas depuis l’introduction des backends d’état à distance.
Cependant, le chiffrement des états à distance par les fournisseurs de cloud implique que les utilisateurs ne puissent pas séparer l’accès aux magasins d’états de l’accès au client Terraform ou chiffrer sélectivement des fichiers dans ces magasins, ce que certains utilisateurs très soucieux de la sécurité souhaiteraient faire afin d’ajouter une couche de protection supplémentaire.
« La différence tient dans le fait que dans un cas les données sont déjà chiffrées avant d’être envoyées, alors, que dans l’autre cas, elles sont en clair avant que [le provider] les chiffre et les stocke. Dans le premier, je ne vois jamais les données en clair, dans le second, si », affirme Stebastian Stadil.
Les avantages et les inconvénients du chiffrement des états
Dans les deux communautés (OpenTofu et Terraform), certains se sont inquiétés que les utilisateurs puissent perdre à l’accès aux états de l’outil IaC, s’ils perdent l’accès aux clés de chiffrement côté client. Or, l’approche d’OpenTofu permet aux utilisateurs de spécifier une configuration de repli pour le déchiffrement, et certains utilisateurs ont déclaré que ce risque avait été exagéré tout en ignorant les avantages potentiels.
« Le système mis en place dans OpenTofu chiffre l’ensemble du fichier d’état, et pas seulement les valeurs individuelles, et ne s’appuie pas sur les fournisseurs (providers) pour le faire », signale Robert Hafner, ancien contributeur de Terraform et auteur du livre « Terraform in Depth ». « Cela semble être un autre exemple où HashiCorp néglige la contribution de la communauté pour des motifs commerciaux, plutôt que pour des raisons techniques réelles ».
« Cela semble être un autre exemple où HashiCorp néglige la contribution de la communauté pour des motifs commerciaux, plutôt que pour des raisons techniques réelles. »
Robert HafnerAncien contributeur de Terraform et auteur du livre « Terraform in Depth »
Cette fonctionnalité a également suscité l’intérêt d’un autre professionnel dont l’entreprise s’en tiendra pour l’instant à Terraform Community Edition, au vu de la jeunesse d’OpenTofu, un projet qu’il suit néanmoins de très près.
« Nous utilisons la version autohébergée de GitLab [de Terraform state], ce qui nous permet de configurer le magasin de données derrière GitLab [où] nous gérons la sécurité d’accès et le chiffrement », indique Phil Fenstermacher, responsable de la conception et de l’architecture des systèmes à William and Mary, une université située à Williamsburg, en Virginie. « Mais si quelqu’un parvient à accéder aux fichiers en back-end, il pourra en lire le contenu en texte brut. Nous aimerions utiliser le chiffrement côté client pour chiffrer les données sensibles dans le fichier, car nous pourrions alors utiliser différentes clés de chiffrement pour différents projets, au lieu d’une seule clé pour tout ce qui se trouve derrière GitLab ».
