Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Policy-as-Code Enforcement

devsecops

Définition

Policy-as-Code Enforcement désigne la pratique d'exprimer les politiques de sécurité, de conformité, et de gouvernance sous forme de code (versionnable, testable, et déployable) plutôt que sous forme de documents Word ou de checklists manuelles, et d'appliquer ces politiques de manière automatisée dans les pipelines CI/CD et les environnements d'exécution. Cette approche transforme les politiques de sécurité en contrôles coercitifs automatisés, éliminant la dépendance à la discipline humaine pour leur application. Les outils de Policy-as-Code les plus répandus sont OPA (Open Policy Agent) avec le langage Rego, Kyverno (policies Kubernetes en YAML natif), AWS SCP (Service Control Policies pour la gouvernance des comptes AWS), HashiCorp Sentinel (politiques pour Terraform), et Checkov/Terrascan (politiques IaC prépackagées pour Terraform, CloudFormation, Kubernetes). Chaque outil cible un contexte d'application différent mais partage la philosophie commune : les politiques sont du code, versionnées comme le code applicatif, testées comme le code applicatif. L'application des politiques peut se faire à différents points du cycle DevOps. Dans les pipelines CI (shift-left) : les politiques IaC (Checkov, Terrascan) vérifient les fichiers Terraform/Kubernetes avant déploiement — une instance EC2 sans chiffrement EBS ou un Pod Kubernetes sans PodSecurityContext bloquent le pipeline. À l'admission Kubernetes (runtime) : les politiques OPA/Kyverno/Kyverno sont évaluées par le Kubernetes Admission Controller pour chaque ressource créée ou modifiée — un Pod sans resource limits, sans labels obligatoires, ou avec une image non signée est rejeté. Dans les environnements cloud (post-déploiement) : AWS Config Rules, Azure Policy, GCP Organization Policies détectent les ressources non conformes aux politiques et déclenchent des alertes ou des remédiation automatiques. La gouvernance du Policy-as-Code lui-même est essentielle : les politiques doivent être versionnées dans Git avec les mêmes processus de revue de code que le code applicatif, testées unitairement (OPA Unit Testing, Kyverno test), et documentées pour que les équipes comprennent pourquoi une politique existe (et non juste qu'elle existe).

OPA et Rego pour les politiques Kubernetes

OPA (Open Policy Agent) avec Gatekeeper est un admission controller Kubernetes permettant des politiques exprimées en Rego. Exemple : une politique interdisant les images de registres non approuvés (package kubernetes.admission; deny[msg] { image := input.review.object.spec.containers[_].image; not startswith(image, "ghcr.io/myorg/"); msg := sprintf("image non autorisée : %v", [image])}). La politique est versionnée dans un ConstraintTemplate CRD et s'applique automatiquement à tout Pod créé dans le cluster.

Kyverno : Policy-as-Code en YAML natif Kubernetes

Kyverno est une alternative à OPA+Gatekeeper qui utilise la syntaxe YAML Kubernetes nativement pour définir les politiques, sans Rego. Exemple de politique requérant des resource limits sur tous les containers : ClusterPolicy avec un validate rule vérifiant que containers[].resources.limits.cpu et containers[].resources.limits.memory sont définis. Kyverno peut aussi générer des ressources (générer automatiquement une NetworkPolicy pour tout nouveau Namespace) et muter des ressources (ajouter des labels manquants automatiquement).

Tests unitaires des politiques

Les politiques Policy-as-Code doivent être testées comme du code : OPA Unit Testing permet d'écrire des tests en Rego (package kubernetes.admission_test; test_deny_disallowed_registry { deny[_] with input as {...}}) et de les exécuter avec opa test policies/. Kyverno propose kyverno test ./policies/ avec des test cases YAML. Ces tests garantissent que les politiques fonctionnent comme prévu avant leur déploiement et préviennent les régressions lors des modifications. Un pipeline CI dédié aux politiques (lint Rego, tests unitaires, intégration tests) traite les politiques avec la même rigueur que le code applicatif.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis