How to Enforce Policies in Argo CD Without Breaking Developer Workflows
If you’ve worked with Argo CD for more than a sprint, you already know why it’s so loved. It’s fast, clean, declarative, and works beautifully with Git as the source of truth. But here’s the part that’s rarely talked about: Argo CD doesn’t help you enforce security or compliance policies.
Not natively, at least.
And in a highly regulated environment—especially in banking, fintech, or healthcare—that’s a serious gap. One that many platform teams are left trying to patch on their own.
In this blog, we will discuss making deployments secure and compliant in Argo CD. But in case you are interested, check out the blog on securing the entire GitOps process by Bob Boule, our VP of Product.
Friction between speed and security in GitOps
In theory, GitOps sounds like the perfect model. Every change goes through Git. Argo CD ensures that the cluster state matches what’s declared. It’s clean and traceable.
But GitOps doesn’t evaluate what you’re deploying, only checks whether it matches what’s in Git.
So while developers are syncing YAMLs to production, the security team is asking questions like:
- Was the image scanned?
- Was the change reviewed and approved?
- Does this include a valid SBOM?
- Who approved this deployment—and are they supposed to?
And more often than not, the answers aren’t in Git. The answer lies in various stages of software delivery (build, artefact, code scanning, etc.)
Default workaround: YAML bloat and manual Gating
To enforce policies, some DevOps or platform engineering teams try to inject checks directly into Argo CD. And that involves activities such as:
- Editing ApplicationSets
- Adding approval gates into CI pipelines
- Relying on developers to add annotations or PR labels
- Writing custom Lua scripts to conditionally block syncs
But, this approach of editing Argo CD resources or halting deployment is brittle, inconsistent, and it puts the burden on the developers too.
Let’s face it- developers shouldn’t be responsible for enforcing compliance policies. And platform engineers shouldn’t have to maintain 50 versions of security logic across 200 different services.
Reality check of compliance policies in GitOps deployment
Most of the policies we’re being asked to enforce aren’t “nice-to-haves.” They’re core requirements tied to frameworks like SOC 2, ISO 27001, HIPAA, PCI-DSS, and internal risk controls. Few examples of policies can be:
- Only allow deployments with SBOMs attached
- Block deployment if the CVE severity > 7.0
- Require an approved ServiceNow ticket for every production release
- Developer and approver must be different people (SoD)
- Deployments must be paused if initiated during a blackout window
Try enforcing all of that across a GitOps model manually, and you’re looking at YAML sprawl, missed gates, and audit chaos.
So, we took a different approach.
What if you could enforce those policies without modifying a single manifest?
That’s what we did with OpsMx Delivery Shield. We enable DevOps and Platform engineers to enforce security and compliance policies defined by the AppSec team in organisation.
How OpsMx Delivery Shield enables Secure GitOps
Instead of embedding policies in manifests, Delivery Shield runs an agent in the cluster. It intercepts every Argo CD deployment request and checks it against centrally defined policies.
There are 2 parts of Delivery Shield:
- Aggregate data in realtime, and then
- Apply AI to take decisions in the run-time
Part-1: Aggregate data: Delivery Shield pulls data from all the stages for app delivery:
- Git (commits, PRs)
- CI systems like Jenkins
- Artifact stores like JFrog
- Vulnerability scanners like Trivy
- Approval systems like ServiceNow
(refer the image below)
Part-2: Run-time Decision making: And then it answers the question: Should this deployment proceed?
If yes, Argo CD reconciles the changes. And If not, Delivery Shield blocks the sync, without changing the GitOps flow.
No YAML rewrites. No developer disruption. No pipeline modification. Check the below image.
Example of policy checks while syncing apps in Argo CD
Here is the video of Bob Boule, our VP products, who explains how an Deployment manifest file goes out-of-sync after a new build is created. However, the syncing process in Argo CD fails due to violation of Deployment Firewall policy.
Benefits of applying policies externally
As the DevOps and AppSec team manages to enforce policies externally, the immediate benefit is compliance of the process to organisational and industry standards. From a team perspective, here are a few benefits:
- Developers stops worrying about adding security logic to their manifests
- DevOps engineers get a scalable model for enforcing policy and compliance across all apps
Security teams gains visibility without chasing anyone
Final thoughts: Secure GitOps is possible with zero hassle
Argo CD gives you a clean, declarative delivery model. But it wasn’t built for policy enforcement. And that’s where OpsMx Delivery Shield comes into picture to fill exactly that gap.
If you’re running GitOps at scale, and you’re tired of chasing policy violations or hacking YAML to stay compliant, it’s time to try a better approach.
If you want to secure your GitOps process, book a demo today.
0 Comments