Policy as code : des règles qui bloquent avant l'apply

La policy as code transforme une règle d'équipe écrite dans un document (« tout est étiqueté », « aucun stockage public ») en un programme qui s'exécute à chaque changement et le refuse s'il la viole. La revue humaine ne peut pas relire cent lignes de plan en vérifiant chaque étiquette ; une règle codée le fait en quelques secondes, de façon identique à chaque fois. Cette leçon explique où appliquer ces règles, lesquelles choisir pour commencer, comment les traiter quand elles gênent, et où se situe l'écriture proprement dite (dans la formation Rego). Le scénario est celui de l'équipe de quatre personnes : une application web (deux VM, une base, un réseau, un DNS) en dev et prod, infrastructure en cours de passage au code.

Ce que vous allez apprendre

• définir la policy as code et dire ce qu'elle apporte à la revue humaine ;
• choisir où appliquer une règle : plan en CI, admission Kubernetes, garde-fous du cloud ;
• formuler trois règles utiles pour une petite équipe ;
• lire un extrait court de règle écrit en Rego ;
• tracer les exceptions sans qu'elles deviennent la norme.

Les extraits de code sont des illustrations à lire, pas des étapes à exécuter.

Qu'est-ce que la policy as code et à quoi sert-elle ?

La policy as code (politique sous forme de code) consiste à écrire les règles de conformité dans un langage exécutable, à les versionner dans Git et à les faire évaluer automatiquement sur chaque changement. Une règle prend une description de l'état voulu en entrée et rend un verdict : accepté ou refusé, avec un message qui dit pourquoi.

Elle apporte trois choses que la revue humaine seule n'apporte pas. D'abord la constance : la règle s'applique de la même façon à la millième pull request qu'à la première, même le vendredi soir. Ensuite l'explicite : la règle est écrite, donc discutable et modifiable par une pull request, alors qu'une habitude orale ne l'est pas. Enfin la rapidité du retour : l'auteur apprend l'erreur dans la minute, pas après trois jours d'attente de relecture.

Elle ne remplace pas la revue humaine, qui juge l'intention et l'architecture. Elle ne remplace pas non plus les tests vus dans Tests et contrôles automatiques : un test vérifie qu'un composant se comporte comme prévu, une politique vérifie qu'un changement respecte les règles de l'organisation. Elle retire de la revue ce qu'une machine fait mieux, pour laisser les relecteurs sur ce qui demande du jugement (Relire un changement IaC).

Où appliquer une règle : plan en CI, admission Kubernetes ou garde-fous du cloud ?

On peut appliquer une règle à trois endroits de la chaîne, et ils ne voient pas la même chose. La question à poser est : à quel moment est-il le moins coûteux de refuser, et qui peut contourner ? Le plus tôt possible est le plus économique ; le point le plus en aval est le plus sûr.

Point d'application	Ce qu'il évalue	Avantage	Limite
Plan en CI	Le plan JSON : ce que le changement s'apprête à créer ou modifier	Refus avant tout apply, retour à l'auteur dans la pull request	Ne voit pas ce qui est créé hors du code (console, script)
Admission Kubernetes	Chaque objet que le cluster reçoit	Refuse même ce qui n'est pas passé par la CI	Ne concerne que le cluster, pas le reste de l'infrastructure
Garde-fous du cloud	Chaque appel d'API au niveau du compte ou de l'organisation	Difficile à contourner, même par un administrateur du projet	Messages parfois peu explicites, règles moins faciles à tester

Glissez pour voir

Le plan JSON est la description structurée du plan : l'outil sait la produire en JSON, et une politique peut alors parcourir la liste des changements (ressource, type, valeurs après changement). Côté Terraform, cette liste s'appelle resource_changes. C'est le point d'application le plus accessible pour une équipe IaC. La leçon Policy as Code et governance dans HCP Terraform montre une variante hébergée de ce modèle, et Checkov un scanner prêt à l'emploi qui évite d'écrire soi-même les règles courantes.

L'admission Kubernetes est un contrôle sur l'API du cluster : avant d'enregistrer un objet, le cluster interroge un composant qui peut le refuser. Le cluster sait aussi exprimer des règles natives (ValidatingAdmissionPolicy, stable depuis Kubernetes 1.30) ; Admission Controllers Kubernetes et ValidatingAdmissionPolicy détaillent le mécanisme, Gatekeeper : Rego dans le cluster Kubernetes l'approche par Rego, et ArgoCD et admission controllers le cas GitOps.

Les garde-fous du cloud sont des règles que le fournisseur applique à l'échelle d'un compte ou d'une organisation (par exemple les politiques d'organisation ou les services de contrôle de conformité propres à chaque fournisseur). La leçon Garde-fous, héritage des politiques et étiquetage les traite côté cloud.

La bonne pratique est de cumuler, avec des rôles différents : la CI pour un retour rapide et lisible, un garde-fou du cloud comme filet de dernier recours.

Quelles règles écrire en premier ?

Une petite équipe a besoin de peu de règles, mais qui visent des risques réels. Pour le scénario, trois règles suffisent à démarrer. Chacune se formule d'abord en une phrase en français, avec son motif ; le code ne vient qu'après, quand la phrase est validée par l'équipe.

Règle en français	Pourquoi	Où elle s'évalue
Toute ressource créée porte les étiquettes environnement, equipe, projet et expire_le	Savoir à qui écrire et que supprimer ; rendre le coût attribuable (Le coût dès le code)	Plan en CI
Aucun stockage d'objets n'est accessible publiquement	Fuite de données par exposition accidentelle	Plan en CI, puis garde-fou du cloud
Les ressources ne se créent que dans les régions autorisées (par exemple en Europe)	Conformité, souveraineté, maîtrise des coûts	Garde-fou du cloud, plan en CI pour le retour rapide

Glissez pour voir

Voici ce que donne la première règle écrite en Rego, le langage de politique de l'écosystème Open Policy Agent (OPA). Les trois premières étiquettes sont celles de la formation Cloud (Garde-fous, héritage des politiques et étiquetage) ; expire_le, propre à l'IaC, donne une durée de vie (Le coût dès le code). L'extrait suivant a été évalué avec OPA 1.17.1 et Conftest sur un plan d'exemple : il refuse les ressources créées ou modifiées auxquelles il manque une étiquette. Il suppose des étiquettes en dictionnaire (cas d'AWS, {"equipe": "web"}) ; chez les fournisseurs qui les expriment en liste de chaînes ou d'objets, la version multi-fournisseurs est dans la leçon Cloud citée plus haut.

package iac.etiquettes

obligatoires := {"environnement", "equipe", "projet", "expire_le"}

deny contains msg if {
  some rc in input.resource_changes
  some action in rc.change.actions
  action in {"create", "update"}
  etiquettes := object.get(rc.change.after, "tags", {})
  manquantes := obligatoires - object.keys(etiquettes)
  count(manquantes) > 0
  msg := sprintf("%s : étiquettes manquantes %v", [rc.address, manquantes])
}

Une VM déclarée avec environnement, equipe et projet mais sans expire_le produit le message module.app.vm_app[0] : étiquettes manquantes {"expire_le"}, et la CI échoue. Cette leçon s'arrête là pour le code : apprendre à écrire, tester et appliquer ces règles, avec Conftest pour les fichiers de configuration, est l'objet de la formation Rego et de Conftest : tester ses fichiers de configuration.

Comment traiter une règle qui gêne : exceptions et mise en place progressive ?

Une règle qui bloque un travail légitime sera contournée, discrètement, si le processus ne prévoit pas de dérogation. Une exception est une autorisation explicite, limitée et tracée de ne pas appliquer une règle à une ressource précise. Sans elle, les gens désactivent la règle entière.

Une exception utile porte cinq informations : la règle concernée, la ressource visée, le motif, la personne qui l'approuve et une date d'expiration. Elle vit dans un fichier versionné, modifié par pull request, de sorte qu'on peut la relire, la justifier et la retirer. Une exception sans date devient permanente.

Pour introduire une règle, on l'avertit d'abord, puis on la bloque une fois les violations existantes traitées ou excusées ; la méthode, avec la dérogation documentée, est détaillée dans Garde-fous, héritage des politiques et étiquetage. Cette bascule est une décision d'équipe, pas un réglage technique.

Quelles erreurs fréquentes avec la policy as code ?

• Une règle qui ne s'évalue jamais. Dans certains langages de politique, une condition mal écrite ne produit pas d'erreur : la règle ne rend simplement aucun refus, et la CI reste verte. Seul un test qui doit échouer sur un cas fautif détecte ce piège.
• Trop de règles dès le départ. Cent règles que personne ne comprend déclenchent des contournements. Commencer par trois règles claires vaut mieux.
• Des messages sans explication. Un refus « règle 42 violée » ne dit pas quoi corriger. Le message doit citer la ressource et l'action attendue.
• Seul un point d'application. Une règle uniquement en CI laisse passer ce qui est créé depuis la console du fournisseur.
• Des exceptions sans date. Elles s'accumulent et la règle devient décorative.

À retenir

• La policy as code exécute les règles de l'équipe à chaque changement, avec le même verdict à chaque fois et un retour rapide.
• Trois points d'application : le plan JSON en CI, l'admission Kubernetes, les garde-fous du cloud ; on les cumule avec des rôles différents.
• Commencer par trois règles formulées en français : étiquettes obligatoires, pas de stockage public, régions autorisées.
• Une exception se trace : règle, ressource, motif, approbateur, date d'expiration, dans un fichier versionné.
• Une règle se teste avec un cas qui doit échouer ; l'écriture de ces règles relève de la formation Rego.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →