Argo CD + Kyverno: the GitOps policy as code your cluster was missing

Lire cet article en français

Stéphane Robert DevOps Engineer

Updated on April 14, 2026 · Published on April 13, 2026

9 min read

#kubernetes#supply-chain#devsecops#securite#gitops

You use Argo CD to drive your Kubernetes deployments with GitOps. But who checks that what lands in the cluster complies with your security rules? On 2 April 2026, the CNCF published a practical guide that couples Argo CD and Kyverno to turn your security policies into versioned code, deployed and enforced automatically. Here is what to take away from it, and why it is a critical link in the supply chain.

About the links in this article

This blog is written in French, and the linked guides are in French. I kept them because they are the underlying references, but be aware of the language before you follow them.

Why does this topic matter now?

Four signals converge this week in our supply chain watch:

• A CNCF article (2 April 2026) detailing the Argo CD + Kyverno pattern in production
• The Argo CD v3.3.6 release (27 March 2026), a bugfix version, images signed with Cosign and verifiable provenance
• Argo CD v3.4.0-rc4 (27 March 2026), the GA version is not out yet, the v3.4 milestone targets 4 May 2026
• CVE-2020-8554, a design vulnerability (MITM through externalIPs) still not fixed natively in Kubernetes, which Kyverno policies can mitigate

The timing is no accident. After the recent supply chain attacks on GitHub Actions (tj-actions, Trivy), the community is pushing for the admission controller to become the last line of defense before the cluster.

What is Kyverno in 30 seconds?

Kyverno is a CNCF Graduated project since 16 March 2026, which strengthens its credibility as a policy as code engine for Kubernetes. It acts as a Kubernetes admission controller: it intercepts every request to the API server before the resource is created, and decides what to do with it according to your rules.

Five policy families cover the full resource lifecycle:

Type	Action	Concrete example
Validate	Block or audit	Forbid containers running as root
Mutate	Modify on the fly	Inject a team label automatically
Generate	Create resources	Generate one NetworkPolicy per namespace
Cleanup	Remove leftovers	Clean up Failed pods every hour
VerifyImages	Check signature, digest and attestations	Reject an image not signed with Cosign

Glissez pour voir

The decisive advantage: policies are written in standard Kubernetes YAML. No Rego (OPA), no new language to learn. For a detailed comparison, see VAP vs Kyverno vs Gatekeeper.

How does the App-of-Apps pattern deploy Kyverno?

The CNCF approach relies on a pattern Argo CD users know well: App-of-Apps. A root application points to a Git directory containing Application manifests, and each child manages its own Helm chart.

global-infra/
  infra-services/          # ← Argo CD root app
    kyverno.yaml           # Application: deploys Kyverno (sync-wave 1)
    kyverno-policies.yaml  # Application: deploys the policies (sync-wave 2)
  kyverno/
    Chart.yaml             # Helm wrapper → kyverno 3.7.1
    values.yaml
  kyverno-policies/
    Chart.yaml             # Helm wrapper → kyverno-policies
    values.yaml
    templates/             # your ValidatingPolicies / ImageValidatingPolicies

The sync-wave guarantees that Kyverno is installed before the policies are applied. Without it, Argo CD would try to create ValidatingPolicy resources before the CRD exists.

Kyverno 1.17+, new CEL types

Since February 2026, the ClusterPolicy CRDs are deprecated (removal in v1.20, October 2026). For new deployments, use the CEL types (ValidatingPolicy, ImageValidatingPolicy, etc.). The example below uses the new syntax. See the official migration guide.

Argo CD options not to forget

With Kyverno, enable ServerSideApply=true in the syncOptions: its CRDs can exceed the annotation size limit used by client-side apply.

Also add argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true on the Argo CD application. Without it, the mutations performed by Kyverno can cause permanent drift in Argo CD diffs.

Why audit first, enforce later?

The classic trap: enabling policies in Deny mode on day one and blocking the whole team. The CNCF guide recommends a progressive approach:

1. Deploy the policies in Audit mode, Kyverno lets resources through but records violations in the PolicyReport resources
2. Measure the impact, how many existing deployments would be blocked?
3. Fix the manifests, adapt the Deployments, StatefulSets, etc.
4. Switch to Deny, a simple value change in Git, Argo CD reconciles automatically

The Audit → Deny switch is a Git change. No kubectl edit, no ops ticket. That is policy as code in the strict sense.

What is the supply chain impact?

In a secured supply chain, Kyverno steps in at the most critical point, right before the image runs in the cluster:

Code → Build → Sign (Cosign) → Push Registry → Deploy (Argo CD)
                                                       ↓
                                              Kyverno checks:
                                              ✓ Image signed?
                                              ✓ SLSA provenance?
                                              ✓ No critical CVE?
                                              ✓ No root container?

Concretely, Kyverno can:

• Verify Cosign signatures before admission
• Require a SLSA provenance attestation, a topic already covered on this blog
• Block images from unapproved registries
• Prevent execution as root
• Forbid externalIPs (a direct mitigation of CVE-2020-8554)

CVE-2020-8554, still relevant

This CVE from 2020 is a design vulnerability that allows a MITM on Kubernetes services through externalIPs. It has no native fix in Kubernetes, it is considered a design flaw affecting all versions. The recommended mitigation is to forbid the use of externalIPs, for example with a Kyverno admission policy or the DenyServiceExternalIPs feature gate.

What does Argo CD v3.3.6 bring?

The Argo CD v3.3.6 release, published on 27 March 2026, is part of a release chain already signed with Cosign, with verifiable provenance meeting the SLSA Level 3 requirements for images and CLI binaries. The signing and the provenance are not specific to this version, they belong to the Argo CD release process at large.

Argo CD v3.4.0 is in release candidate (rc4, published on 27 March 2026). The GA version is not available yet; the v3.4 milestone targets 4 May 2026.

How do you get started with a minimal policy?

For those who want to test quickly, here is the policy most consistent with our narrative thread, it directly covers CVE-2020-8554 by forbidding the creation of services with externalIPs:

restrict-external-ips.yaml

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: restrict-external-ips
spec:
  validationActions: [Audit]   # switch to [Deny] after 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)."

Commit this file into the kyverno-policies/templates/ directory, Argo CD will deploy it automatically.

Going further: full course

This post covers the principles. If you want a step-by-step guide with the complete manifests (Helm wrapper, sync-waves, ServerSideApply, ServerSideDiff, IncludeMutationWebhook, three ready-to-use policies and the Audit → Enforce workflow), see module 8 of the ArgoCD course: ArgoCD + Admission Controllers.

Key takeaways

• Kyverno + Argo CD = GitOps policy as code, your security policies are versioned, reviewed and deployed like application code
• Audit mode allows a risk-free rollout, measure before you block
• The admission controller is the last line of defense of the supply chain, after signing and provenance
• CVE-2020-8554 still has no native fix, a Kyverno restrict-external-ips policy is the recommended mitigation
• Argo CD signs its releases with Cosign and provides SLSA Level 3 provenance, the chain of trust is consistent end to end

SLSA provenance verification with Kyverno Implement SLSA provenance verification in CI and at Kubernetes deployment time.

Cosign, sign and verify your images Complete Cosign guide: signing, verification, CI/CD integration.

Where to start with supply chain security A pragmatic roadmap to secure your software chain.

ArgoCD course, GitOps on Kubernetes 8 modules: concepts, installation, App-of-Apps, multi-env, security and admission controllers.

Module 8, ArgoCD + Admission Controllers Complete guide: Kyverno via App-of-Apps, sync-waves, ServerSideDiff, VerifyImages and the Audit → Enforce workflow.

Kyverno, Kubernetes Policy Engine Complete Kyverno guide: YAML policies, validate, mutate, generate and CEL.

Kubernetes Admission Controllers Understand admission controllers and their role in cluster security.

Securing ArgoCD RBAC, SSO, network policies and ArgoCD security best practices.

Source: GitOps policy-as-code: Securing Kubernetes with Argo CD and Kyverno, CNCF Blog, 2 April 2026. Watch score: 60/100 (bugfix release, supply chain topic, 4 concurring sources).

×

📖 Voir la documentation →