Les pipelines CI\/CD modernes avancent vite. Les \u00e9quipes d\u00e9ploient des dizaines \u2014 parfois des centaines \u2014 de mises en production par jour, et chacune de ces mises en production comporte des d\u00e9cisions de configuration qui impactent la s\u00e9curit\u00e9, la conformit\u00e9 et la stabilit\u00e9 op\u00e9rationnelle. Un seul manifeste Kubernetes mal configur\u00e9, un r\u00f4le IAM trop permissif dans Terraform, ou une image de conteneur provenant d\u2019un registre non approuv\u00e9 peut exposer l\u2019ensemble de votre infrastructure.<\/p>\n
Les revues de code manuelles ne peuvent pas suivre le rythme. M\u00eame l\u2019ing\u00e9nieur en s\u00e9curit\u00e9 le plus consciencieux manquera des \u00e9l\u00e9ments en examinant des centaines de pull requests par semaine. C\u2019est l\u00e0 qu\u2019interviennent les moteurs de politiques<\/strong> : des outils automatis\u00e9s qui \u00e9valuent l\u2019infrastructure-as-code, les manifestes de d\u00e9ploiement et les configurations de pipeline par rapport \u00e0 un ensemble d\u00e9claratif de r\u00e8gles \u2014 et bloquent les violations avant qu\u2019elles n\u2019atteignent la production.<\/p>\n Les moteurs de politiques transforment la s\u00e9curit\u00e9 d\u2019un goulot d\u2019\u00e9tranglement en garde-fou. Au lieu de ralentir les d\u00e9veloppeurs avec des portes d\u2019approbation manuelles, ils fournissent un retour instantan\u00e9 et d\u00e9terministe directement dans le pipeline CI. Un d\u00e9veloppeur pousse un plan Terraform qui accorde les permissions Mais le paysage des moteurs de politiques s\u2019est d\u00e9velopp\u00e9 rapidement, et choisir le bon \u2014 ou la bonne combinaison \u2014 n\u2019est pas simple. Dans ce guide, nous comparons quatre moteurs de politiques majeurs : Open Policy Agent (OPA)<\/strong>, Kyverno<\/strong>, HashiCorp Sentinel<\/strong> et AWS Cedar<\/strong>. Nous examinerons chacun en profondeur, les comparerons selon les dimensions les plus importantes pour la s\u00e9curit\u00e9 CI\/CD, et fournirons une matrice de d\u00e9cision pour vous aider \u00e0 choisir.<\/p>\n Open Policy Agent (OPA)<\/a> est le moteur de politiques g\u00e9n\u00e9raliste le plus \u00e9tabli dans l\u2019\u00e9cosyst\u00e8me cloud-native. Cr\u00e9\u00e9 \u00e0 l\u2019origine par Styra et donn\u00e9 \u00e0 la Cloud Native Computing Foundation (CNCF), OPA a obtenu le statut de projet dipl\u00f4m\u00e9 CNCF en 2021. Il est con\u00e7u pour d\u00e9coupler les d\u00e9cisions de politique de la logique applicative en fournissant un moteur l\u00e9ger et performant qui peut \u00eatre int\u00e9gr\u00e9 en tant que sidecar, biblioth\u00e8que ou d\u00e9mon autonome.<\/p>\n OPA utilise Rego<\/strong>, un langage de requ\u00eate d\u00e9claratif sp\u00e9cialement con\u00e7u, inspir\u00e9 de Datalog. Les politiques Rego op\u00e8rent sur des donn\u00e9es structur\u00e9es (JSON\/YAML), ce qui les rend applicables \u00e0 pratiquement tous les domaines : contr\u00f4le d\u2019admission Kubernetes, validation des plans Terraform, autorisation d\u2019API, application des politiques de pipeline CI\/CD, et bien plus encore.<\/p>\n Rego est puissant mais pr\u00e9sente une v\u00e9ritable courbe d\u2019apprentissage. C\u2019est un langage de programmation logique o\u00f9 vous d\u00e9finissez des r\u00e8gles sous forme d\u2019instructions logiques plut\u00f4t que d\u2019instructions imp\u00e9ratives. Voici un exemple simple qui refuse les conteneurs s\u2019ex\u00e9cutant en tant que root :<\/p>\n Le style d\u00e9claratif est \u00e9l\u00e9gant une fois que vous l\u2019avez int\u00e9rioris\u00e9, mais les d\u00e9veloppeurs habitu\u00e9s aux langages imp\u00e9ratifs ont souvent du mal avec le mod\u00e8le d\u2019\u00e9valuation de Rego \u2014 en particulier l\u2019\u00e9valuation partielle, la compr\u00e9hension d\u2019ensembles et l\u2019it\u00e9ration implicite sur les collections avec la syntaxe Conftest<\/a> est la r\u00e9ponse d\u2019OPA \u00e0 l\u2019int\u00e9gration CI\/CD. C\u2019est un outil en ligne de commande qui ex\u00e9cute les politiques OPA sur des fichiers de configuration structur\u00e9s \u2014 YAML Kubernetes, plans Terraform, Dockerfiles, et plus encore. Une \u00e9tape CI typique ressemble \u00e0 ceci :<\/p>\n Conftest prend en charge plusieurs formats d\u2019entr\u00e9e nativement, peut r\u00e9cup\u00e9rer des politiques depuis des registres OCI (permettant une distribution centralis\u00e9e des politiques), et s\u2019int\u00e8gre parfaitement dans tout syst\u00e8me CI capable d\u2019ex\u00e9cuter une commande shell. Pour un guide pratique pas \u00e0 pas, consultez notre Lab : Application des politiques de d\u00e9ploiement Kubernetes avec OPA Conftest en CI\/CD<\/a>.<\/p>\n Pour un guide complet sur OPA et Rego dans le CI\/CD, consultez notre article : Policy as Code pour le CI\/CD : Appliquer des portes de s\u00e9curit\u00e9 avec OPA et Rego<\/a>.<\/p>\n Kyverno<\/a> est un moteur de politiques natif Kubernetes, con\u00e7u sp\u00e9cifiquement pour l\u2019\u00e9cosyst\u00e8me Kubernetes. Il est devenu un projet CNCF en incubation et a connu une adoption rapide aupr\u00e8s des \u00e9quipes souhaitant appliquer des politiques sans apprendre un nouveau langage de programmation. La philosophie centrale de Kyverno est que les administrateurs Kubernetes doivent pouvoir \u00e9crire des politiques en utilisant le m\u00eame YAML qu\u2019ils connaissent d\u00e9j\u00e0.<\/p>\n Les politiques Kyverno sont d\u00e9finies comme des ressources personnalis\u00e9es Kubernetes. Il n\u2019y a pas de nouveau langage \u00e0 apprendre \u2014 les politiques utilisent la syntaxe YAML famili\u00e8re avec la correspondance de motifs, les overlays et les expressions JMESPath pour les conditions. Voici une politique \u00e9quivalente qui exige que les conteneurs s\u2019ex\u00e9cutent en tant que non-root :<\/p>\n Cette approche YAML-first r\u00e9duit consid\u00e9rablement la barri\u00e8re \u00e0 l\u2019entr\u00e9e. Tout op\u00e9rateur Kubernetes peut lire et \u00e9crire des politiques Kyverno sans formation sp\u00e9cialis\u00e9e.<\/p>\n Kyverno s\u2019est \u00e9tendu au-del\u00e0 du simple contr\u00f4le d\u2019admission avec le Kyverno CLI<\/strong>, qui peut valider des ressources par rapport \u00e0 des politiques hors ligne \u2014 ce qui le rend utilisable dans les pipelines CI\/CD :<\/p>\n Le CLI prend en charge les tests de politiques, la validation des ressources et peut g\u00e9n\u00e9rer des rapports XML JUnit pour l\u2019int\u00e9gration CI. Cependant, l\u2019offre CI\/CD de Kyverno est plus restreinte que celle d\u2019OPA : il fonctionne mieux avec les manifestes Kubernetes et ne g\u00e8re pas nativement les plans Terraform, les Dockerfiles ou d\u2019autres formats non-Kubernetes.<\/p>\n HashiCorp Sentinel<\/a> est un framework de policy-as-code int\u00e9gr\u00e9 aux produits commerciaux de HashiCorp : Terraform Cloud\/Enterprise, Vault Enterprise, Consul Enterprise et Nomad Enterprise. Il a \u00e9t\u00e9 con\u00e7u sp\u00e9cifiquement pour fournir des garde-fous de gouvernance pour les workflows de provisionnement d\u2019infrastructure.<\/p>\n Sentinel utilise son propre langage sp\u00e9cifique au domaine, plus imp\u00e9ratif que Rego et plus accessible pour les d\u00e9veloppeurs familiers avec Python ou Go. Voici un exemple qui restreint les types d\u2019instances EC2 dans Terraform :<\/p>\n Le langage prend en charge les imports, les fonctions, les niveaux d\u2019application (advisory, soft-mandatory, hard-mandatory), et a une sensation imp\u00e9rative famili\u00e8re. Les politiques se lisent plus naturellement que Rego pour la plupart des d\u00e9veloppeurs.<\/p>\n Sentinel est profond\u00e9ment int\u00e9gr\u00e9 aux workflows de Terraform Cloud et Enterprise. Les politiques sont \u00e9valu\u00e9es automatiquement lors du Pour les pipelines CI\/CD en dehors de l\u2019\u00e9cosyst\u00e8me HashiCorp, le Sentinel CLI<\/strong> (le simulateur Cedar<\/a> est un langage de politique et un moteur d\u2019\u00e9valuation d\u00e9velopp\u00e9 par AWS et mis en open source en 2023. Con\u00e7u \u00e0 l\u2019origine pour alimenter Amazon Verified Permissions et AWS IAM Identity Center, Cedar a \u00e9t\u00e9 pens\u00e9 d\u00e8s le d\u00e9part pour l\u2019autorisation<\/strong> \u2014 d\u00e9terminer si un principal peut effectuer une action sur une ressource.<\/p>\n Cedar est le plus r\u00e9cent entrant dans cette comparaison, et son champ d\u2019application est plus restreint que celui d\u2019OPA ou de Kyverno. Bien qu\u2019il excelle dans les d\u00e9cisions d\u2019autorisation fine, son application \u00e0 l\u2019application des politiques CI\/CD est encore \u00e9mergente.<\/p>\n Le langage de Cedar privil\u00e9gie la lisibilit\u00e9 et l\u2019analysabilit\u00e9. Les politiques sont exprim\u00e9es sous forme d\u2019instructions permit\/forbid qui se lisent presque comme de l\u2019anglais :<\/p>\n Le syst\u00e8me de types et les capacit\u00e9s de v\u00e9rification formelle de Cedar sont uniques parmi les moteurs de cette comparaison. AWS a publi\u00e9 des preuves formelles<\/a> des propri\u00e9t\u00e9s cl\u00e9s du langage Cedar, garantissant que les politiques se comportent de mani\u00e8re pr\u00e9visible et peuvent \u00eatre analys\u00e9es pour d\u00e9tecter les conflits, les redondances et l\u2019exhaustivit\u00e9.<\/p>\n L\u2019int\u00e9gration CI\/CD de Cedar est la moins mature des quatre moteurs. Il peut \u00eatre utilis\u00e9 pour mod\u00e9liser les d\u00e9cisions d\u2019autorisation CI\/CD \u2014 par exemple, qui peut d\u00e9ployer dans quel environnement, quels pipelines peuvent acc\u00e9der \u00e0 quels secrets, ou quelles branches peuvent d\u00e9clencher des releases en production \u2014 mais cela n\u00e9cessite un travail d\u2019int\u00e9gration personnalis\u00e9. Il n\u2019existe pas d\u2019\u00e9quivalent \u00e0 Conftest ou au Kyverno CLI pour valider des manifestes Kubernetes ou des plans Terraform par rapport \u00e0 des politiques Cedar pr\u00eates \u00e0 l\u2019emploi.<\/p>\n Cela dit, le SDK de Cedar est disponible en Rust, Java et Go, et son moteur d\u2019\u00e9valuation peut \u00eatre int\u00e9gr\u00e9 dans des outils CI\/CD personnalis\u00e9s. Les \u00e9quipes construisant des plateformes de d\u00e9ploiement sur mesure sur AWS pourraient trouver que Cedar s\u2019int\u00e8gre naturellement pour la logique d\u2019autorisation.<\/p>\ns3:*<\/code> ? Le pipeline \u00e9choue avec un message clair expliquant pourquoi. Un manifeste Kubernetes ex\u00e9cute un conteneur en tant que root ? Bloqu\u00e9 avant d\u2019atteindre le cluster.<\/p>\nOpen Policy Agent (OPA) et Rego<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Langage de politique : Rego<\/h3>\n
package kubernetes.admission\n\ndeny[msg] {\n input.request.kind.kind == \"Pod\"\n container := input.request.object.spec.containers[_]\n container.securityContext.runAsUser == 0\n msg := sprintf(\"Container '%v' must not run as root\", [container.name])\n}<\/code><\/pre>\n[_]<\/code>.<\/p>\nInt\u00e9gration CI\/CD avec Conftest<\/h3>\n
conftest test deployment.yaml --policy .\/policies\/ --output json<\/code><\/pre>\nPoints forts<\/h3>\n
\n
opa test<\/code>, incluant l\u2019analyse de couverture.<\/li>\nPoints faibles<\/h3>\n
\n
Kyverno<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Langage de politique : YAML (natif Kubernetes)<\/h3>\n
apiVersion: kyverno.io\/v1\nkind: ClusterPolicy\nmetadata:\n name: require-run-as-nonroot\nspec:\n validationFailureAction: Enforce\n rules:\n - name: check-containers\n match:\n any:\n - resources:\n kinds:\n - Pod\n validate:\n message: \"Containers must not run as root\"\n pattern:\n spec:\n containers:\n - securityContext:\n runAsNonRoot: true<\/code><\/pre>\nInt\u00e9gration CI\/CD<\/h3>\n
kyverno apply .\/policies\/ --resource deployment.yaml<\/code><\/pre>\nPoints forts<\/h3>\n
\n
Points faibles<\/h3>\n
\n
HashiCorp Sentinel<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Langage de politique : langage Sentinel<\/h3>\n
import \"tfplan\/v2\" as tfplan\n\nallowed_instance_types = [\"t3.micro\", \"t3.small\", \"t3.medium\"]\n\nmain = rule {\n all tfplan.resource_changes as _, rc {\n rc.type is \"aws_instance\" implies\n rc.change.after.instance_type in allowed_instance_types\n }\n}<\/code><\/pre>\nInt\u00e9gration CI\/CD<\/h3>\n
terraform plan<\/code> dans Terraform Cloud, et les niveaux d\u2019application d\u00e9terminent si les violations produisent des avertissements ou bloquent les applies. Cette int\u00e9gration \u00e9troite est \u00e0 la fois la plus grande force de Sentinel et sa principale limitation.<\/p>\nsentinel<\/code>) permet les tests et l\u2019\u00e9valuation en local, mais il op\u00e8re sur des donn\u00e9es simul\u00e9es plut\u00f4t que sur l\u2019\u00e9tat r\u00e9el de l\u2019infrastructure. Vous pouvez tester les politiques Sentinel dans un pipeline CI, mais le point d\u2019application principal reste au sein des produits HashiCorp.<\/p>\nPoints forts<\/h3>\n
\n
Points faibles<\/h3>\n
\n
AWS Cedar<\/h2>\n
Pr\u00e9sentation<\/h3>\n
Langage de politique : Cedar<\/h3>\n
\/\/ Only allow production deployments from the main branch\nforbid (\n principal,\n action == Action::\"deploy\",\n resource == Environment::\"production\"\n) unless {\n context.source_branch == \"main\" &&\n context.tests_passed == true &&\n context.approvals >= 2\n};<\/code><\/pre>\nInt\u00e9gration CI\/CD<\/h3>\n
Points forts<\/h3>\n
\n
Points faibles<\/h3>\n
\n
Tableau comparatif<\/h2>\n