Dérive Terraform : Détecter et Corriger l'Incohérence des Infrastructures

Vous avez automatisé votre infrastructure avec Terraform. Super ! Mais que se passe-t-il quand quelqu'un fait une "correction rapide" directement dans la console cloud ? C'est ce qu'on appelle la Dérive d'Infrastructure (Drift), et c'est un tueur silencieux pour la fiabilité et la sécurité.

Pourquoi la Dérive est Dangereuse

• Changements non testés : Les modifications directes contournent vos pipelines CI/CD et vos tests.
• Failles de sécurité : Un port de pare-feu ouvert manuellement pourrait ne jamais être refermé.
• Échecs de déploiement : Terraform peut échouer ou produire des résultats inattendus lors de la prochaine mise à jour planifiée.

Comment Détecter la Dérive Automatiquement

1. Plans Planifiés : Exécutez terraform plan régulièrement (ex: toutes les 2 heures) et alertez en cas de changements détectés.
2. Outils Cloud Natifs : Utilisez AWS Config ou Azure Policy pour surveiller les changements de ressources en temps réel.
3. Plateformes IaC : Des outils comme Terraform Cloud, Spacelift ou Atlantis intègrent des fonctionnalités de détection de dérive.

Un workflow de dérive pragmatique

La détection de dérive n’est utile que si elle débouche sur une décision. Un workflow léger :

1. Trier : la dérive est-elle attendue (changement d’urgence) ou suspecte (acteur inconnu) ?
2. Décider : réconcilier dans le code vs revenir en arrière via Terraform.
3. Documenter : relier l’événement de dérive à un ticket et un owner.
4. Boucler : ajouter un garde-fou pour éviter la même dérive (policy, RBAC, template).

En environnement régulé, traitez les événements de dérive comme des signaux sécurité : visibles et auditables.

Corriger la Dérive

Une fois détectée, vous avez deux choix :

• Réconcilier : Mettre à jour votre code Terraform pour correspondre au changement manuel.
• Réinitialiser : Ré-exécuter Terraform pour écraser le changement manuel et restaurer l'état prévu.

Prévenir la dérive (mieux que la détecter)

• faire de Terraform le chemin par défaut : workflows pavés, templates, ownership clair
• utiliser un accès break-glass : limité dans le temps, audité, visible
• bloquer les changements console à risque via des policies (quand possible)

Anti-patterns fréquents

• changements console “temporaires” sans ticket, sans owner, sans expiration
• comptes admin partagés (pas de responsabilité)
• ignorer les alertes de dérive jusqu’au prochain incident

Ce qu’il faut mesurer

• nombre d’événements de dérive par semaine (doit baisser)
• temps moyen de résolution (triage → réconcilier/réinitialiser)
• % de changements passant par Terraform vs console

Conclusion

L'Infrastructure as Code n'a de valeur que si elle est la seule source de vérité. La mise en œuvre d'une détection automatique de la dérive garantit que votre documentation (le code) correspond toujours à la réalité, réduisant ainsi le risque opérationnel.