Quand votre console cloud et votre code IaC ne sont pas d'accord : détection automatique de la dérive d'infrastructure

Vous gérez votre infrastructure via Terraform depuis des mois. Tout est défini dans le code, relu via des pull requests et déployé via des pipelines. Un jour, un membre de l'équipe doit corriger rapidement un problème de configuration. Au lieu de passer par le pipeline, il se connecte à la console cloud, modifie manuellement une règle de groupe de sécurité, et passe à autre chose. La modification fonctionne. Personne n'y repense.

Des semaines plus tard, vous lancez un nouveau déploiement. Terraform prévoit d'annuler cette modification du groupe de sécurité car le code contient toujours l'ancienne définition. Si vous appliquez le plan, la modification délibérée sera écrasée. Si vous l'ignorez, votre code ne correspond plus à la réalité. Vous avez maintenant une dérive d'infrastructure.

La dérive est l'écart entre ce que votre code d'infrastructure déclare devoir exister et ce qui existe réellement dans votre environnement cloud. Ce n'est pas un problème théorique. Cela arrive dans toutes les équipes qui gèrent l'infrastructure à grande échelle. La question n'est pas de savoir si la dérive se produira, mais à quelle vitesse vous la détecterez.

Pourquoi la détection manuelle de la dérive échoue

Techniquement, vous pouvez détecter la dérive en ouvrant votre console cloud, en inspectant chaque ressource et en la comparant avec votre code IaC. Cela fonctionne quand vous gérez cinq ressources. Cela cesse de fonctionner quand vous en gérez cinquante, cinq cents ou cinq mille.

La détection manuelle a trois problèmes. Premièrement, elle est lente. Une simple comparaison peut prendre des minutes. Multipliez cela par des centaines de ressources, et vous passez des heures sur quelque chose qui devrait être automatisé. Deuxièmement, elle n'est pas fiable. L'œil humain manque les petites différences, surtout quand les ressources ont des dizaines de champs de configuration. Troisièmement, elle est incohérente. Différents membres de l'équipe peuvent vérifier des choses différentes, ou oublier de vérifier complètement.

Le vrai problème est le timing. La dérive peut survenir à tout moment. Une vérification manuelle une fois par semaine signifie que vous pouvez vivre avec un changement non détecté pendant des jours. Si ce changement introduit une vulnérabilité de sécurité ou casse une dépendance, vous le découvrirez difficilement lors du prochain incident.

Comment fonctionne la détection automatique de la dérive

La détection automatique de la dérive suit un principe simple : exécuter une comparaison entre l'état réel de votre infrastructure et vos définitions IaC selon un calendrier régulier. Ce processus s'appelle un scan de dérive. Un scan de dérive ne modifie rien. Il trouve seulement les différences et les signale.

L'approche la plus courante utilise les mêmes outils que vous utilisez déjà pour gérer l'infrastructure. Terraform, par exemple, a une commande plan qui compare votre fichier d'état avec les ressources cloud réelles. Votre fichier d'état est un enregistrement que Terraform conserve localement ou à distance, stockant les ressources créées et leur configuration actuelle. Lorsque vous exécutez terraform plan sans modifier le code, l'outil vérifie si le fichier d'état correspond à ce qui existe réellement dans le cloud. Si quelqu'un a modifié une ressource directement dans la console, le plan affichera cela comme un changement que Terraform souhaite effectuer.

C'est le fondement de la détection de dérive : exécuter plan périodiquement et vérifier les changements inattendus.

Voici un script bash minimal qui exécute un scan de dérive et alerte votre équipe en cas de dérive détectée :

#!/bin/bash
# drift-scan.sh - Exécute un scan de dérive Terraform et notifie en cas de changements

set -euo pipefail

cd /chemin/vers/projet/terraform

terraform init -input=false

# Rafraîchir l'état depuis les ressources live, puis planifier avec code de sortie détaillé
terraform plan -refresh-only -detailed-exitcode -out=drift.tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
    # Le code de sortie 2 signifie qu'il y a des changements (dérive détectée)
    echo "Dérive détectée à $(date)"
    
    # Générer un résumé lisible
    terraform show drift.tfplan > drift-summary.txt
    
    # Envoyer une notification à Slack (ajuster l'URL du webhook)
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"🚨 Dérive détectée en production !\n$(cat drift-summary.txt)\"}" \
        https://hooks.slack.com/services/VOTRE/WEBHOOK/URL
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
    echo "Erreur lors de l'exécution du plan"
    exit 1
else
    echo "Aucune dérive détectée"
fi

Ce script peut être déclenché par une tâche cron ou un pipeline CI/CD planifié pour s'exécuter toutes les quelques heures.

Le diagramme suivant montre le cycle complet de détection de dérive :

flowchart TD A[Code IaC<br/>État souhaité] -->|terraform apply| B[Ressources Cloud<br/>État réel] B -->|Modification manuelle dans la console| C[Ressource dérivée] C -->|Plan ou rafraîchissement programmé| D{Dérive détectée ?} D -->|Oui| E[Notification<br/>Slack ou Email] D -->|Non| B E --> F{Décision de réponse} F -->|Réconcilier| G[terraform apply annule la modification] F -->|Accepter| H[Mettre à jour le code IaC pour correspondre à l'état réel] G --> B H --> A

Au-delà du plan de base : obtenir des résultats précis

Il y a un détail subtil mais important ici. Un terraform plan standard compare le fichier d'état avec les ressources réelles. Mais que faire si le fichier d'état lui-même est obsolète ? Si quelqu'un a effectué une modification dans la console, le fichier d'état pourrait ne pas la refléter. Le plan ne détecterait pas la dérive car il compare deux choses qui sont toutes deux désynchronisées.

Certains outils gèrent mieux cela. Terraform Cloud et OpenTofu offrent une détection de dérive plus poussée. Au lieu de simplement comparer l'état aux ressources, ils rafraîchissent d'abord l'état en extrayant la configuration réelle du cloud, puis comparent cet état rafraîchi avec votre code. Cela vous donne une comparaison du code aux ressources réelles, et non de l'état aux ressources. Le résultat est plus précis car il détecte les changements survenus en dehors du fichier d'état.

Cette distinction est importante. Si vous vous fiez uniquement à la sortie du plan de base, vous pourriez manquer une dérive introduite avant la dernière mise à jour du fichier d'état. Un scan de dérive approprié doit toujours commencer par rafraîchir l'état à partir de l'environnement live.

Planification et notification

Un scan de dérive doit s'exécuter selon un calendrier. La fréquence dépend de la fréquence à laquelle les changements se produisent en dehors de votre pipeline. Les équipes qui gèrent une infrastructure de production critique exécutent souvent des scans toutes les quelques heures. Les équipes avec moins d'activité peuvent les exécuter une fois par jour. La clé est la cohérence : le scan doit s'exécuter automatiquement sans intervention humaine.

Vous pouvez planifier les scans à l'aide d'une tâche cron sur votre serveur CI/CD, d'un déclencheur de pipeline planifié ou d'un planificateur intégré de votre outil IaC. L'important est que le calendrier soit fiable et ne dépende pas de quelqu'un qui se souvienne de l'exécuter.

Lorsque la dérive est détectée, l'étape suivante est la notification. Les alertes automatisées doivent être envoyées sur le canal de communication de votre équipe, que ce soit Slack, email ou un système de ticketing. Une bonne notification comprend trois éléments : quelle ressource a dérivé, ce qui a changé et quand cela a été détecté. Si votre fournisseur cloud journalise qui a effectué la modification, incluez également cette information. Cela accélère considérablement l'investigation.

Que faire après la détection

Trouver la dérive n'est que la première étape. Une fois que vous savez qu'elle existe, vous avez deux options.

La première option est la réconciliation : ramener la ressource à l'état défini dans votre code. C'est la réponse par défaut pour la plupart des équipes. Vous exécutez terraform apply ou votre équivalent, et l'outil annule la modification manuelle. Cela fonctionne bien lorsque la dérive était accidentelle ou non autorisée.

La deuxième option est l'acceptation : la modification manuelle était intentionnelle et doit rester. Dans ce cas, vous mettez à jour votre code IaC pour correspondre à l'état réel. C'est le bon choix lorsque la modification était un correctif légitime effectué rapidement dans la console et que le code doit rattraper son retard. Le danger est que si vous faites cela trop souvent, votre code cesse d'être la source de vérité et devient un enregistrement historique.

La décision entre la réconciliation et l'acceptation dépend de la politique de votre équipe. Certaines équipes réconcilient toujours, sauf exception documentée. D'autres autorisent l'acceptation mais exigent une pull request de suivi dans un délai défini. Ce qui compte, c'est que la décision soit délibérée, pas accidentelle.

Liste de contrôle pratique pour la détection automatique de la dérive

Si vous mettez en place la détection de dérive pour la première fois, voici une courte liste de contrôle pour commencer :

  • Choisissez votre outil de détection : Utilisez la détection de dérive intégrée de votre outil IaC existant ou un outil dédié comme Terraform Cloud, OpenTofu, ou un script personnalisé qui exécute plan périodiquement.
  • Définissez un calendrier de scan : Commencez par une fois par jour pour les environnements non critiques et toutes les quelques heures pour la production. Ajustez en fonction de la fréquence des modifications manuelles.
  • Configurez les notifications : Envoyez des alertes sur le chat de votre équipe ou votre système de ticketing. Incluez le nom de la ressource, le changement spécifique et l'horodatage.
  • Définissez une politique de réponse : Décidez si vous devez réconcilier ou accepter la dérive. Documentez le processus pour que toute l'équipe suive la même approche.
  • Testez le processus : Introduisez une modification manuelle délibérée dans un environnement de staging, laissez le scan la détecter, et vérifiez que la notification et la réponse fonctionnent comme prévu.

L'essentiel à retenir

La dérive d'infrastructure n'est pas le signe d'une mauvaise équipe. C'est le signe que votre équipe va vite et prend parfois des raccourcis. Le problème n'est pas le raccourci en lui-même. Le problème est de ne pas le savoir jusqu'à ce qu'il provoque un incident.

La détection automatique de la dérive transforme un problème invisible en un problème visible. Elle n'empêche pas les gens de faire des modifications dans la console. Elle garantit que lorsqu'ils le font, le reste de l'équipe le découvre rapidement et peut décider de la marche à suivre. Cette visibilité est ce qui maintient votre infrastructure fiable, même lorsque le code et le cloud ne sont pas d'accord.