Hardening Argo CD

It can deploy anything, anywhere.

Advanced14 min · lesson 11 of 12

Argo CD is one of the most privileged things in your platform — it holds credentials to every cluster it manages and applies arbitrary manifests from Git — so hardening spans its own components, its access model, and the Git trust chain. Its pieces (API server, repo-server, application-controller, Redis, Dex) should run with least-privilege service accounts, network policies restricting them, and the UI/API behind SSO with no anonymous access. Turn off or lock down the built-in admin account after bootstrap.

The Argo CD trust surface

access to Argo CD

UI/API

SSO, no anon, RBAC

admin account

disable after setup

what Argo CD trusts + reaches

Git repos

the real source of truth

cluster creds

least privilege per cluster

projects

constrain repos/dests/kinds

Lock access (SSO+RBAC), constrain scope (projects, scoped cluster creds), and protect Git — it defines what deploys.

Git is now part of your security perimeter

Because Argo CD deploys whatever is in Git, write access to a synced repo is deploy access to your clusters — so the repo needs the protections of a production system: branch protection, required reviews, signed commits (Argo CD can verify commit signatures), and CODEOWNERS on sensitive paths. Combine that with scoped projects, least-privilege cluster credentials, SSO-backed RBAC, and audit logging of syncs. Defense in depth: even a trusted Git change should hit policy (OPA/Gatekeeper) at admission.

Write access to a synced repo is deploy access to prod

In GitOps, merging to a synced branch deploys to the cluster, so anyone who can push there can change production — the Git repo is now inside your security perimeter. Protect it like one: required reviews, signed commits (and verify them in Argo CD), CODEOWNERS, and no direct pushes. Pair it with scoped projects and admission policy so a malicious or mistaken commit still meets a second gate before it runs.

Secrets & image updatesArgo CD vs Flux