Terraform 1.10 : Les valeurs éphémères redéfinissent la gestion des secrets

Le paysage de l’Infrastructure as Code est en pleine transformation, avec des rivalités technologiques comme celle entre Terraform, outil phare de HashiCorp, et OpenTofu, son fork open source. OpenTofu s’est distingué en intégrant des fonctionnalités comme le chiffrement des fichiers d’état (state files), une fonctionnalité qui a longtemps été demandée par les utilisateurs.

Face à cette concurrence, Terraform 1.10 introduit une réponse audacieuse et innovante : la ressource ephemeral. Contrairement au chiffrement des états, Terraform propose une méthode proactive qui intègre directement la gestion sécurisée des secrets dans ses workflows. Avec ephemeral, Terraform facilite l’interaction sécurisée avec des gestionnaires de secrets comme AWS Secrets Manager, Azure Key Vault, et Kubernetes Token Request, tout en évitant la persistance des secrets dans le fichier d’état.

Pourquoi la gestion des secrets est un défi dans Terraform ?

Les secrets, tels que des mots de passe, des clés API ou des certificats, sont souvent indispensables pour déployer une infrastructure. Voici quelques exemples d’utilisation :

Accéder à une base de données sur AWS.
Configurer une connexion sécurisée via un certificat sur Azure.
Obtenir des jetons temporaires dans un cluster Kubernetes.

Cependant, dans Terraform, ces secrets étaient historiquement stockés dans les fichiers d’état. Cela posait des risques majeurs :

Exposition accidentelle : Si un fichier d’état est mal configuré ou sauvegardé dans un backend non sécurisé, les secrets deviennent vulnérables.
Persistance inutile : Même après l’utilisation d’un secret, il reste inscrit dans l’état, augmentant le risque d’exposition.
Conformité difficile : Les normes imposent une gestion stricte des secrets, difficile à garantir si ces derniers persistent dans les fichiers d’état.

Voici la version corrigée, en tenant compte que c’est Terraform qui a dû répondre à OpenTofu avec sa fonctionnalité ephemeral.

La réponse d’OpenTofu : Chiffrement natif des fichiers d’état

L’une des fonctionnalités marquantes d’OpenTofu, introduite dès ses premières versions, est le chiffrement natif des fichiers d’état. Cette approche vise à résoudre un problème critique : les secrets sensibles stockés dans les fichiers d’état, qui peuvent être exposés en cas de mauvaise gestion ou de fuite.

Pourquoi le chiffrement natif d’OpenTofu a marqué un tournant ?

Historiquement, HashiCorp s’était opposé à intégrer le chiffrement des fichiers d’état directement dans Terraform, arguant que cette responsabilité devait revenir au backend (S3, Azure Blob Storage, etc.). Cette position a été critiquée, car elle reposait sur une bonne configuration des utilisateurs, laissant une marge importante à l’erreur humaine.

OpenTofu a donc adopté une approche radicalement différente : intégrer le chiffrement natif des fichiers d’état directement dans l’outil. Cela a permis aux utilisateurs de sécuriser leurs fichiers d’état au repos (at rest) sans dépendre de la configuration spécifique des backends.

Le chiffrement natif en détail

Avec OpenTofu, le chiffrement des fichiers d’état repose sur des algorithmes éprouvés comme AES-GCM et sur l’intégration de gestionnaires de clés (Key Management Systems) populaires tels que :

AWS KMS (Key Management Service),
Azure Key Vault,
Google Cloud KMS,
Et des solutions open source comme OpenBao.

Exemple de configuration avec AWS KMS

terraform {
  encryption {
    key_provider "aws_kms" "kms_key" {
      kms_key_id = "mon-kms-key-id"
      region     = "eu-west-1"
    }
    method "aes_gcm" "secure_method" {
      keys = key_provider.aws_kms.kms_key
    }
    state {
      method = method.aes_gcm.secure_method
    }
  }
}

Avec cette configuration :

Tous les fichiers d’état sont automatiquement chiffrés dès qu’ils sont créés ou mis à jour.
Les clés sont gérées de manière sécurisée via AWS KMS.

Les avantages du chiffrement d’OpenTofu

Protection des fichiers d’état au repos :
- Les secrets sensibles sont chiffrés, même pour les workflows existants, ce qui protège les configurations actuelles sans nécessiter de changements majeurs.
Flexibilité :
- Les utilisateurs peuvent choisir parmi plusieurs gestionnaires de clés, garantissant une compatibilité avec les environnements multi-clouds.
Conformité simplifiée :
- En chiffrant toutes les données au repos, OpenTofu facilite le respect des normes de sécurité.

Les limites du chiffrement natif

Bien que le chiffrement natif offre une protection importante, il présente certaines limites :

Persistance des secrets :
- Les secrets restent dans les fichiers d’état, même s’ils sont chiffrés. En cas de compromission des clés de chiffrement, les secrets pourraient être exposés.
Complexité opérationnelle :
- Configurer un gestionnaire de clés (KMS) peut ajouter une couche de complexité, notamment pour les petites équipes ou les débutants.
Impact sur les performances :
- Les opérations de chiffrement et de déchiffrement peuvent ralentir les workflows, surtout pour des projets volumineux.

Pourquoi le chiffrement natif a obligé Terraform à réagir ?

Le chiffrement natif a été une véritable rupture pour plusieurs raisons :

Simplification de la sécurité :
- Les utilisateurs n’ont plus à s’inquiéter des mauvaises configurations de backend. Avec OpenTofu, les fichiers d’état sont toujours chiffrés, quel que soit l’emplacement.
Adoption rapide :
- L’intégration d’une fonctionnalité aussi imortante a attiré une partie de la communauté Terraform, surtout parmi ceux qui exigeaient une meilleure sécurité.
Une solution adaptée aux workflows existants :
- Contrairement à Terraform, qui a répondu en introduisant ephemeral, OpenTofu s’est concentré sur l’amélioration des workflows existants, sans nécessiter de refonte ou de migration.

Face à cette avancée, HashiCorp a dû revoir sa position.

La réponse de Terraform : la ressource `ephemeral`

Terraform 1.10 révolutionne la gestion des secrets avec une nouvelle ressource appelée ephemeral. Cette ressource permet d’utiliser des secrets directement depuis des gestionnaires externes sans les inscrire dans le fichier d’état ou les journaux.

Principes clés de la ressource `ephemeral`

Accès dynamique aux secrets : Les secrets sont récupérés directement depuis des gestionnaires comme AWS Secrets Manager, Azure Key Vault, ou Kubernetes Token Request.
Stockage temporaire : Les secrets ne sont accessibles qu’en mémoire pendant l’exécution de Terraform et ne sont jamais inscrits dans l’état ou les logs.
Intégration avec des workflows existants : La ressource ephemeral fonctionne avec des providers existants, permettant une adoption facile.

Exemple concret : Gestion des secrets AWS avec Terraform

Imaginons que vous devez configurer une base de données PostgreSQL sur AWS. Voici un exemple complet utilisant ephemeral avec AWS Secrets Manager :

provider "aws" {
  region = "eu-west-2"
}

# Récupérer les informations d'une base de données existante
data "aws_db_instance" "example" {
  db_instance_identifier = "testdbinstance"
}

# Récupérer le secret depuis AWS Secrets Manager
ephemeral "aws_secretsmanager_secret_version" "db_master" {
  secret_id = data.aws_db_instance.example.master_user_secret[0].secret_arn
}

# Décoder les informations du secret
locals {
  credentials = jsondecode(ephemeral.aws_secretsmanager_secret_version.db_master.secret_string)
}

provider "postgresql" {
# Utiliser les informations du secret pour configurer PostgreSQL
  host     = data.aws_db_instance.example.address
  port     = data.aws_db_instance.example.port
  username = local.credentials["username"]
  password = local.credentials["password"]
}

# Créer une nouvelle base de données
resource "postgresql_database" "db" {
  name = "new_db"
}

Avantages de la ressource `ephemeral`

Sécurité renforcée : Les secrets ne sont jamais inscrits dans le fichier d’état ou les logs, éliminant les risques d’exposition accidentelle.
Intégration multi-cloud : La ressource prend en charge plusieurs providers, tels que AWS, Azure, et Kubernetes, rendant la gestion des secrets plus universelle.
Simplicité et flexibilité : Aucune configuration complexe n’est nécessaire. La ressource ephemeral s’intègre directement dans vos workflows Terraform existants.
Conformité facilitée : En évitant la persistance des secrets, cette approche simplifie le respect des normes de sécurité.

Limites des valeurs éphémères de Terraform

Voici les limites que je vois pour le moment, sans avoir encore pu tester la fonctionnalité de manière approfondie. Elles se basent sur les caractéristiques annoncées et les cas d’utilisation courants.

Nécessité d’un gestionnaire de secrets :
- Fonctionne mieux avec des outils comme AWS Secrets Manager ou HashiCorp Vault, ce qui peut compliquer la configuration pour des petites équipes.
Impact sur les projets existants :
- Migration nécessaire pour convertir les variables sensibles en ephemeral.
- Synchronisation obligatoire avec des gestionnaires de secrets externes.
Compatibilité limitée :
- Certains workflows complexes, comme les environnements multi-clouds ou partagés, peuvent être freinés par l’absence de persistance des secrets.
- Tous les providers Terraform ne sont pas encore pleinement intégrés avec la ressource ephemeral.
Erreurs humaines possibles :
- Les secrets doivent être manuellement marqués comme éphémères, augmentant le risque d’oublis ou d’erreurs.
Pas de protection des secrets existants :
- Les secrets déjà présents dans les fichiers d’état nécessitent une migration manuelle et un nettoyage des fichiers.

Comparaison Terraform vs OpenTofu

Caractéristique	Terraform 1.10 (ephemeral)	OpenTofu (chiffrement)
Approche	Supprime les secrets du fichier d’état	Chiffre les fichiers d’état
Configuration requise	Simple, basée sur les ressources	Complexe, nécessite des gestionnaires de clés
Risques résiduels	Aucun stockage des secrets	Les secrets restent présents, mais chiffrés
Performance	Pas d’impact	Peut ralentir les opérations sur le fichier d’état

Conclusion

Avec la ressource ephemeral, Terraform 1.10 offre une solution innovante et proactive à la gestion des secrets. Contrairement à OpenTofu, qui protège les données en les chiffrant, Terraform supprime complètement les secrets des fichiers d’état, réduisant ainsi les risques à la source. Cette approche s’intègre facilement dans des workflows existants, tout en répondant aux exigences modernes de sécurité et de conformité.

Le duel entre Terraform et OpenTofu est une excellente nouvelle pour les utilisateurs. Ces deux outils offrent désormais des options solides pour gérer les secrets et sécuriser les infrastructures. Que vous choisissiez le chiffrement natif d’OpenTofu ou les valeurs éphémères de Terraform, l’essentiel est de sélectionner l’approche qui convient le mieux à vos besoins. Une chose est sûre : la sécurité des secrets dans l’Infrastructure as Code est aujourd’hui plus accessible que jamais.