Vous utilisez Argo CD pour piloter vos déploiements Kubernetes en GitOps. Mais qui vérifie que ce qui arrive dans le cluster respecte vos règles de sécurité ? Le 2 avril 2026, la CNCF a publié un guide pratique qui couple Argo CD et Kyverno pour transformer vos politiques de sécurité en code versionné, déployé et appliqué automatiquement. Voici ce qu’il faut en retenir — et pourquoi c’est un maillon critique de la supply chain.
Pourquoi ce sujet compte maintenant
Quatre signaux convergent cette semaine dans notre veille supply chain :
- Un article CNCF (2 avril 2026) détaillant le pattern Argo CD + Kyverno en production
- La release Argo CD v3.3.6 (27 mars 2026) — version correctrice, images signées avec Cosign et provenance vérifiable
- Argo CD v3.4.0-rc4 (27 mars 2026) — la version GA n’est pas encore publiée, le milestone v3.4 vise le 4 mai 2026
- CVE-2020-8554 — une vulnérabilité de conception (MITM via
externalIPs) toujours non corrigée nativement dans Kubernetes, que des policies Kyverno peuvent mitiger
Le timing n’est pas un hasard. Après les attaques supply chain récentes sur les GitHub Actions (tj-actions, Trivy), la communauté pousse pour que l’admission controller devienne le dernier rempart avant le cluster.
Kyverno en 30 secondes
Kyverno est un projet CNCF Graduated depuis le 16 mars 2026, ce qui renforce sa crédibilité comme moteur de policy-as-code pour Kubernetes. Il agit comme un contrôleur d’admission Kubernetes : il intercepte chaque requête vers l’API server avant que la ressource ne soit créée, et décide quoi en faire selon vos règles.
Cinq familles de politiques couvrent le cycle de vie complet des ressources :
| Type | Action | Exemple concret |
|---|---|---|
| Validate | Bloquer ou auditer | Interdire les conteneurs en root |
| Mutate | Modifier à la volée | Injecter un label team automatiquement |
| Generate | Créer des ressources | Générer un NetworkPolicy par namespace |
| Cleanup | Supprimer le superflu | Nettoyer les pods Failed toutes les heures |
| VerifyImages | Vérifier signature, digest et attestations | Refuser une image non signée avec Cosign |
L’avantage décisif : les politiques sont écrites en YAML Kubernetes standard. Pas de Rego (OPA), pas de nouveau langage à apprendre. Pour un comparatif détaillé, voir VAP vs Kyverno vs Gatekeeper.
Le pattern App-of-Apps avec Kyverno
L’approche CNCF repose sur un pattern que les utilisateurs Argo CD connaissent
bien : App-of-Apps. Une application racine pointe vers un répertoire Git
contenant des manifests Application, et chaque enfant gère son propre chart
Helm.
global-infra/ infra-services/ # ← app racine Argo CD kyverno.yaml # Application: déploie Kyverno (sync-wave 1) kyverno-policies.yaml # Application: déploie les politiques (sync-wave 2) kyverno/ Chart.yaml # wrapper Helm → kyverno 3.7.1 values.yaml kyverno-policies/ Chart.yaml # wrapper Helm → kyverno-policies values.yaml templates/ # vos ValidatingPolicies / ImageValidatingPoliciesLe sync-wave garantit que Kyverno est installé avant que les politiques
ne soient appliquées. Sans ça, Argo CD tenterait de créer des ValidatingPolicy
avant que le CRD n’existe.
Audit d’abord, enforce ensuite
Le piège classique : activer les politiques en mode Deny dès le premier
jour et bloquer toute l’équipe. Le guide CNCF recommande une approche
progressive :
- Déployer les politiques en mode
Audit— Kyverno laisse passer les ressources mais enregistre les violations dans lesPolicyReport - Mesurer l’impact — combien de déploiements existants seraient bloqués ?
- Corriger les manifests — adapter les Deployments, StatefulSets, etc.
- Basculer en
Deny— un simple changement de valeur dans Git, Argo CD réconcilie automatiquement
Le passage Audit → Deny est une modification Git. Pas de kubectl edit,
pas de ticket ops. C’est du policy-as-code au sens strict.
Impact supply chain : le dernier rempart
Dans une chaîne de supply chain sécurisée, Kyverno intervient au point le plus critique — juste avant que l’image ne tourne dans le cluster :
Code → Build → Sign (Cosign) → Push Registry → Deploy (Argo CD) ↓ Kyverno vérifie : ✓ Image signée ? ✓ Provenance SLSA ? ✓ Pas de CVE critique ? ✓ Pas de conteneur root ?Concrètement, Kyverno peut :
- Vérifier les signatures Cosign avant admission
- Exiger une attestation de provenance SLSA — le sujet est déjà couvert sur ce blog
- Bloquer les images issues de registres non approuvés
- Empêcher l’exécution en tant que root
- Interdire les
externalIPs(mitigation directe de CVE-2020-8554)
Ce qu’Argo CD v3.3.6 apporte
La release Argo CD v3.3.6, publiée le 27 mars 2026, s’inscrit dans une chaîne de release déjà signée avec Cosign, avec une provenance vérifiable conforme aux exigences SLSA Level 3 pour les images et les binaires CLI. La signature et la provenance ne sont pas spécifiques à cette version — elles relèvent du processus de release d’Argo CD plus largement.
Argo CD v3.4.0 est en release candidate (rc4, publiée le 27 mars 2026). La version GA n’est pas encore disponible ; le milestone v3.4 vise le 4 mai 2026.
Mise en œuvre minimale
Pour ceux qui veulent tester rapidement, voici la policy la plus cohérente
avec notre fil narratif — elle couvre directement CVE-2020-8554 en
interdisant la création de services avec externalIPs :
apiVersion: policies.kyverno.io/v1kind: ValidatingPolicymetadata: name: restrict-external-ipsspec: validationActions: [Audit] # passer en [Deny] après validation matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["services"] validations: - expression: "!has(object.spec.externalIPs) || size(object.spec.externalIPs) == 0" message: "externalIPs are not allowed (CVE-2020-8554)."Commitez ce fichier dans le répertoire kyverno-policies/templates/,
Argo CD le déploiera automatiquement.
À retenir
- Kyverno + Argo CD = policy-as-code GitOps — vos politiques de sécurité sont versionnées, revues et déployées comme du code applicatif
- Le mode Audit permet un rollout sans risque — mesurez avant de bloquer
- L’admission controller est le dernier rempart de la supply chain, après la signature et la provenance
- CVE-2020-8554 reste sans correctif natif — une policy Kyverno
restrict-external-ipsest la mitigation recommandée - Argo CD signe ses releases avec Cosign et fournit une provenance SLSA Level 3 — la chaîne de confiance est cohérente de bout en bout
Source : GitOps policy-as-code: Securing Kubernetes with Argo CD and Kyverno — CNCF Blog, 2 avril 2026. Score de veille : 60/100 (release correctrice, sujet supply chain, 4 sources concordantes).