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.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “Managing Secrets in ArgoCD Without Fighting It”.
Key questions
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 secret workflows become hard to operate at scale?
A: They move the main risk from plaintext exposure to manual key handling, repeated encryption and decryption, unreadable diffs and re-encryption after rotation.
Q: What are the signs that an external secret controller is misaligned with ArgoCD?
A: A common sign is a secret that appears after sync and then disappears again on the next reconciliation cycle.
Practitioner guidance
- Define the secret authority boundary Decide whether Git, an external secrets manager or a controller owns the credential lifecycle, then document that choice per application and environment so reconciliation does not compete with secret governance.
- Separate plaintext avoidance from lifecycle control Use encryption only when the team can also manage decryption access, key rotation and review workflows without slowing secret updates or creating hidden shared access.
- Check owner references on generated secrets Confirm that controller-created Kubernetes secrets carry an owner reference path back to the tracked resource so ArgoCD and Kubernetes garbage collection do not prune them unexpectedly.
Bottom line: ArgoCD handles manifests well, but secrets force a separate governance model because credentials cannot be treated like ordinary declarative config.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:57 pm
Secrets governance fails when the deployment system and the credential authority are not the same system. GitOps is built for reproducible desired state, but credentials require explicit ownership, rotation and revocation semantics that ArgoCD does not infer on its own. That creates a recurring boundary problem across NHI governance, platform engineering and release automation. The practitioner lesson is to define where secret authority lives before Git becomes the last writer.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should teams centralise secrets before using GitOps for Kubernetes?
A: Yes, when the same credential must serve multiple apps, clusters or environments. A central secrets manager gives you one lifecycle and one revocation point, while Git only carries the declarative reference. That reduces duplication, but only if the cluster-side materialisation is tracked correctly.
👉 Read our full editorial: ArgoCD secrets management breaks down when Git meets credentials