Où exécuter les politiques d'infrastructure : Plan, Apply et Post-Déploiement

Vous avez rédigé vos politiques d'infrastructure sous forme de code. Elles vérifient les violations de sécurité, les dépassements de coûts et les conventions de nommage. Maintenant se pose la question pratique : où, dans votre pipeline, ces politiques doivent-elles réellement s'exécuter ?

La réponse n'est pas un seul endroit. Il y en a trois. Chaque emplacement détecte un type de problème différent, et en sauter un laisse des failles dans vos garde-fous.

Politique au moment du Plan : anticiper les problèmes avant qu'ils ne surviennent

Le premier endroit pour exécuter les politiques est la phase de planification. Dans des outils comme Terraform, Pulumi ou OpenTofu, la phase de planification calcule les modifications qui seraient apportées à votre infrastructure. Elle affiche un diff : les ressources à créer, modifier ou supprimer. Mais rien n'a encore changé concrètement.

Exécuter les politiques ici agit comme un filtre précoce. Le moteur de politique inspecte les modifications planifiées et décide si elles sont autorisées. Si un développeur tente d'ouvrir un groupe de sécurité à 0.0.0.0/0, la politique le bloque au moment du plan. Si quelqu'un sélectionne un type d'instance coûteux qui dépasse votre seuil budgétaire, la politique le signale. Si un nom de ressource ne respecte pas votre convention de nommage, la politique le rejette.

L'avantage est évident : vous empêchez les violations avant qu'aucune ressource n'existe. Le pipeline s'arrête, le développeur reçoit un message clair sur ce qui a été bloqué et pourquoi, et il peut corriger le code sans avoir à nettoyer des ressources déjà créées. Pas de rollback nécessaire. Pas de ressources orphelines. Pas de fenêtre d'exposition de sécurité.

Voici un exemple concret utilisant Open Policy Agent (OPA) pour appliquer une politique qui bloque les groupes de sécurité publics au moment du plan :

# Générer un plan Terraform et le convertir en JSON
export TF_VAR_region="us-east-1"
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json

# Évaluer la politique : refuser si un groupe de sécurité a une règle d'entrée 0.0.0.0/0
# policy.rego contient : deny[msg] { ... }
opa eval --data policy.rego --input plan.json "data.terraform.deny"

# Si la sortie contient un message de refus, faire échouer le pipeline
if opa eval --data policy.rego --input plan.json "data.terraform.deny" | grep -q '"result"'; then
  echo "VIOLATION DE POLITIQUE : Groupe de sécurité public détecté. Déploiement bloqué."
  exit 1
fi

C'est l'endroit le plus efficace pour appliquer les politiques. Cela fait gagner du temps, réduit le gaspillage et maintient votre infrastructure propre dès le départ.

Politique au moment de l'Apply : la dernière ligne de défense

Le deuxième endroit pour exécuter les politiques est la phase d'application (apply). L'apply est le moment où les modifications impactent réellement votre infrastructure. Les ressources sont créées, modifiées ou supprimées pour de bon.

Pourquoi exécuter à nouveau les politiques si vous avez déjà vérifié au moment du plan ? Parce que les vérifications au moment du plan ont des angles morts. Elles ne voient que ce qui est dans le code. Elles ne peuvent pas voir l'état réel de votre infrastructure, qui peut avoir dérivé en dehors du pipeline. Quelqu'un a peut-être modifié une ressource manuellement via la console. Un déploiement précédent a peut-être laissé les choses dans un état inattendu. Le plan suppose un point de départ certain, mais la réalité peut être différente.

La politique au moment de l'apply revalide avant que les modifications ne s'exécutent. Elle détecte les cas où le plan semblait correct mais où l'état réel de l'infrastructure provoquerait une violation. Elle gère également les scénarios où les modifications proviennent entièrement de l'extérieur du pipeline. Si quelqu'un exécute un terraform apply manuel depuis son ordinateur portable, la politique au moment de l'apply s'active quand même.

Un autre cas d'usage important est celui des portes d'approbation. Au moment du plan, une politique peut détecter une violation et la signaler. Mais la décision de continuer ou de s'arrêter intervient souvent au moment de l'apply. Peut-être que la violation nécessite l'approbation d'un ingénieur senior pour une exception. Peut-être que le changement est à haut risque et nécessite une vérification par une deuxième personne. Les politiques au moment de l'apply peuvent imposer ces flux de travail.

Considérez les politiques au moment du plan comme de la prévention et les politiques au moment de l'apply comme de la vérification. Les deux sont nécessaires.

Politique après le déploiement : détecter la dérive et les violations silencieuses

Le troisième endroit pour exécuter les politiques est une fois que les ressources sont déjà en cours d'exécution. C'est le contrôle post-déploiement, et il sert un objectif différent.

Les politiques de plan et d'apply détectent les violations au moment du changement. Mais l'infrastructure ne reste pas statique. Une personne ayant accès à la console peut modifier une règle de groupe de sécurité après le déploiement. Une nouvelle exigence de conformité peut rendre des ressources auparavant acceptables non conformes. Des ressources censées être temporaires peuvent encore être en cours d'exécution des mois plus tard, ce qui coûte de l'argent.

Les politiques post-déploiement s'exécutent selon un planning. Toutes les heures, tous les soirs ou toutes les semaines, elles analysent votre infrastructure en direct et la comparent à vos règles de politique. Toute ressource qui enfreint une règle est signalée. Le rapport est envoyé sur Slack, par e-mail ou sur un tableau de bord. L'équipe corrige ensuite la violation ou supprime la ressource.

C'est ainsi que vous détectez la dérive de configuration. C'est aussi ainsi que vous appliquez des politiques qui ne peuvent pas être vérifiées au moment du plan ou de l'apply. Par exemple, une politique qui dit "aucune ressource ne doit être plus ancienne que 90 jours sans révision" ne peut être appliquée qu'en analysant périodiquement les ressources en cours d'exécution.

Les politiques post-déploiement transforment la conformité d'un contrôle ponctuel en une pratique continue. Sans elles, votre infrastructure s'éloigne lentement de vos normes, et personne ne le remarque jusqu'au prochain audit.

Comment les trois points fonctionnent ensemble

Chaque point couvre ce que les autres manquent. Les politiques au moment du plan empêchent les violations avant qu'elles ne se produisent. Les politiques au moment de l'apply détectent ce que le plan a manqué et appliquent les flux d'approbation. Les politiques post-déploiement détectent la dérive et les problèmes à long terme.

Le diagramme ci-dessous montre comment les trois points de contrôle de politique s'intègrent dans un pipeline d'infrastructure typique :

flowchart TD A[Commit de code] --> B[Phase de Plan] B --> C{Contrôle de politique au moment du Plan} C -->|Réussi| D[Phase d'Apply] C -->|Échoué| E[Bloquer et notifier le développeur] E --> A D --> F{Contrôle de politique au moment de l'Apply} F -->|Réussi| G[Ressources créées/modifiées] F -->|Échoué| H[Bloquer et demander une approbation] H --> D G --> I[Analyse de politique post-déploiement] I -->|Conforme| J[Surveiller en continu] I -->|Dérive détectée| K[Alerter l'équipe et corriger] K --> G

Si vous n'exécutez les politiques qu'au moment du plan, les modifications manuelles contournent vos règles. Si vous n'exécutez les politiques qu'au moment de l'apply, vous créez quand même des ressources qui violent la politique avant que la vérification ne s'exécute. Si vous n'exécutez les politiques qu'après le déploiement, vous réagissez toujours aux problèmes au lieu de les prévenir.

Les trois sont nécessaires pour un système de garde-fou complet.

Liste de contrôle pratique

Voici une référence rapide pour configurer les points d'exécution des politiques dans votre pipeline :

  • Étape Plan : Exécutez les politiques sur le diff planifié. Bloquez les modifications qui violent les règles de sécurité, de coût ou de nommage. Faites échouer le pipeline tôt.
  • Étape Apply : Exécutez à nouveau les politiques avant d'exécuter les modifications. Détectez la dérive et imposez une approbation manuelle pour les modifications à haut risque.
  • Post-déploiement : Planifiez des analyses périodiques des politiques sur l'infrastructure en direct. Signalez les violations à l'équipe. Corrigez ou supprimez les ressources non conformes.

L'essentiel à retenir

Exécuter les politiques à un seul endroit ne suffit pas. Les vérifications au moment du plan empêchent les problèmes avant qu'ils ne commencent. Les vérifications au moment de l'apply détectent ce qui passe à travers les mailles du filet. Les vérifications post-déploiement maintiennent votre infrastructure honnête dans le temps. Intégrez les trois dans votre pipeline, et vos politiques protégeront réellement votre infrastructure au lieu de vous donner une fausse impression de sécurité.