GitOps Security Best Practices
GitOps solved a real operational problem. By making Git the single source of truth for infrastructure state and letting Argo CD or Flux pull and apply changes, teams eliminated the class of drift problems that come from ad-hoc 'kubectl apply' commands and manual Terraform runs. The operational clarity was real. What changed simultaneously, and quietly, was the threat model. When your Git reposit…
- GitOps makes Git a production control plane, your repository security posture is now your deployment security posture
- Branch protection bypass, secret sprawl in manifests, and permissive Argo CD RBAC are the three highest-impact vectors
- External Secrets Operator is architecturally cleaner than Sealed Secrets for teams with an existing secrets management platform
- Drift detection is an underused GitOps security property, configure it to alert, not just auto-correct
- Signed commits create identity attribution on every production change, a security property no manual deployment pipeline can match
Git Is Now A Production Control Plane
The GitOps model is conceptually clean: Git holds the desired state, a controller (Argo CD or Flux) continuously reconciles actual state against it. Engineers stop interacting with clusters directly. Changes go through pull requests. The audit trail is in Git history. This is genuinely better operationally than the alternative. What the model means from a security perspective is that Git repository permissions are now production access controls. A developer who can merge to the main branch in a
The Specific Vectors: What Attackers Actually Exploit
Branch protection bypass is the highest-impact vector in a GitOps environment. If an attacker can merge to the branch that Argo CD or Flux watches, whether through a compromised account with sufficient permissions, a misconfigured repository allowing force pushes, or an administrator account that bypasses required reviews, they can deploy arbitrary manifests to production. The fix is not just enabling branch protection; it is auditing who has bypass permissions and removing administrator exempti
Argo CD RBAC And The Least-Privilege Deployment Model
Argo CD ships with a default admin account and a permissive RBAC model that grants broad access. In practice, I have seen production Argo CD instances where every developer has the ability to trigger syncs, modify application definitions, and override sync policies. This is the equivalent of giving every developer production kubectl access, which is precisely the problem GitOps was supposed to solve. Argo CD RBAC uses a Casbin policy model configured in a ConfigMap. The operational pattern that
Frequently asked questions
- What is the biggest security mistake teams make when adopting GitOps?
- Not updating the repository security model to match the new threat model. Teams adopt Argo CD or Flux, point it at an existing Git repository, and leave the branch protection rules, team permissions, and secret handling patterns unchanged. The repository just became a production control plane, but it's still configured like a code collaboration to…
- Should I use Sealed Secrets or External Secrets Operator?
- If your team has an existing secrets management platform, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, use External Secrets Operator. It integrates with your existing infrastructure and keeps secret material out of Git entirely. If you don't have a secrets management platform and need something that works with Git-native workflows, Seale…
- How do I audit what Argo CD has deployed and who approved it?
- Argo CD's event stream and audit log, combined with Git commit history and PR review records, provides the full chain of custody. The critical configuration is ensuring SSO is enabled (so Argo CD actions are attributed to real identities, not shared accounts) and that the Argo CD audit log is shipped to your SIEM. Without SSO, Argo CD audit logs a…
- Does GitOps eliminate the need for Kubernetes RBAC?
- No, GitOps replaces direct human access to clusters with controller-mediated access, but Kubernetes RBAC is still the mechanism that governs what the GitOps controller itself can do. The Argo CD or Flux service account needs carefully scoped RBAC permissions. If that service account has cluster-admin, a GitOps control plane compromise gives an att…