L'état Terraform est le joyau : protégez-le comme tel

L'affirmation

Les équipes adoptent l'infrastructure comme code pour la reproductibilité, puis stockent le seul fichier qui la rend reproductible — le fichier d'état — sur un portable, dans un dépôt Git ou dans un seau que tout le monde peut lire. Ce fichier est une carte complète de votre infrastructure et, pire, un relevé en clair de bon nombre de ses secrets. Si vous utilisez Terraform ou OpenTofu, la façon de stocker et de verrouiller l'état est une décision plus importante que tout ce qui figure dans votre configuration.

Ce que contient réellement le fichier d'état

L'état n'est pas qu'une liste de ressources. C'est la correspondance entre votre code et les ressources réelles qu'il a créées, avec leurs attributs actuels — et Terraform écrit ces attributs tels quels, secrets compris. Un mot de passe de base de données défini via une ressource, une clé d'accès générée pour un compte de service, une clé privée, l'identifiant initial d'administration : si c'était l'attribut d'une ressource gérée, il se trouve en clair dans le fichier d'état.

grep -o '"password":[^,]*' terraform.tfstate    # ne soyez pas surpris du resultat

Ce seul fait exclut immédiatement trois emplacements de stockage : jamais un dépôt Git, car l'historique est éternel et les bifurcations publiques arrivent ; jamais un portable, car les portables se perdent et se copient ; jamais un seau à lecture large, car « interne » n'est pas « chiffré et audité ».

Les deux problèmes que règle l'état distant

Stocker l'état dans un magasin partagé et verrouillant règle d'un coup un problème de sécurité et un problème d'exactitude.

Le problème de sécurité, ce sont les secrets en clair ci-dessus : un magasin adéquat chiffre l'état au repos et restreint qui peut le lire. Le problème d'exactitude, c'est la modification concurrente. Si deux ingénieurs lancent apply sur la même infrastructure en même temps, et que l'état vit sur leurs deux portables, chacun fera des changements que l'état de l'autre ignore — d'où des ressources dupliquées, des ressources orphelines que Terraform ne suit plus, et un fichier d'état qui ne correspond plus à la réalité. Le verrouillage d'état fait attendre le second apply jusqu'à la fin du premier.

Un magasin correct

terraform {
  backend "s3" {
    bucket         = "acme-tf-state"
    key            = "prod/terraform.tfstate"
    region         = "ca-central-1"
    encrypt        = true
    use_lockfile   = true          # verrouillage S3 natif
  }
}

Trois propriétés rendent cela sûr. encrypt = true chiffre l'objet au repos. Le seau a le versionnage activé, pour qu'un état corrompu ou supprimé par accident se restaure à la version précédente — la corruption d'état n'est récupérable que si vous avez gardé l'historique. Et le verrouillage est activé, pour que les applications concurrentes se sérialisent au lieu d'entrer en collision.

# configuration du seau, a poser une fois :
# - versionnage : active  (historique / restauration)
# - chiffrement : active  (au repos)
# - acces public : bloque
# - acces : un role unique, pas des utilisateurs individuels

Gardez les secrets hors de l'état quand vous le pouvez

Le chiffrement au repos protège le fichier, mais le meilleur secret dans un état est celui qui n'y est pas. Deux habitudes réduisent l'exposition. D'abord, générez les secrets hors de Terraform et référencez-les — laissez l'application ou un gestionnaire de secrets créer le mot de passe de base de données, et ne passez à Terraform qu'une référence, pas la valeur. Ensuite, quand Terraform doit manipuler un secret, marquez la variable sensitive = true pour qu'elle soit masquée dans la sortie du plan et les journaux, là où les secrets fuient vers les systèmes d'intégration et l'historique du terminal même quand le fichier d'état est bien protégé.

Aucune de ces habitudes ne retire entièrement les secrets de l'état — certaines ressources renvoient des identifiants générés comme attributs quoi qu'il arrive — ce qui est précisément pourquoi le chiffrement et un accès restreint sur le magasin restent non négociables.

La règle du rayon d'impact : scindez votre état

Un fichier d'état unique pour toute votre infrastructure signifie qu'une seule erreur — ou un seul terraform destroy lancé dans le mauvais répertoire — peut tout affecter. Scindez l'état par rayon d'impact : des fichiers séparés pour le réseau, pour les magasins de données et pour la couche applicative, pour qu'une application à la couche applicative ne puisse pas toucher la base, et qu'un état applicatif corrompu n'emporte pas le réseau. La frontière à tracer entoure les choses qui changent à des rythmes différents et que vous ne voudriez jamais détruire ensemble.

La reprise à tester avant d'en avoir besoin

L'état peut être perdu ou corrompu, et la voie de reprise n'est pas évidente sous pression : parcourez-la une fois sciemment. Confirmez que vous pouvez restaurer une version antérieure de l'état depuis l'historique du seau. Confirmez que vous pouvez réimporter une ressource réelle existante dans l'état avec terraform import si la correspondance est perdue. Et gardez la configuration du magasin elle-même — le seau, le verrouillage — documentée hors de Terraform, car c'est le seul morceau d'infrastructure que Terraform ne peut pas amorcer pour vous. L'équipe qui a restauré l'état une fois, un après-midi calme, se remet du vrai incident en minutes ; celle qui ne l'a jamais fait passe l'incident à découvrir que terraform import existe.