Le policy as code consiste à exprimer des exigences d’infrastructure sous forme de règles versionnées et exécutables. Pour Terraform, le contrôle le plus utile analyse le plan avant l’application, puis explique précisément pourquoi une ressource respecte ou viole une règle.

Cette approche réduit les vérifications manuelles répétitives. Elle ne remplace pas la revue d’architecture. Elle rend visibles des écarts objectifs, comme une ressource publique, une région interdite, un chiffrement absent ou des tags obligatoires manquants.

Policy as code Terraform : la règle devient un produit

Une politique utile possède un objectif, un propriétaire, des tests et un cycle de vie. Elle doit produire une décision compréhensible. Un simple « refusé » ralentit l’équipe ; un message indiquant la ressource, la règle et la correction attendue accélère la résolution.

La politique reçoit des données structurées. Avec Terraform, il s’agit souvent du plan converti en JSON. Elle retourne ensuite des violations, un avertissement ou une autorisation. Le pipeline décide enfin si le déploiement peut continuer.

Transformer les risques en règles vérifiables

Ne commencez pas par écrire cinquante règles. Listez d’abord les incidents que vous voulez empêcher. Pour chaque risque, identifiez la donnée disponible dans le plan, la sévérité, le responsable et la correction attendue.

Les premières règles devraient couvrir un petit nombre de risques importants. Une base réaliste vérifie l’exposition publique, le chiffrement, les régions autorisées, les identités trop privilégiées et les suppressions de ressources critiques.

Évitez les règles portant sur un détail sans conséquence. Chaque contrôle ajoute du coût de maintenance. S’il ne protège ni une exigence métier, ni une obligation, ni un risque d’exploitation réel, il appartient probablement à un linter ou à une convention.

Placer chaque contrôle au bon niveau

Un contrôle sur le code HCL donne un retour rapide, mais il ne voit pas toujours le résultat final des modules et variables. Un contrôle sur le plan JSON se rapproche de ce qui sera créé. Un contrôle après application confirme l’état réel.

Utilisez ces niveaux ensemble. Le poste local sert au feedback rapide. La pull request applique les contrôles reproductibles. La porte avant production traite les risques élevés. La surveillance après déploiement détecte la dérive et les propriétés impossibles à connaître au plan.

Reliez aussi les politiques au périmètre. Une règle destinée à la production ne doit pas forcément bloquer une sandbox éphémère. À l’inverse, une exception de développement ne doit jamais s’étendre implicitement aux comptes sensibles.

Si votre organisation structure encore sa chaîne IaC, notre comparaison Terraform ou Ansible en entreprise aide à séparer provisioning, configuration et contrôles associés.

OPA, Conftest, Sentinel ou règles natives

OPA évalue des règles Rego sur des données JSON. Il reste indépendant du fournisseur et peut gouverner plusieurs domaines. Conftest facilite l’exécution de règles OPA dans une chaîne CI/CD et sur différents formats de configuration.

Sentinel s’intègre à HCP Terraform et Terraform Enterprise. Ses niveaux d’application permettent d’informer, d’autoriser une dérogation tracée ou de bloquer. Les politiques Terraform natives en HCL peuvent aussi réduire la courbe d’apprentissage dans cet environnement.

Choisissez selon votre plateforme, pas selon la popularité. Une équipe déjà équipée de HCP Terraform valorisera l’intégration. Une organisation multi-outils préférera souvent OPA. Une petite équipe peut commencer avec Conftest dans son pipeline existant.

Mini-lab : contrôler un plan Terraform sans toucher au cloud

Ce test s’exécute dans un répertoire local ou un runner isolé. Il ne lance aucun apply. Utilisez un exemple sans données sensibles, un backend local et une version de Terraform validée par votre équipe.

Créez un exemple volontairement incomplet. La ressource locale évite de contacter un fournisseur cloud. Le contrôle exigera ici un tag logique owner.

terraform {
  required_version = ">= 1.6.0"
}

resource "terraform_data" "example" {
  input = {
    environment = "test"
  }
}

Initialisez le dossier, produisez un plan binaire, puis convertissez-le en JSON. Ne lancez pas l’application.

terraform init
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

Ajoutez une politique Rego minimale. Elle cherche les ressources gérées et refuse celles dont la valeur d’entrée ne contient pas de propriétaire.

package terraform.guardrails

import rego.v1

deny contains msg if {
  some rc in input.resource_changes
  rc.mode == "managed"
  not rc.change.after.input.owner
  msg := sprintf("%s : owner manquant", [rc.address])
}

Évaluez la règle sur le plan. La requête affiche la liste des refus. Le résultat attendu contient l’adresse terraform_data.example et le message indiquant que le propriétaire manque.

opa eval \
  --data policy.rego \
  --input tfplan.json \
  'data.terraform.guardrails.deny'

Ajoutez ensuite owner = "platform" dans la valeur d’entrée, régénérez le plan et relancez OPA. La liste doit devenir vide. Cette seconde exécution vérifie le chemin conforme, pas seulement l’échec attendu.

Pour nettoyer, supprimez uniquement les fichiers générés dans ce répertoire de lab. Aucun état distant et aucune ressource cloud n’ont été créés.

rm tfplan.binary tfplan.json
rm -rf .terraform .terraform.lock.hcl

Déployer les garde-fous sans arrêter les livraisons

Commencez par une période d’observation. Le pipeline publie les violations sans bloquer. Mesurez leur fréquence, les faux positifs, le temps de correction et les équipes concernées. Corrigez les règles avant d’augmenter leur niveau d’application.

Classez ensuite les décisions. Une règle informative signale une amélioration. Une règle souple autorise une dérogation approuvée. Une règle stricte arrête un risque critique, comme une exposition publique non justifiée ou la suppression d’une ressource protégée.

Déployez par périmètre. Commencez sur une sandbox, puis un projet pilote, puis la production. Conservez la version du paquet de politiques avec chaque décision. Vous pourrez ainsi expliquer pourquoi un plan ancien a été accepté.

Le retour arrière consiste à repasser une règle du mode bloquant au mode informatif, pas à supprimer toute la couche de contrôle. Protégez cette modification par une approbation et une trace d’audit.

Pour limiter les contournements, sécurisez aussi les runners. L’article sur la manière de restreindre les sorties réseau des runners CI/CD complète cette gouvernance du chemin de déploiement.

Erreurs courantes et dépannage

Surveillez également la durée des contrôles. Un pipeline trop lent pousse aux contournements. Séparez les règles rapides des analyses lourdes, mettez en cache les dépendances et exécutez les vérifications indépendantes en parallèle.

Sources officielles pour approfondir

FAQ sur le policy as code Terraform

Faire des politiques un accélérateur de confiance

Le policy as code Terraform devient utile lorsqu’il donne un retour rapide, précis et proportionné. Commencez par quelques risques importants, testez les règles comme du code et rendez chaque exception visible.

La réussite se mesure autant au nombre d’incidents évités qu’au temps nécessaire pour corriger une violation. Une règle que chacun comprend protège mieux qu’un catalogue imposant que tout le monde contourne.