Cet article de blog fait écho au Meetup du Silicon Chalet Infrastructure as code, bonnes pratiques et pièges à éviter que j’ai eu l’occasion de présenter le 22.05.2025. À la fin de présentation, je parle notamment des fonctionnalités qui permettent de protéger des informations sensibles que ce soit avec OpenTofu mais aussi Terraform.
N’hésitez pas à aller faire un tour sur la présentation pour en savoir plus !
Les secrets… une boucle sans fin#
Quand on fait de l’Infrastructure as Code aussi appelé communément IaC, il est difficile d’esquiver le sujet des secrets ou des informations sensibles que l’on finit par stocker un jour ou l’autre dans le fameux state de Terraform ou d’OpenTofu…
En effet, dans ces deux langages déclaratifs, une des fonctionnalités principales est le stockage de l’état des ressources qui ont été déployées par l’outil. Cela comprend aussi bien les ressources classiques comme des réseaux, machines virtuelles mais aussi les fameuses clés APIs ou mots de passe de base de données que vous voulez déployer ou injecter dans vos applications ou services.
Une chose est sûre, les deux outils mentionnés plus haut évoluent et proposent depuis récemment des mécanismes internes pour protéger ou éviter de stocker de manière brute ces informations.
Depuis le changement de licence de Terraform il y a deux ans, OpenTofu est né mais a surtout pris de l’ampleur grâce à l’engouement de la communauté pour ce dernier et les ajouts récents pour augmenter les capacités de l’outil. En particulier sur la protection du state que HashiCorp, l’éditeur de Terraform s’est toujours refusé à implémenter dans la version open source.
Si jamais vous êtes intéressés par tout ce qui tourne autour des langages d’IaC, n’hésitez pas à aller consulter quelques bonnes pratiques, sans oublier la mise en place d’une CI/CD pour Terraform ou OpenTofu.
Prêt pour découvrir ce que ces deux outils peuvent vous proposer ? C’est parti !
OpenTofu#
OpenTofu ? Oui ! Le dernier né des outils d’IaC (enfin pas vraiment…) !
J’avais déjà introduit cet outil dans un article sur la création de ressources dans Cloudflare il y a quelques mois déjà.
Pour faire simple, OpenTofu est un dérivé de la version 1.6.x de Terraform avant son changement de licence en Business Source License réalisé deux ans auparavant.
Cette modification brusque de licence est sans grande conséquence pour la plupart des utilisateurs de Terraform, mais oblige ceux qui vendent des services incorporant cet outil à payer une contrepartie à son éditeur. Néanmoins, cela a fait beaucoup réagir la communauté sur le fait d’utiliser un outil aujourd’hui globalement utilisé pour déployer des ressources jusqu’à des contextes de production, qui peut modifier ses conditions d’utilisation du jour au lendemain.
C’est donc la Linux Foundation qui porte le projet, la même organisation derrière la CNCF et Kubernetes. Ce qui permet d’être relativement serein sur l’avenir de l’outil.
Avec ses deux ans d’existence, OpenTofu n’a fait que de progresser dans son adoption auprès des utilisateurs finaux notamment grâce à sa forte écoute de la communauté en introduisant des fonctionnalités demandées depuis très (très très) longtemps sur Terraform.
La première version, la 1.7.0 apporte le chiffrement du state. Pour moi, c’est clairement le plus gros manque au produit d’HashiCorp.
Sa mise en place est extrêmement simple et permet de s’interfacer avec une passphrase ou utiliser un Vault externe comme AWS KMS, Google Cloud KMS ou OpenBao.
terraform {
encryption {
key_provider "pbkdf2" "encryption_key" {
passphrase = var.encryption_passphrase
}
method "aes_gcm" "encryption_method" {
keys = key_provider.pbkdf2.encryption_key
}
state {
method = method.aes_gcm.encryption_method
enforced = true
}
plan {
method = method.aes_gcm.encryption_method
enforced = true
}
}
}
Exemple de configuration pour le chiffrement du plan et du state
{"serial":1,"lineage":"fb7d17fe-...","meta":{"key_provider.pbkdf2.encryption_key":"eyJzYWx...","encryption_version":"v0"}
Contenu d’un state chiffré
La vie d’OpenTofu n’est pas de tout repos, HashiCorp scrute souvent les évolutions de son adversaire, allant même jusqu’à vouloir l’attaquer en justice quand il juge l’implémentation de fonctionnalités trop proches des siennes.
Comme dit plus haut, la volonté d’OpenTofu est de suivre les désirs de la communauté, et cela va perdurer tout en gardant une maîtrise de la compatibilité avec Terraform, avec l’envie profonde de permettre aux personnes de migrer sans encombre.
Réduire OpenTofu au chiffrement de sa mémoire serait un peu trop réducteur… En effet, de nombreux changements sont arrivés depuis. Vous pouvez le constater au sein de la documentation.
Terraform#
Terraform est devenu depuis plusieurs années le standard de l’industrie en ce qui concerne la création d’infrastructure : son langage déclaratif, les multiples providers pour déployer des ressources, sans oublier l’utilisation d’un state pour conserver les actions réalisées par l’outil ont fait la force et la popularité de ce dernier.
Terraform continue grandement d’évoluer, la dernière version en date v1.12.x est sortie au milieu du mois de mai avec comme toujours une large panoplie d’améliorations.
Mais la fonctionnalité dont je voulais vous parler est arrivée avec la v1.10.x avec une belle évolution en v1.11.x.
Je parle bien sûr de la possibilité de rendre éphémères quelques unes de vos ressources !
Cet ajout de HashiCorp est une réponse assez claire au chiffrement du state offert par OpenTofu. Vous ne pouvez toujours pas chiffrer ce dernier avec Terraform, mais vous avez maintenant la possibilité d’éviter de stocker des ressources ou informations sensibles.
Cette fonctionnalité se décline en deux parties :
- Les ressources éphémères avec le mot clé
ephemeral, demandent une véritable implémentation du provider au sein de Terraform. Par exemple, le provider tls propose la ressourcetls_private_key.
ephemeral "tls_private_key" "this" {
algorithm = "ECDSA"
ecdsa_curve = "P384"
}
Exemple de ressource dite éphémère
Le cycle de vie est complètement différent comparé au bloc resource. En fait, une ressource éphémère ne dure que lors d’une phase plan ou apply sans persister le résultat dans le state. Ainsi, Terraform utilise un mécanisme d’ouverture et de fermeture pour accéder à celle-ci et récupère des informations de manière temporaire.
- Des arguments en écriture seule qui vont de pair avec les ressources éphémères.
En fait, une ressource éphémère ne peut lier ses outputs qu’à des ressources avec des champs suffixés en _wo.
Pourquoi ? Tout simplement car ces paramètres ne seront pas stockés non plus dans le state ou dans le plan de Terraform.
[...]
# kubernetes_secret_v1.this:
resource "kubernetes_secret_v1" "this" {
binary_data_wo = (write-only attribute)
data_wo = (write-only attribute)
data_wo_revision = 1
[...]
Le champs binary_data_wo et data_wo ne sont pas visibles au sein du state
_wo_revision ou _wo_version sont obligatoires si vous voulez injecter une valeur à un champ en _wo. En effet, c’est le seul moyen de dire à Terraform de modifier la valeur si ce dernier est incrémenté.La récupération et l’injection de valeurs sensibles pourrait utiliser ce type de mécanisme pour éviter de dupliquer l’information au sein du plan et du state.
Attention tout de même, les providers commencent à intégrer les deux composants décrits plus haut mais il faudra encore un peu de temps pour généraliser ça pour tous.
Un choix définitif ? Pas vraiment !#
Alors ? Plutôt chiffrement du state ou ressources éphémères ? OpenTofu ou Terraform ?
Eh bien j’ai une bonne nouvelle pour vous, OpenTofu donne un aperçu facilement accessible des travaux pour les futures versions, et, les ressources éphémères arriveront bel et bien dans OpenTofu au sein de la version v1.11.0.
Une issue GitHub avait été levée il y a quelques mois en faisant grandement réagir, ce qui a sans nul doute permis à l’équipe de développement de prévoir sa future intégration.
Une bonne raison de patienter, mais surtout encore une autre raison pour pourquoi pas migrer, n’est-ce pas ?
L’heure de la démo#
Cette démo a été réalisée pour le Meetup Silicon Chalet, elle permet de découvrir :
Vous pouvez la récupérer ici :
Pour tester ces deux fonctions vous pouvez, une fois le prérequis remplis…
- Soit exécuter les commandes décrites au sein du README ;
- Soit utiliser les scripts
opentofu-demo.shouterraform-demo.sh, et ainsi vous laisser guider.
Quelques mots pour conclure#
La sécurité et la protection des données sensibles sont des sujets très importants notamment dans le cadre d’une démarche DevSecOps. L’Infrastructure as Code n’échappe pas à la règle, et, l’arrivée d’un adversaire direct à Terraform a relancé ni plus ni moins la concurrence et l’arrivée de nouvelles fonctionnalités.
HashiCorp avec Terraform cherche à se démarquer sans diluer ses offres commerciales dans la version open source. Quant à OpenTofu, il continue sa volonté de rester à l’écoute de la communauté et de satisfaire les demandes, quitte à importer des concepts directement issus de Terraform si ces derniers suscitent l’engouement.
Le choix d’un outil réside aussi dans les fonctions proposées et je suis personnellement convaincu que le chiffrement du state à fait migrer pas mal d’entreprise vers OpenTofu. Je l’ai d’ailleurs vu chez les clients que j’accompagne en tant que consultant.
Même si ce OpenTofu est encore jeune, il hérite du passé de Terraform et donc de sa maturité. À vous de faire votre choix maintenant !