Chiffrer le state et les plans avec OpenTofu

Le bloc encryption est aujourd’hui l’une des differences 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 meme 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 reduire la valeur d’un fichier vole.

Le point important est de comprendre ce que ce chiffrement fait vraiment. Il protege les donnees au repos, mais il ne remplace ni les sauvegardes, ni les controles d’acces, ni une strategie de rotation des cles. Ce guide vous montre le bon enchainement : configurer un nouveau projet, migrer un projet existant, gerer un rollover de cle ou de methode, puis eviter les erreurs les plus frequentes 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 methode unencrypted et un fallback ;
gerer un changement de cle ou de methode sans casser la lecture du state ;
etendre 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 cle adaptee, 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 donnees a la personne qui execute legitiment tofu plan ou tofu apply ;
ne dispense pas de limiter les acces au backend.

Autrement dit, le chiffrement natif n’est pas une permission magique. C’est une couche de defense supplementaire qui reduit la valeur des artefacts et des fichiers au repos.

Prerequis

Avant de chiffrer votre state, vous devez etre 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 meme :

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

L’exemple le plus simple pour demarrer utilise :

pbkdf2 comme key provider ;
aes_gcm comme methode 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’ecriture non chiffree si la configuration ou les variables attendues ne sont pas presentes. C’est une facon simple d’eviter 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 depot :

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 cle est le suivant : comme le bloc encryption doit etre resolu tres tot, la valeur doit etre disponible des tofu init.

Etape 2 - Migrer un projet existant vers un state chiffre

Un projet existant pose un probleme specifique : son state est encore en clair. OpenTofu refuse par defaut de le lire une fois le chiffrement declare, pour eviter de traiter un contenu potentiellement manipule.

La migration se fait donc avec une methode 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 recommandee

Sauvegardez le state actuel et la cle qui servira au nouveau chiffrement.
Ajoutez la configuration ci-dessus avec unencrypted et fallback.
Passez la passphrase a tofu init, puis executez tofu plan et tofu apply.
Verifiez qu’OpenTofu sait maintenant relire le state avec la nouvelle methode.
Retirez ensuite le fallback vers unencrypted et activez enforced = true si ce n’est pas deja fait.

Tant que la migration n’est pas terminee, ne renommez pas vos key providers ou vos methods a la legere. OpenTofu stocke des metadonnees qui s’appuient aussi sur ces identifiants.

Etape 3 - Changer de cle ou de methode sans perdre la lecture

Le meme mecanisme de fallback sert au rollover. Il permet d’introduire une nouvelle cle ou une nouvelle methode tout en gardant la capacite 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 methode, puis la methode de secours si la lecture echoue. Lorsqu’il reecrit le state ou le plan, il utilise la nouvelle methode.

Etape 4 - Etendre 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 systemes de gestion de cles comme AWS KMS, GCP KMS, Azure Vault ou OpenBao.

Key provider	Quand l’utiliser	Limite principale
`pbkdf2`	premier deploiement, petite equipe, lab, besoin simple	la passphrase doit etre geree proprement par l’equipe
`aws_kms` / `gcp_kms` / `azure_vault`	environnement cloud deja structure autour d’un KMS	plus de dependances d’infrastructure et d’authentification
`openbao`	organisation deja alignee 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 depot ;
activer le chiffrement sans sauvegarde du state et de la cle ;
supprimer un fallback avant d’avoir verifie la relecture du state ;
renommer key providers ou methods sans comprendre l’impact sur les metadonnees ;
croire que le chiffrement remplace les controles d’acces et les sauvegardes.

Depannage

Symptome	Cause probable	Solution
OpenTofu refuse de lire l’ancien state	migration lancee sans methode `unencrypted` ni `fallback`	ajouter la phase de migration explicite puis rejouer `init`
le plan ecrit encore en clair	`enforced` absent ou variables non chargees	ajouter `enforced = true` et verifier les variables des `tofu init`
changement de nom du key provider casse la lecture	metadata liees au nom precedent	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`	declarer la methode pour la lecture du state distant
l’equipe perd l’acces au state	passphrase ou cle non sauvegardee	restaurer la bonne cle depuis votre procedure de sauvegarde

A retenir

Le bloc encryption est l’une des differences les plus utiles entre OpenTofu et Terraform.
Il protege les states et plans au repos, mais ne remplace ni les sauvegardes ni les controles d’acces.
Un projet existant doit etre migre via unencrypted et fallback, pas en activant brutalement le chiffrement.
Le rollover d’une cle ou d’une methode se traite aussi avec fallback.
Pensez aussi aux lectures terraform_remote_state si vous segmentez vos stacks.

Prochaines etapes

Migrer depuis Terraform Reprendre la bascule globale du depot si vous partez d'une base Terraform existante.

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

Comprendre le state Revenir aux fondamentaux si vous devez expliquer la sensibilite du state a votre equipe.

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