Policy as Code et governance dans HCP Terraform

Un terraform plan peut être syntaxiquement correct mais proposer des changements dangereux : une instance en m5.24xlarge oubliée, une base de données sans chiffrement, un déploiement dans une région non autorisée. Le Policy as Code évalue automatiquement le plan avant l’apply pour bloquer les violations.

Ce que vous allez apprendre

• Ce qu’est le Policy as Code et pourquoi il existe
• La différence entre Sentinel et OPA (Open Policy Agent)
• La distinction entre policy checks et policy evaluations
• Comment fonctionnent les policy sets et les niveaux d’enforcement
• Comment créer et appliquer une première politique
• Les limites du free tier pour le Policy as Code

Qu’est-ce que le Policy as Code

Analogie : le contrôle qualité sur la chaîne de montage

Dans une usine, le contrôle qualité vérifie chaque produit avant l’expédition : dimensions, poids, finitions. Si un produit ne passe pas le contrôle, il est renvoyé en production. Le Policy as Code, c’est le contrôle qualité de votre infrastructure : il vérifie le plan Terraform avant l’apply et bloque les changements non conformes.

Le Policy as Code dans HCP Terraform s’insère dans le cycle de vie d’un run, entre le plan et l’apply :

Étape	Ce qui se passe
Plan	Terraform calcule les changements
Policy checks / evaluations	Les politiques évaluent le plan
Apply	Les changements sont appliqués (si les politiques passent)

Glissez pour voir

Si une politique échoue, le run est bloqué — aucun changement n’est appliqué.

Ordre exact dans le run

L’ordre d’exécution des politiques dépend du framework et du type d’évaluation :

• OPA policy evaluations : après le plan et les run tasks, avant le cost estimation.
• Sentinel policy evaluations : après le plan et les run tasks, avant le cost estimation.
• Sentinel policy checks : après le plan, les run tasks et le cost estimation.

Sentinel vs OPA

HCP Terraform supporte deux frameworks de Policy as Code :

Critère	Sentinel	OPA (Rego)
Développé par	HashiCorp (propriétaire)	CNCF (open source)
Langage	Sentinel (DSL dédié)	Rego (langage déclaratif)
Écosystème	Spécifique HashiCorp	Multi-usage (Kubernetes, CI/CD, API)
Courbe d’apprentissage	Faible (syntaxe simple)	Moyenne (Rego est particulier)
Données accessibles	Plan, state, run, organisation	Plan JSON via input
Exemples et bibliothèques	terraform-sentinel-policies (HashiCorp)	conftest, Rego Playground
Disponible en gratuit	✅ (limité)	✅ (limité)

Glissez pour voir

Quand choisir Sentinel

• Vous êtes dans un écosystème 100 % HashiCorp
• Vous voulez une syntaxe simple et lisible sans courbe d’apprentissage
• Vous avez besoin d’accéder aux données spécifiques HCP Terraform (run metadata, organization info)

Quand choisir OPA

• Vous utilisez déjà OPA pour Kubernetes (Gatekeeper) ou vos API
• Vous voulez des politiques portables entre outils
• Votre équipe maîtrise déjà Rego

Pour les labs d’apprentissage, Sentinel est le choix le plus simple.

Policy checks vs policy evaluations

C’est la distinction architecturale la plus importante à comprendre dans HCP Terraform :

Type	Frameworks supportés	Enforcement disponible
Policy checks	Sentinel uniquement	advisory, soft-mandatory, hard-mandatory
Policy evaluations	Sentinel et OPA	advisory, mandatory (les niveaux soft-mandatory et hard-mandatory sont convertis en mandatory)

Glissez pour voir

Concrètement :

• Les policies Sentinel peuvent s’exécuter comme policy checks ou comme policy evaluations, selon le type de policy set choisi.
• Les policies OPA s’exécutent uniquement comme policy evaluations.

Cette distinction affecte les niveaux d’enforcement disponibles, l’ordre d’exécution dans le run et les possibilités d’override.

En résumé

Si vous avez besoin des trois niveaux d’enforcement (advisory, soft-mandatory, hard-mandatory), vous devez utiliser Sentinel avec un policy set de type policy checks. Avec OPA ou avec Sentinel en mode policy evaluations, seuls advisory et mandatory sont disponibles.

Les niveaux d’enforcement

Les niveaux d’enforcement disponibles dépendent du type d’évaluation.

Sentinel policy checks

Niveau	Comportement si échec	Cas d’usage
Advisory	Le run continue, un avertissement est affiché	Recommandations, bonnes pratiques non bloquantes
Soft-mandatory	Le run est bloqué, mais un utilisateur autorisé peut outrepasser	Règles importantes avec exception possible
Hard-mandatory	Le run est bloqué, aucun override possible	Règles de conformité incontournables (sécurité, réglementation)

Glissez pour voir

Override et policy sets

Le comportement exact de l’override dépend aussi de la configuration du policy set : un policy set peut être configuré pour autoriser ou interdire les overrides, indépendamment du niveau d’enforcement individuel de chaque politique.

Policy evaluations (Sentinel et OPA)

En mode policy evaluations, les niveaux soft-mandatory et hard-mandatory sont convertis en mandatory :

Niveau	Comportement si échec
Advisory	Le run continue, un avertissement est affiché
Mandatory	Le run est bloqué — les utilisateurs ayant la permission Manage Policy Overrides peuvent continuer

Glissez pour voir

En pratique

Commencez par advisory pour observer l’impact de vos politiques sur les runs existants. Passez en soft-mandatory (Sentinel checks) ou mandatory (evaluations) quand l’équipe est prête. Réservez hard-mandatory (Sentinel checks uniquement) aux règles de sécurité critiques.

Policy sets

Un policy set regroupe des politiques et les applique à des workspaces ou des projects.

Structure d’un policy set

Composant	Ce qu’il fait
Policies	Les règles individuelles (fichiers .sentinel ou .rego)
Scope	Les workspaces ou projects ciblés
Enforcement	Le niveau par défaut pour les politiques du set
Source	Policies gérées dans l’UI, repository VCS ou API / provider tfe

Glissez pour voir

Créer un policy set

1. Préparez vos fichiers de politiques

   Exemple Sentinel — exiger des tags sur toutes les ressources AWS :

   enforce-tags.sentinel

   import "tfplan/v2" as tfplan
   
   mandatory_tags = ["environment", "team", "cost-center"]
   
   main = rule {
     all tfplan.resource_changes as _, rc {
       rc.type is "aws_instance" implies
         all mandatory_tags as tag {
           rc.change.after.tags contains tag
         }
     }
   }

   Exemple OPA (Rego) — limiter la taille des instances :

   restrict-instance-size.rego

   package terraform.policies
   
   deny[msg] {
     rc := input.resource_changes[_]
     rc.type == "aws_instance"
     rc.change.after.instance_type == "m5.24xlarge"
     msg := "Les instances m5.24xlarge ne sont pas autorisées"
   }

   Pour une policy OPA gérée dans l’UI, HCP Terraform demande une query qui pointe vers la règle Rego à évaluer — ici terraform.policies.deny. Le résultat de cette query doit être un tableau : la policy passe quand ce tableau est vide (aucune violation), et échoue quand il contient des messages.

2. Créez le fichier de configuration du policy set

   Pour Sentinel, créez un sentinel.hcl :

   policy "enforce-tags" {
     source            = "./enforce-tags.sentinel"
     enforcement_level = "soft-mandatory"
   }

   Pour OPA, créez un fichier policies.hcl ou utilisez l’interface web.

3. Créez le policy set dans HCP Terraform

   Dans l’interface web : Organization → Settings → Policy Sets → Connect a new policy set.

   Champ	Valeur
   Source	Policies gérées dans l’UI (pour un test) ou VCS / API (pour la production)
   Framework	Sentinel ou OPA
   Scope	Specific workspaces / Specific projects / All workspaces

   Glissez pour voir

4. Testez la politique

   Lancez un terraform plan dans un workspace ciblé. Si le plan viole la politique :

   • En advisory : le run continue avec un avertissement.
   • En soft-mandatory (Sentinel checks) : le run est bloqué, un utilisateur autorisé peut outrepasser.
   • En hard-mandatory (Sentinel checks) : le run est bloqué sans override possible.
   • En mandatory (policy evaluations) : le run est bloqué — un utilisateur avec la permission Manage Policy Overrides peut continuer.

Limites du free tier

L’édition gratuite d’HCP Terraform limite le Policy as Code à 1 policy set contenant 5 politiques maximum. Le raccordement à un dépôt VCS pour les policy sets nécessite le plan Standard ou supérieur. En free tier, vous devez uploader les politiques manuellement.

Politiques courantes

Voici des exemples de politiques fréquemment mises en place :

Politique	Ce qu’elle vérifie	Enforcement recommandé
Tags obligatoires	Toutes les ressources ont les tags requis	Soft-mandatory
Régions autorisées	Pas de déploiement hors eu-west-1, eu-central-1	Hard-mandatory
Chiffrement activé	Les volumes EBS, S3 buckets et RDS sont chiffrés	Hard-mandatory
Taille d’instance limitée	Pas d’instances *.24xlarge ou *.metal	Soft-mandatory
Pas d’adresses IP publiques	Les instances EC2 n’ont pas d’IP publique	Hard-mandatory
Coût estimé limité	Le cost estimate du plan ne dépasse pas un seuil	Advisory

Glissez pour voir

Bibliothèques de politiques

HashiCorp fournit des bibliothèques de politiques prêtes à l’emploi :

• terraform-sentinel-policies (GitHub) : collection de politiques Sentinel couvrant AWS, Azure, GCP et VMware.
• Rego Playground : testez vos politiques OPA en ligne avant de les déployer.

Workflow de gouvernance en production

En production, le cycle de vie des politiques suit un workflow structuré :

1. Développez la politique en local ou dans le Rego Playground.

2. Testez la politique en mode advisory sur un workspace de staging.

3. Observez les résultats pendant quelques jours — identifiez les faux positifs.

4. Corrigez la politique et passez en soft-mandatory (Sentinel checks) ou mandatory (policy evaluations).

5. Déployez en production en hard-mandatory (Sentinel checks uniquement) quand la confiance est établie.

Dépannage

Symptôme	Cause probable	Solution
Policy check: soft-mandatory failed	Le plan viole une politique Sentinel (checks)	Corrigez la configuration ou demandez un override à un utilisateur autorisé
Policy check: hard-mandatory failed	Le plan viole une politique bloquante (Sentinel checks)	Corrigez obligatoirement la configuration
Policy evaluation: mandatory failed	Le plan viole une policy evaluation (Sentinel ou OPA)	Corrigez la configuration ou demandez un override (permission Manage Policy Overrides)
Le policy check n’apparaît pas	Aucun policy set n’est attaché au workspace	Vérifiez le scope du policy set
Error: invalid policy lors de l’upload	Erreur de syntaxe dans le fichier .sentinel ou .rego	Validez la syntaxe en local avant l’upload
Le policy set VCS ne se met pas à jour	Connection VCS non configurée (free tier)	Uploadez manuellement ou passez au plan Standard
Faux positif sur une politique	La politique est trop stricte	Affinez les conditions ou ajoutez une exception

Glissez pour voir

À retenir

• Le Policy as Code évalue automatiquement le plan entre le plan et l’apply. C’est votre dernier rempart avant un changement non conforme.
• Sentinel (HashiCorp, syntaxe simple) et OPA (CNCF, Rego, portable) sont les deux frameworks supportés. Sentinel est plus simple pour débuter.
• Sentinel peut s’exécuter comme policy checks (3 niveaux : advisory, soft-mandatory, hard-mandatory) ou comme policy evaluations (2 niveaux : advisory, mandatory). OPA ne supporte que les policy evaluations.
• L’override d’une politique dépend du type d’évaluation et de la configuration du policy set — hard-mandatory en Sentinel checks est le seul cas sans override possible.
• En édition gratuite : 1 policy set, 5 politiques maximum, pas de VCS. Suffisant pour tester et apprendre.
• Déployez progressivement : advisory → mandatory / soft-mandatory → hard-mandatory (Sentinel checks) une fois la confiance établie.

Prochaines étapes

Créer et piloter un workspace Revenez aux bases : workspace, exécution distante, réglages.

Dynamic credentials, tfe_outputs et run triggers Credentials temporaires OIDC, partage d'état et chaînage de runs.

Variables, secrets et variable sets Centraliser les variables et les partager entre workspaces.

×

📖 Voir la documentation →