Policy as Code : Maîtriser les Changements d'Infrastructure

Vous avez trois environnements : développement, recette et production. Chacun est géré via l'infrastructure as code. Le pipeline s'exécute, les plans sont bons, les changements sont appliqués. Mais un jour, quelqu'un crée une ressource dans la mauvaise région. Une autre fois, une ressource cloud est déployée sans le tag obligatoire cost-center. Personne ne s'en aperçoit jusqu'à l'arrivée de la facture.

Des environnements séparés résolvent le problème de tester les changements avant qu'ils n'atteignent la production. Mais ils ne résolvent pas le problème des personnes qui effectuent des changements violant les règles organisationnelles. Vous avez besoin de quelque chose qui applique ces règles automatiquement, pas juste d'un document que personne ne lit.

Pourquoi les Règles Manuelles ne Fonctionnent Pas

La plupart des équipes ont des politiques écrites quelque part. Une page wiki indique que toutes les ressources doivent avoir un tag environment. Un message Slack dit que les ressources de production vont uniquement dans ap-southeast-1. Une décision de réunion stipule que tout changement de règle de pare-feu nécessite l'approbation de l'équipe sécurité.

Ces règles existent, mais elles reposent sur la mémoire humaine et les bonnes intentions. Les gens oublient. Les nouveaux membres de l'équipe ignorent l'existence du wiki. Les changements urgents contournent le processus de relecture. Et quand quelque chose tourne mal, vous n'avez aucun moyen de prouver si la règle a été respectée ou non.

La gouvernance manuelle crée des frictions sans apporter de sécurité. Les règles sont là, mais elles ne sont appliquées qu'après que les dégâts sont faits.

Policy as Code : Des Règles qui s'Exécutent dans le Pipeline

Une politique est une règle que tout changement d'infrastructure doit suivre. La gouvernance est la manière dont vous vous assurez que ces règles sont effectivement respectées. Lorsque vous écrivez les deux sous forme de code et les exécutez dans votre pipeline, vous obtenez ce qu'on appelle le Policy as Code.

L'idée est simple : au lieu d'avoir des règles dans un document, vous les écrivez comme des contrôles exécutables qui s'exécutent avant que tout changement ne soit appliqué. Le pipeline évalue le changement proposé par rapport à vos politiques. Si une politique est violée, le pipeline s'arrête et signale exactement ce qui ne va pas.

Voici une politique Sentinel simple qui impose un tag environment sur chaque ressource :

# Exiger que chaque ressource ait un tag "environment"
mandatory_tag = rule {
  all tfplan.resources as _, resource {
    resource.applied.tags contains "environment"
  }
}

main = rule {
  mandatory_tag
}

C'est le même principe que l'infrastructure as code. Vous traitez vos règles de la même manière que vos définitions d'infrastructure. Elles vivent dans un dépôt, sont relues, testées et appliquées de manière cohérente.

Politiques Courantes que Vous Pouvez Appliquer

Les exigences de tagging sont le point de départ le plus courant. De nombreuses organisations exigent que chaque ressource cloud ait des tags comme environment, owner ou cost-center. Sans application, vous obtenez des tags incohérents, manquants ou avec des fautes de frappe. Avec le Policy as Code, le pipeline vérifie la sortie du plan et rejette toute ressource qui ne respecte pas les règles de tagging.

Les restrictions de région sont une autre politique fréquente. Si votre organisation a décidé que les charges de travail de production ne s'exécutent que dans des régions spécifiques, le pipeline doit l'appliquer. Un développeur pourrait accidentellement cibler une région différente lors d'un déploiement tardif. La politique l'attrape avant qu'aucune ressource ne soit créée.

Les workflows d'approbation peuvent également être intégrés dans la politique. Tous les changements n'ont pas le même risque. Modifier une règle de pare-feu en recette peut nécessiter un relecteur. Modifier la même règle en production peut nécessiter l'approbation de l'équipe sécurité. Le pipeline peut vérifier l'environnement, le type de ressource et la portée du changement pour déterminer le chemin d'approbation requis.

Comment ça Fonctionne en Pratique

Le flux typique ressemble à ceci. Après la génération du plan d'infrastructure et avant l'étape d'application, le pipeline exécute des contrôles de politique. Ces contrôles lisent la sortie du plan et l'évaluent par rapport à vos règles.

Voici une représentation visuelle de ce flux :

flowchart TD A[Commit de code] --> B[Générer le plan] B --> C{Contrôle de politique} C -- Succès --> D[Appliquer le changement] C -- Échec --> E[Bloquer le pipeline] E --> F[Afficher l'erreur : Règle, Ressource, Valeur attendue] D --> G[Déploiement terminé]

Vous pouvez utiliser des outils dédiés comme Open Policy Agent (OPA) ou Sentinel pour des politiques complexes. Ou vous pouvez écrire des scripts simples qui analysent le plan et vérifient des conditions spécifiques. L'outil importe moins que le principe : le contrôle doit être automatique, cohérent et bloquant.

Si une violation de politique est détectée, le pipeline s'arrête. La sortie montre exactement quelle règle a été violée, quelle ressource l'a déclenchée et quelle devrait être la valeur attendue. Le développeur reçoit un retour immédiat, pas un ticket qui arrive trois jours plus tard.

Les Exceptions Font Partie du Système

Les politiques ne doivent pas être des barrières absolues. Il existe des raisons légitimes de faire des exceptions. Un nouveau besoin métier peut nécessiter des ressources dans une région qui n'était pas approuvée auparavant. Un correctif d'urgence peut devoir contourner les règles de tagging normales.

La clé est de rendre les exceptions visibles et documentées. Au lieu que quelqu'un contourne silencieusement la politique, il soumet une demande d'exception. La demande passe par un processus d'approbation, et l'exception approuvée est enregistrée dans la piste d'audit. Le pipeline peut même vérifier les exceptions approuvées et autoriser le changement à se poursuivre.

Cela transforme les exceptions de processus cachés en décisions documentées. Vous savez qui a approuvé quoi, quand et pourquoi. Ces informations sont précieuses pour les audits, les post-mortems et les futures révisions de politiques.

Pourquoi ça Rend les Équipes Plus Rapides

Cela semble contre-intuitif. Ajouter des contrôles automatisés à votre pipeline semble devoir ralentir les choses. Mais c'est l'inverse qui se produit.

Sans Policy as Code, chaque changement qui pourrait toucher une zone sensible nécessite une relecture manuelle. Le relecteur doit vérifier le plan, se souvenir des règles et prendre une décision. Cela prend du temps, et le relecteur peut oublier quelque chose.

Avec le Policy as Code, les contrôles de routine se font automatiquement. Le pipeline rejette les changements clairement invalides en quelques secondes. Le relecteur n'a besoin d'examiner que les changements qui nécessitent réellement un jugement humain. L'équipe va plus vite car elle n'attend pas des contrôles manuels pour des choses qui pourraient être automatisées.

Et quand quelque chose tourne mal, vous avez une piste d'audit claire. Vous savez ce qui a changé, qui l'a approuvé et quelles politiques étaient impliquées. Fini les suppositions, les accusations et les « je ne savais pas que cette règle existait ».

Une Checklist Rapide pour Commencer

Si vous envisagez le Policy as Code pour votre pipeline d'infrastructure, voici les étapes pour débuter :

  • Choisissez une politique qui cause le plus de problèmes aujourd'hui. Le tagging est généralement un bon début.
  • Écrivez la politique sous forme de script ou utilisez un outil comme OPA. Testez-la contre une violation connue.
  • Ajoutez le contrôle de politique à votre pipeline, entre les étapes de planification et d'application.
  • Exécutez-le d'abord en mode non bloquant. Enregistrez les violations mais laissez le pipeline continuer.
  • Passez en revue les violations pendant une semaine. Corrigez les faux positifs et ajustez les règles.
  • Passez en mode bloquant. Faites en sorte que le pipeline s'arrête en cas de violation.
  • Documentez le processus d'exception. Expliquez clairement comment demander une dérogation.

Ce qu'il Faut Retenir

Le Policy as Code transforme vos règles d'infrastructure de documents oubliés en gardiens automatisés. Il détecte les violations avant qu'elles n'atteignent la production, fournit des pistes d'audit claires et permet à votre équipe d'aller plus vite en automatisant les contrôles de routine. Les règles vivent dans votre dépôt, sont relues comme du code et s'exécutent à chaque exécution du pipeline. C'est une gouvernance qui fonctionne réellement, pas une gouvernance qui vit sur une page wiki que personne ne lit.