Quand l'infrastructure est le produit : gouvernance IaC et détection de dérive

Imaginez que vous êtes responsable de centaines, voire de milliers de serveurs répartis sur plusieurs fournisseurs cloud et régions. Votre entreprise pourrait être un fournisseur de services cloud, une grande plateforme e-commerce ou une entreprise technologique avec une infrastructure déployée simultanément à Singapour, Francfort et en Virginie.

Dans cet environnement, l'infrastructure n'est pas simplement l'endroit où les applications s'exécutent. L'infrastructure est le produit. Chaque modification de configuration – ajout d'une règle de pare-feu, redimensionnement d'une instance de base de données, ajustement d'un paramètre de répartiteur de charge – peut affecter des dizaines de services à la fois. Une mauvaise configuration ne casse pas une seule application. Elle casse des centaines de services qui dépendent de cette infrastructure partagée.

C'est un monde différent du déploiement d'une application web unique. Les enjeux sont plus élevés, le rayon d'explosion est plus large et la marge d'erreur est quasi nulle.

Le problème de cohérence qui mène à l'IaC

Lorsque l'infrastructure est gérée manuellement via des sessions SSH ou des tableaux de bord cloud, les incohérences s'installent rapidement. Votre environnement de staging a des règles de pare-feu légèrement différentes de celles de la production. Votre configuration de production en Asie diffère de celle en Europe. Personne ne peut dire avec certitude quelle configuration est réellement en cours d'exécution.

C'est le moment où les équipes se tournent vers l'Infrastructure as Code (IaC). Vous écrivez toute la configuration de l'infrastructure sous forme de code, vous la stockez dans Git et vous l'appliquez automatiquement via des pipelines. Terraform, Pulumi, AWS CDK ou CloudFormation deviennent vos outils principaux. Chaque serveur, règle réseau et bucket de stockage est défini dans le contrôle de version.

Mais écrire la configuration sous forme de code n'est que la première étape. Une fois que votre infrastructure vit dans le code, une nouvelle question émerge : « Comment s'assurer que chaque changement respecte nos politiques avant d'atteindre la production ? »

Gouvernance IaC : politique automatisée, pas bureaucratie

La gouvernance semble être un mot qui ralentit les choses. En pratique, la gouvernance IaC est tout le contraire. Ce sont des garde-fous automatisés qui vérifient chaque changement avant qu'il n'atteigne la production, sans qu'un humain ait besoin de lire chaque ligne de configuration.

Voici comment cela fonctionne en pratique. Votre équipe de sécurité décide que tous les buckets de stockage doivent être chiffrés. Votre équipe de conformité exige que toutes les instances de base de données utilisent un type d'instance spécifique. Votre équipe réseau exige qu'aucune règle de pare-feu n'ouvre les ports 22 ou 3306 à Internet public.

Le diagramme suivant illustre le pipeline de gouvernance automatisé, du commit de code au déploiement et à la détection de dérive :

flowchart TD A[Commit du code IaC] --> B[Exécution des vérifications de politique] B --> C{Politique respectée ?} C -->|Oui| D[Déploiement vers l'infrastructure] C -->|Non| E[Blocage du changement et notification] E --> A D --> F[Surveillance de la dérive] F --> G{Dérive détectée ?} G -->|Non| H[Infrastructure stable] G -->|Oui| I[Alerte de l'équipe] I --> J[Correction automatique ?] J -->|Oui| K[Reconcilier avec l'état du code] J -->|Non| L[Révision manuelle] K --> F L --> M[Mise à jour du code ou acceptation de la dérive] M --> A

Ces règles sont écrites sous forme de politiques automatisées qui s'exécutent dans votre pipeline CI/CD. Lorsque quelqu'un soumet une pull request qui modifie le code de l'infrastructure, le pipeline ne se contente pas d'appliquer le changement. Il vérifie d'abord chaque ressource par rapport à vos politiques. Si un changement viole une politique, le pipeline échoue. Le changement n'atteint jamais la production.

Par exemple, voici une règle Open Policy Agent (OPA) simple qui applique une norme de balisage, exigeant que chaque ressource ait une balise cost-center :

package terraform

# Refuser toute ressource sans balise 'cost-center'
violation[msg] {
  resource := input.resource_changes[_]
  resource.type in ["aws_s3_bucket", "aws_instance", "aws_db_instance"]
  not resource.change.after.tags.cost-center
  msg := sprintf("%v %v ne possède pas la balise obligatoire 'cost-center'", [resource.type, resource.address])
}

Lorsque cette politique s'exécute dans votre pipeline CI/CD, toute modification de ressource dépourvue de la balise requise entraînera l'échec du pipeline, empêchant ainsi l'infrastructure mal configurée d'atteindre la production.

Il ne s'agit pas d'ajouter des étapes d'approbation pour le contrôle. Il s'agit de détecter les problèmes avant qu'ils ne deviennent des incidents. Un bucket de stockage mal configuré et accessible publiquement ne devient pas une fuite de données. Une instance de base de données trop petite ne provoque pas de panne de performance. La politique les détecte dans le pipeline, et l'équipe les corrige avant même qu'ils ne s'exécutent.

Dérive : quand la réalité diverge du code

L'IaC vous donne une source de vérité unique pour votre infrastructure. Mais cette vérité ne tient que si ce qui est réellement en cours d'exécution correspond à ce qui se trouve dans votre code. En pratique, cet alignement se brise constamment.

La dérive se produit lorsque la configuration réelle de l'infrastructure diffère de celle définie dans votre code IaC. Quelqu'un se connecte au tableau de bord cloud lors d'un incident et modifie manuellement une règle de groupe de sécurité. Un membre de l'équipe ajoute un écouteur de répartiteur de charge directement via la console parce qu'il en avait besoin de toute urgence. Un processus automatisé d'une autre équipe modifie une ressource sans passer par votre pipeline.

La dérive est dangereuse car elle rend votre IaC peu fiable. Si votre code indique qu'un serveur a la configuration A, mais que la réalité a la configuration B, alors la récupération, la mise à l'échelle ou la création d'un nouvel environnement produiront des résultats inattendus. Vous ne pouvez pas reconstruire l'infrastructure à partir du code si le code ne correspond pas à la réalité.

La détection de dérive résout ce problème en comparant périodiquement l'état réel de votre infrastructure à votre code. Le pipeline exécute les mêmes commandes qu'il utilise pour appliquer l'infrastructure, mais en mode « plan » ou « preview ». Il ne change rien. Il compare simplement. Lorsqu'il trouve des différences, il les signale.

Certaines équipes vont plus loin. Lorsqu'une dérive est détectée, le pipeline peut automatiquement reconcilier l'infrastructure vers l'état défini par le code. D'autres préfèrent notifier l'équipe responsable et la laisser décider de mettre à jour le code ou d'accepter la dérive comme intentionnelle.

Gestion des changements à haut risque

Certains changements d'infrastructure comportent plus de risques que d'autres. Modifier la configuration d'une base de données de production, changer une règle de pare-feu qui affecte le trafic principal, ou altérer un répartiteur de charge qui sert des millions de requêtes – ces changements nécessitent une attention particulière.

Pour ces changements, vous avez besoin de plus que des politiques automatisées. Vous avez besoin de processus d'approbation intégrés qui se déroulent à l'intérieur du pipeline, pas à l'extérieur. Le flux de travail ressemble à ceci :

  1. Un développeur crée une pull request avec le changement d'infrastructure.
  2. Les politiques automatisées s'exécutent et vérifient les violations.
  3. Si les politiques sont respectées, le pipeline notifie les réviseurs concernés – peut-être un DBA pour les changements de base de données, ou un ingénieur réseau pour les changements de pare-feu.
  4. Les réviseurs approuvent ou demandent des modifications directement dans la pull request.
  5. Ce n'est qu'après toutes les approbations que le changement est appliqué.

Le point clé est que l'approbation ne signifie pas ralentir. Cela signifie que les bonnes personnes examinent les bons changements au bon moment, avec tout le contexte disponible dans le pipeline. Pas de course après les gens sur le chat. Pas d'approbations de dernière minute avant la fermeture d'une fenêtre de release.

Liste de contrôle pratique pour la gouvernance IaC

  • Écrivez des politiques automatisées pour chaque règle de sécurité et de conformité applicable à votre infrastructure
  • Exécutez les vérifications de politique dans votre pipeline avant d'appliquer tout changement d'infrastructure
  • Mettez en place une détection de dérive planifiée (quotidienne ou hebdomadaire selon votre tolérance au risque)
  • Décidez si vous souhaitez corriger automatiquement la dérive ou notifier l'équipe
  • Définissez les changements qui nécessitent une approbation supplémentaire et qui sont les approbateurs
  • Faites de l'approbation une partie intégrante du pipeline, pas un processus séparé en dehors

L'essentiel à retenir

Lorsque l'infrastructure est votre produit, la cohérence et le contrôle ne sont pas optionnels. L'IaC vous donne les fondations, mais la gouvernance et la détection de dérive transforment ces fondations en quelque chose en quoi vous pouvez avoir confiance. Les politiques automatisées détectent les problèmes avant qu'ils n'atteignent la production. La détection de dérive vous indique quand la réalité a divergé de votre code. Et les approbations intégrées garantissent que les changements à haut risque reçoivent l'attention appropriée sans devenir des goulots d'étranglement.

L'objectif n'est pas de ralentir les changements d'infrastructure. C'est de les rendre suffisamment sûrs pour que vous puissiez aller vite sans crainte.