Terraform CI/CD : GitHub Actions, plan et Go/NoGo

Une pull request, notamment issue d’un fork, exécute du code non fiable. Les secrets et les droits de déploiement doivent rester inaccessibles à ce contexte.

1. Créer un dépôt de recette avec dossier infra/ et workflow de contrôle dédié.
2. Définir permissions: contents: read pour la CI sur pull request.
3. Réserver les identifiants cloud et le droit d’appliquer les changements à un workflow protégé distinct.

# Schéma de gouvernance
# PR externe -> format / validation, aucun secret
# Branche protégée -> plan avec identité contrôlée
# Environnement approuvé -> apply après Go/NoGo

fmt et validate donnent un premier niveau de qualité sans accorder d’accès aux comptes cloud.

1. Créer .github/workflows/terraform-checks.yml en adaptant la version Terraform.
2. Épingler les actions à un SHA de commit vérifié avant adoption en production : les tags major de cet exemple servent uniquement de point de départ.
3. Utiliser -backend=false pour éviter l’accès au state distant pendant ces contrôles.

# .github/workflows/terraform-checks.yml
name: Terraform checks
on:
  pull_request:
    paths:
      - "infra/**"
      - ".github/workflows/terraform-checks.yml"
permissions:
  contents: read
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "1.9.8"
      - run: terraform -chdir=infra fmt -check -recursive
      - run: terraform -chdir=infra init -backend=false -input=false
      - run: terraform -chdir=infra validate -no-color

Un badge vert ne suffit pas : il faut confirmer que les contrôles échouent lorsque le code est incohérent.

1. Ouvrir une pull request de recette avec du Terraform valide et contrôler les logs.
2. Créer ensuite une erreur de formatage puis une référence HCL invalide pour provoquer volontairement des échecs.
3. Rendre le job validate obligatoire dans la protection de main seulement après l’avoir vu fonctionner.

# Contrôles reproductibles en local :
terraform -chdir=infra fmt -check -recursive
terraform -chdir=infra init -backend=false -input=false
terraform -chdir=infra validate -no-color

plan peut interroger des APIs cloud et accéder au state ; il doit s’exécuter sur une identité limitée, dans le bon environnement.

1. Après revue, exécuter plan dans un workflow de branche protégée avec authentification éphémère OIDC si le provider le permet.
2. Init utilise le backend distant sécurisé et le verrouillage ; les permissions du rôle couvrent uniquement le périmètre requis.
3. Lire les créations, remplacements et suppressions avant de déclarer le plan acceptable.

terraform -chdir=infra init -input=false
terraform -chdir=infra plan -input=false -out=plan.bin
# Ne jamais publier plan.bin sur une PR publique.

La validation opérationnelle doit porter sur le contenu exact du plan et ses impacts, pas seulement sur la réussite de la CI.

1. Identifier l’approbateur et les critères : risque, coûts, disponibilité, dépendances, rollback.
2. Associer l’approbation à un commit et au plan contrôlé ; limiter les exécutions simultanées sur un state.
3. Après approbation, appliquer le plan sauvegardé avec un exécuteur protégé et des providers identiques.

# Commande à exécuter seulement après approbation
# depuis l'environnement sécurisé où le plan a été préparé :
terraform -chdir=infra apply -input=false plan.bin

La réussite technique d’apply n’assure ni disponibilité applicative ni réversibilité métier.

1. Contrôler les outputs attendus, l’état d’exploitation et les dépendances après apply.
2. Conserver les traces de validation, de revue et de déploiement dans un système à accès restreint.
3. Préparer des changements correctifs par un nouveau plan ; ne pas considérer terraform destroy comme un rollback universel.

terraform -chdir=infra output
terraform -chdir=infra plan -input=false
# Vérifications métiers et supervision à exécuter
# dans les outils du service concerné.