GitOps meets policy enforcement.
The moment you embrace Argo CD—that beautiful, declarative, Git-as-source-of-truth approach to Kubernetes—you inherit a question: Who watches the watchers? You’ve locked your infrastructure into version control. Your manifests are clean. Your deployments are automated. But what stops a developer from sneaking a container with root privileges into production? What prevents misconfigured RBAC from creating a security nightmare?
Enter Kyverno, a CNCF graduated project that does for policy enforcement what Argo CD does for deployment orchestration. It’s not new, but its marriage with Argo CD represents something genuinely transformative: a complete GitOps stack where security isn’t bolted on as an afterthought—it’s baked into the infrastructure fabric from day one.
What Kyverno actually does
Think of Kyverno as a bouncer at the Kubernetes club. Every resource trying to enter the cluster gets checked against a rulebook you define, all written in standard Kubernetes YAML. No special domain-specific languages. No proprietary syntax. Just YAML—the same language you’re already writing.
“Kyverno is a policy engine for Kubernetes. It lets you define rules for what is and isn’t allowed in your cluster, all written as standard Kubernetes YAML. Kyverno operates at the admission controller level, meaning it intercepts resource requests before they hit the cluster.”
It operates as an admission controller, sitting at the API gateway and catching resources before they’re actually created. This is where the real power lives. You can configure four distinct policy modes:
Validate policies block or audit resources that break your rules. Mutate policies don’t reject anything—they fix it. A pod requests privileged mode? Kyverno strips it automatically. Missing a network policy? Kyverno injects one. Generate policies create supporting resources automatically (think: automatically spinning up NetworkPolicies whenever a new Deployment lands). And Cleanup policies handle the tedious housekeeping, removing stale resources on a schedule.
This isn’t just security theater. This is security that works while you sleep.
Why this combination actually matters
Here’s the thing about Argo CD alone: it’s phenomenal at managing what gets deployed, but blissfully ignorant about whether it should. A misconfigured secret, a missing pod security context, a container image from an untrusted registry—Argo CD will deploy all of it faithfully, because it’s just following your Git repo.
Kyverno fills that gap. And when you wire Kyverno into Argo CD’s deployment pipeline, something magical happens: your policies become versioned artifacts living in Git, just like your manifests.
Consider the workflow. You write a new Kyverno policy as YAML. You commit it. Argo CD syncs it automatically. The policy is now live, enforcing constraints across your entire cluster. Need to audit before enforcing? Run the policy in audit mode first—violations get logged, but resources still deploy. Once you’re confident, flip a single YAML field from audit to enforce. That’s it. No manual kubectl apply. No cluster restarts. Just Git.
This is policy as infrastructure. And it changes the game.
The architecture that makes it work
The elegance here lies in simplicity. You deploy Kyverno as a standard Helm chart via an Argo CD Application. You then deploy your custom policies as a separate Application, pointing at a directory of YAML files in your repo. Argo CD’s sync-wave annotations ensure Kyverno controllers install before any policies try to enforce anything. No race conditions. No bootstrapping nightmares.
The repository structure unfolds like this:
global-infra/
infra-services/
kyverno.yaml # Argo CD Application deploying Kyverno
kyverno-policies.yaml # Argo CD Application deploying policies
kyverno/ # Helm chart wrapper
Chart.yaml
values.yaml
kyverno-policies/ # Your custom policies live here
Chart.yaml
values.yaml
templates/ # YAML policy definitions
Once this is in place, adding a new policy is trivial. Drop a YAML file in templates/. Push to Git. Argo CD syncs. Done. No manual overhead. No operator intervention.
Why you should actually care
Large organizations deal with compliance chaos. Different teams have different standards. Security reviews turn into bottlenecks. Policy drift happens silently until an audit discovers that half your cluster isn’t following the rulebook.
With Kyverno + Argo CD, you get declarative governance. Policies are reviewable. They’re auditable. They’re versionable. You can run them in audit mode to gather baseline violations before enforcing. You can promote policies through environments (dev → staging → prod) using the same Git workflow you use for code. When a policy violation occurs, you have a complete audit trail of what was rejected, when, and why.
For teams already living in GitOps, this feels inevitable—like discovering you’ve been missing a fundamental piece of the puzzle.
And here’s a prediction: as Kubernetes adoption matures, teams running Argo CD without Kyverno (or a comparable policy engine) will look increasingly reckless. Not because Kyverno is flashy—it’s the opposite, gloriously unglamorous—but because it solves a problem that only gets more painful as your cluster grows.
Setting it up isn’t scary
The actual deployment assumes you’ve already got Argo CD running and a root application watching your infrastructure directory. From there, you’re adding two Application manifests—kyverno.yaml and kyverno-policies.yaml—then Argo CD handles everything.
The initial setup does require YAML boilerplate (defining the Argo CD Applications, the Helm chart structure, the sync-wave annotations), but once that’s done, the operational burden shrinks. You’re no longer manually applying policies or juggling kubectl commands. You’re just committing YAML to Git and letting Argo CD do what it does best.
For teams using ITGix’s Application Development Platform (ADP), it’s even simpler—just set enabled: true and the platform scaffolds the rest. But you don’t need proprietary tooling to make this work. Any Argo CD installation can adopt this pattern.
The real payoff
Security shouldn’t feel like a tax on velocity. With Kyverno + Argo CD, it doesn’t. Policies enforce themselves. Violations are caught before they land in production. Teams get visibility into why something was rejected. The security team gets confidence that rules are actually being applied.
It’s infrastructure that speaks for itself. And in an era where Kubernetes clusters are sprawling across entire organizations, that’s not a luxury—it’s essential.
🧬 Related Insights
- Read more: Nine Vulnerabilities Expose IP KVMs as the Skeleton Key to Your Entire Network
- Read more: How TeamPCP’s Self-Propagating Worm Turned Open Source Into a Backdoor Factory
Frequently Asked Questions
What does Kyverno actually do in Kubernetes? Kyverno is a policy engine that acts as an admission controller, intercepting Kubernetes resources before they’re created. It can validate, mutate, generate, or clean up resources based on policies you define in standard YAML—preventing misconfigurations and enforcing security standards without manual intervention.
How do Kyverno and Argo CD work together? Argo CD deploys and syncs Kyverno policies from your Git repository to the cluster. This makes policies versioned, reviewable, and auditable. You can test policies in audit mode before enforcing them, and promote policy changes through environments just like application code.
Will Kyverno policies break my existing deployments? Not necessarily. Kyverno supports audit mode, which logs violations without blocking resources. Start in audit mode to understand what policies will affect your cluster, then gradually transition to enforce mode once you’ve fixed violations or adjusted policies to match your environment.
