Terraform State : sécuriser S3 et le verrouillage

Une migration sans cartographie expose à un écrasement d’état ou à l’utilisation de deux sources de vérité.

1. Identifier les projets, environnements, pipelines, comptes AWS et responsables du state.
2. Déterminer s’il existe déjà un backend distant et vérifier son mode de verrouillage.
3. Suspendre les écritures concurrentes pour toute opération de migration planifiée.

terraform version
terraform workspace show
terraform state list

Un backend distant n’est pas automatiquement sécurisé : la conservation des versions et les permissions doivent être établies avant usage.

1. Faire créer un bucket dédié au state, avec block public access, chiffrement au repos et versioning.
2. Tester l’accès via un rôle IAM ; restreindre bucket, préfixe et fichiers .tflock nécessaires.
3. Contrôler les règles d’audit, de rétention et les opérations de restauration S3 versioning.

aws s3api get-bucket-versioning --bucket NOM_DU_BUCKET
aws s3api get-public-access-block --bucket NOM_DU_BUCKET
aws s3api get-bucket-encryption --bucket NOM_DU_BUCKET

Le paramètre use_lockfile est la méthode native S3 recommandée ; le verrouillage fondé sur DynamoDB est déprécié dans la documentation actuelle.

1. Renseigner bucket, key, région réelle du bucket et use_lockfile=true.
2. Éviter toute clé AWS, secret, token ou mot de passe directement dans les fichiers .tf ou options -backend-config.
3. Différencier les fichiers d’état par environnement et vérifier que les permissions couvrent aussi la clé .tflock.

# backend.tf (exemple de structure à adapter)
terraform {
  backend "s3" {
    bucket       = "NOM_DU_BUCKET"
    key          = "plateforme/recette/terraform.tfstate"
    region       = "eu-west-3"
    encrypt      = true
    use_lockfile = true
  }
}

La première initialisation et le déplacement d’un state existant sont deux opérations différentes qui ne doivent pas être confondues.

1. Sur un laboratoire neuf sans state à migrer, exécuter terraform init avec les identifiants IAM du rôle autorisé.
2. Si un state local existe, le sauvegarder de façon sécurisée et organiser une migration encadrée avec terraform init -migrate-state ; examiner les demandes de confirmation.
3. Vérifier l’emplacement réellement configuré ; ne pas utiliser -reconfigure pour masquer un écart de state sans investigation.

# Laboratoire neuf, après contrôle du backend :
terraform init
terraform validate
terraform plan

Le vrai critère est d’empêcher les écritures concurrentes tout en autorisant les opérations normales d’un runner légitime.

1. Vérifier que le rôle de travail possède les droits nécessaires sur le state et sur .tflock, sans accès à tous les buckets.
2. Dans un laboratoire, organiser un test d’exécution simultanée contrôlé et vérifier qu’une seconde écriture attend ou échoue proprement.
3. Observer l’objet de verrouillage pendant l’opération et vérifier sa disparition après la fin du processus.

# Exemple de vérification non destructive du state suivi :
terraform state list
# Tester les accès et le lock sous supervision,
# sans exécuter deux apply concurrents en production.

La réversibilité exige de savoir retrouver une version saine et les acteurs habilités avant une panne.

1. Documenter le préfixe de state, les propriétaires, la rétention et les sauvegardes.
2. Tester en recette l’identification d’une ancienne version S3 sans la restaurer dans un state actif de production.
3. Prévoir un plan de récupération validé par un pair avant toute modification manuelle de state.

aws s3api list-object-versions \
  --bucket NOM_DU_BUCKET \
  --prefix plateforme/recette/terraform.tfstate