ArgoCD secrets management: what works when Git is the source of truth?

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

View Full Forum →  |  NHI Foundation Course →