Notifications
Clear all
Topic starter
28/07/2026 6:16 pm
TL;DR: ArgoCD's Git-first reconciliation model works for manifests but becomes brittle for secrets because plaintext, encryption workflows, and out-of-band secret stores each create different governance tradeoffs, according to Infisical. The core issue is not storage alone, but whether identity and ownership remain intact when secrets are rendered, rotated, and pruned across clusters.
NHIMG editorial — based on content published by Infisical: Managing Secrets in ArgoCD Without Fighting It
Questions worth separating out
Q: What breaks when ArgoCD manages secrets like ordinary Kubernetes resources?
A: Secrets either end up exposed in Git as plaintext or become invisible dependencies that can pass sync while the workload still fails at runtime.
Q: Why do encrypted secrets still create operational risk in GitOps?
A: Encryption reduces exposure in the repository, but it adds key custody, resealing, and review overhead to the delivery path.
Q: How do external secret stores change the security model for ArgoCD?
A: They shift the source of truth out of Git and into a central credential store, which is often the right move for rotation and reuse.
Practitioner guidance
- Separate credential material from declarative manifests Keep plaintext secrets out of Git and use a workflow that makes the credential materialize only at deploy or sync time, not at commit time.
- Audit reseal and decryption dependencies If you use encryption-based handling, document who can reseal, who can decrypt, and how key rotation affects every secret that depends on that key.
- Validate owner references before rollout For operators that generate Kubernetes Secret objects, confirm creationPolicy and owner reference behaviour in a non-production cluster before promoting the pattern.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of Sealed Secrets and SOPS workflows for ArgoCD-managed clusters
- Operator patterns for pulling credentials from a central secrets store into Kubernetes
- Owner-reference and creationPolicy behaviour that prevents ArgoCD from pruning generated secrets
- Practical tradeoffs when one secrets manager serves CI, Kubernetes, and other environments
👉 Read Infisical's analysis of ArgoCD secrets management patterns →
ArgoCD secrets management: what works when Git is the source of truth?
Explore further
30/07/2026 10:57 pm
GitOps makes secrets governance a control-plane problem, not just a storage problem. ArgoCD does exactly what it is designed to do, which is reconcile declared state. The problem is that credentials are not ordinary state because they carry lifecycle, ownership, and exposure risk that Git cannot express on its own. That is why secrets handling in GitOps always becomes a question of who can materialise the credential, who can rotate it, and who can prove it still belongs in the cluster.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing why detection without revocation is incomplete.
A question worth separating out:
Q: What should IAM and platform teams check before standardising a secrets workflow?
A: They should check who owns the credential, who can rotate it, how access is reviewed, and whether the deployment controller can accidentally delete the rendered secret. If those answers are split across tools without a clear lifecycle model, the workflow will remain fragile.
👉 Read our full editorial: ArgoCD secrets management breaks down when Git meets credentials
