Chiffrer le state et les plans avec OpenTofu

Le bloc encryption est aujourd'hui l'une des différences les plus utiles entre OpenTofu et Terraform. Au lieu de compter uniquement sur le chiffrement du backend, OpenTofu peut chiffrer nativement le state, les plans et même les lectures de terraform_remote_state. C'est un vrai gain si vous partagez un backend entre plusieurs postes, si vous stockez des plans en artefacts de CI ou si vous voulez réduire la valeur d'un fichier vole.

Le point important est de comprendre ce que ce chiffrement fait vraiment. Il protege les données au repos, mais il ne remplace ni les sauvegardes, ni les contrôles d'accès, ni une stratégie de rotation des clés. Ce guide vous montre le bon enchaînement : configurer un nouveau projet, migrer un projet existant, gérer un rollover de clé ou de méthode, puis éviter les erreurs les plus fréquentes autour de fallback, enforced et tofu init.

Ce que vous allez apprendre

comprendre ce que le chiffrement OpenTofu protege et ce qu'il ne protege pas ;
chiffrer state et plans sur un projet neuf ;
migrer un state existant avec la méthode unencrypted et un fallback ;
gérer un changement de clé ou de méthode sans casser la lecture du state ;
étendre la protection a terraform_remote_state.

Ce que le chiffrement protege vraiment

Quand vous activez le chiffrement, OpenTofu protege vos fichiers de state et de plan au repos. Si un attaquant recupere le fichier sans la clé adaptée, il ne peut plus en lire directement le contenu.

En revanche, ce mecanisme :

ne remplace pas une sauvegarde ;
ne protege pas contre une corruption du state ;
ne protege pas contre un replay d'un ancien plan ou d'un ancien state ;
ne cache pas les données a la personne qui execute legitiment tofu plan ou tofu apply ;
ne dispense pas de limiter les accès au backend.

Autrement dit, le chiffrement natif n'est pas une permission magique. C'est une couche de defense supplémentaire qui réduit la valeur des artefacts et des fichiers au repos.

Prérequis

Avant de chiffrer votre state, vous devez être a l'aise avec :

les bases du state en IaC ;
le fonctionnement general de tofu init ;
les variables racine si vous comptez passer la passphrase via tfvars ou variables d'environnement.

Structure minimale du bloc encryption

Le schema logique du bloc encryption est toujours le même :

choisir un key provider ;
choisir une method ;
relier cette méthode a state, plan et, si besoin, remote_state_data_sources.

L'exemple le plus simple pour démarrer utilise :

pbkdf2 comme key provider ;
aes_gcm comme méthode de chiffrement.

Etape 1 - Chiffrer un nouveau projet

Pour un projet neuf, le cas le plus simple consiste a partir directement avec un state et un plan chiffres.

variable "state_passphrase" {
  description = "Passphrase used by the OpenTofu PBKDF2 key provider"
  type        = string
  sensitive   = true
}

terraform {
  encryption {
    key_provider "pbkdf2" "team" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.team
    }

    state {
      method   = method.aes_gcm.main
      enforced = true
    }

    plan {
      method   = method.aes_gcm.main
      enforced = true
    }
  }
}

Pourquoi `enforced = true`

L'option enforced sert a interdire l'écriture non chiffrée si la configuration ou les variables attendues ne sont pas presentes. C'est une façon simple d'éviter qu'un oubli de variable produise un state en clair sans que vous vous en rendiez compte.

Comment fournir la passphrase

Vous pouvez la fournir par un fichier de variables exclu du dépôt :

tofu init -var-file=secrets/dev.auto.tfvars
tofu plan -var-file=secrets/dev.auto.tfvars

Ou via une variable d'environnement TF_VAR_state_passphrase :

export TF_VAR_state_passphrase='une-passphrase-longue-et-unique'
tofu init
tofu plan

Le point clé est le suivant : comme le bloc encryption doit être résolu très tot, la valeur doit être disponible des tofu init.

Etape 2 - Migrer un projet existant vers un state chiffre

Un projet existant pose un problème spécifique : son state est encore en clair. OpenTofu refuse par défaut de le lire une fois le chiffrement declare, pour éviter de traiter un contenu potentiellement manipule.

La migration se fait donc avec une méthode unencrypted et un fallback temporaire.

variable "state_passphrase" {
  description = "Passphrase used for state and plan encryption"
  type        = string
  sensitive   = true
}

terraform {
  encryption {
    method "unencrypted" "migrate" {}

    key_provider "pbkdf2" "team" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.team
    }

    state {
      method = method.aes_gcm.main

      fallback {
        method = method.unencrypted.migrate
      }
    }

    plan {
      method = method.aes_gcm.main

      fallback {
        method = method.unencrypted.migrate
      }
    }
  }
}

Sequence de migration recommandée

Sauvegardez le state actuel et la clé qui servira au nouveau chiffrement.
Ajoutez la configuration ci-dessus avec unencrypted et fallback.
Passez la passphrase a tofu init, puis exécutez tofu plan et tofu apply.
Vérifiez qu'OpenTofu sait maintenant relire le state avec la nouvelle méthode.
Retirez ensuite le fallback vers unencrypted et activez enforced = true si ce n'est pas déjà fait.

Tant que la migration n'est pas terminée, ne renommez pas vos key providers ou vos methods a la légère. OpenTofu stocke des métadonnées qui s'appuient aussi sur ces identifiants.

Etape 3 - Changer de clé ou de méthode sans perdre la lecture

Le même mecanisme de fallback sert au rollover. Il permet d'introduire une nouvelle clé ou une nouvelle méthode tout en gardant la capacité de relire les anciens artefacts pendant la transition.

terraform {
  encryption {
    key_provider "pbkdf2" "old" {
      passphrase = var.old_passphrase
    }

    key_provider "pbkdf2" "new" {
      passphrase = var.new_passphrase
    }

    method "aes_gcm" "old" {
      keys = key_provider.pbkdf2.old
    }

    method "aes_gcm" "new" {
      keys = key_provider.pbkdf2.new
    }

    state {
      method = method.aes_gcm.new

      fallback {
        method = method.aes_gcm.old
      }
    }

    plan {
      method = method.aes_gcm.new

      fallback {
        method = method.aes_gcm.old
      }
    }
  }
}

OpenTofu tentera d'abord la nouvelle méthode, puis la méthode de secours si la lecture echoue. Lorsqu'il réécrit le state ou le plan, il utilise la nouvelle méthode.

Etape 4 - Étendre la protection a terraform_remote_state

OpenTofu peut aussi appliquer une configuration de chiffrement aux lectures de terraform_remote_state.

terraform {
  encryption {
    key_provider "pbkdf2" "shared" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "shared" {
      keys = key_provider.pbkdf2.shared
    }

    remote_state_data_sources {
      default {
        method = method.aes_gcm.shared
      }
    }
  }
}

Ce point est utile si vous segmentez vos stacks, mais qu'un projet doit lire les outputs d'un autre projet via terraform_remote_state.

Quel key provider choisir en pratique

Le plus simple pour debuter reste PBKDF2 avec une passphrase longue. Mais OpenTofu supporte aussi des integrations vers des systèmes de gestion de clés comme AWS KMS, GCP KMS, Azure Vault ou OpenBao.

Key provider	Quand l'utiliser	Limite principale
`pbkdf2`	premier déploiement, petite équipe, lab, besoin simple	la passphrase doit être gérée proprement par l'équipe
`aws_kms` / `gcp_kms` / `azure_vault`	environnement cloud déjà structure autour d'un KMS	plus de dépendances d'infrastructure et d'authentification
`openbao`	organisation déjà alignée sur un moteur de transit OpenBao	ajoute un service externe a maintenir

Ce qu'il ne faut pas faire

stocker la passphrase en clair dans le dépôt ;
activer le chiffrement sans sauvegarde du state et de la clé ;
supprimer un fallback avant d'avoir verifie la relecture du state ;
renommer key providers ou methods sans comprendre l'impact sur les métadonnées ;
croire que le chiffrement remplace les contrôles d'accès et les sauvegardes.

Dépannage

Symptôme	Cause probable	Solution
OpenTofu refuse de lire l'ancien state	migration lancée sans méthode `unencrypted` ni `fallback`	ajouter la phase de migration explicite puis rejouer `init`
le plan écrit encore en clair	`enforced` absent ou variables non chargées	ajouter `enforced = true` et vérifier les variables des `tofu init`
changement de nom du key provider casse la lecture	metadata liées au nom précédent	utiliser un `fallback` ou un `encrypted_metadata_alias` adapte
un projet lisant `terraform_remote_state` ne dechiffre pas	configuration absente dans `remote_state_data_sources`	déclarer la méthode pour la lecture du state distant
l'équipe perd l'accès au state	passphrase ou clé non sauvegardée	restaurer la bonne clé depuis votre procédure de sauvegarde

A retenir

Le bloc encryption est l'une des différences les plus utiles entre OpenTofu et Terraform.
Il protege les states et plans au repos, mais ne remplace ni les sauvegardes ni les contrôles d'accès.
Un projet existant doit être migre via unencrypted et fallback, pas en activant brutalement le chiffrement.
Le rollover d'une clé ou d'une méthode se traite aussi avec fallback.
Pensez aussi aux lectures terraform_remote_state si vous segmentez vos stacks.

Prochaines étapes

Migrer depuis Terraform Reprendre la bascule globale du dépôt si vous partez d'une base Terraform existante.

Variables dans init Comprendre pourquoi les variables doivent être disponibles des `tofu init` dans certains contextes OpenTofu.

Comprendre le state Revenir aux fondamentaux si vous devez expliquer la sensibilité du state a votre équipe.

Registry, CLI et OCI Industrialiser ensuite providers, caches et miroirs après la mise en place du chiffrement.