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.
At a glance
What this is: Infisical argues that ArgoCD handles declarative deployment cleanly, but secrets introduce a governance problem around plaintext exposure, rotation friction and reconciliation side effects.
Why it matters: IAM and platform teams need to understand where GitOps stops being a safe source of truth for secrets, because ownership, lifecycle and pruning controls must still survive reconciliation.
Context
GitOps works best when the object in Git is the object you want in the cluster. Secrets change that assumption because a credential is not just another manifest field, and base64 encoding is not encryption. In ArgoCD, the tension is between declarative reconciliation and the need to keep API keys, database passwords and other credentials out of plaintext repositories.
The governance problem is not only storage. It is also who can read the secret, how rotation happens, whether review remains meaningful, and what happens when a controller generates a secret after ArgoCD has already synced the parent resource. That makes ArgoCD secrets management a lifecycle and ownership problem, not just a deployment formatting problem.
For teams running Kubernetes through GitOps, the choice is less about elegance than about where secret authority lives. Encryption methods, external secret stores and operators each move the control point differently, and each changes how identity, ownership and drift behave across environments.
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. The control gap is ownership: ArgoCD can reconcile manifests, but it does not inherently govern credential lifecycle, rotation, or where the value comes from.
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. As teams, environments and release frequency grow, the workflow becomes slower and easier to misapply, which can undermine both security and delivery.
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. That usually indicates missing owner references, an incorrect creation policy or a resource tracking mismatch between ArgoCD and the controller that materialised the secret.
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.
Technical breakdown
Why ArgoCD treats secrets like ordinary Kubernetes resources
ArgoCD reconciles desired state from Git into the cluster, so a Secret object is handled like any other manifest unless something external changes that behavior. Kubernetes Secret data is only base64-encoded, which means committing it directly exposes the value to anyone who can read the file. If the secret is absent from Git, ArgoCD may still mark the application synced while the workload later fails because the pod cannot resolve the credential. That creates a false sense of completion: the deployment is declared correct even though the runtime dependency is missing.
Practical implication: Treat secrets as a separate governance path from manifests, with explicit handling for secrecy, ownership and runtime availability.
How encryption shifts the burden from plaintext to key management
Methods such as Sealed Secrets and SOPS keep plaintext out of Git by encrypting the secret material before commit, then decrypting it during reconciliation or apply time. That removes direct exposure, but it shifts the operating burden to encryption and decryption workflows, review friction and key lifecycle management. Every engineer touching the secret may need the decryption path, and rotating the key can force re-encryption of every dependent file. In practice, the secret is safer in transit to Git, but the operational surface around key custody becomes the real control point.
Practical implication: Use encryption only when your team can sustain the key lifecycle and review overhead without slowing rotation or release cadence.
Why external secret stores depend on owner references and controller trust
External Secrets Operator and similar controllers move the source of truth out of Git and into a central secret store, then materialise a Kubernetes Secret at sync time. That solves plaintext storage, but it introduces a second reconciliation layer: ArgoCD tracks the declarative resource, while the controller creates the live secret later. If the generated secret does not carry an owner reference back to the tracked resource, ArgoCD can prune it on the next sync. The creationPolicy setting exists to preserve that linkage so garbage collection and resource tracking stay aligned.
Practical implication: Verify that generated secrets have an owner reference path ArgoCD and Kubernetes can both recognise before rollout.
Threat narrative
Attacker objective: The practical objective is to prevent secret exposure while still delivering credentials into Kubernetes in a way ArgoCD can reconcile safely.
- Entry occurs when a secret is committed as plaintext or an unreadable encrypted object is rendered without a usable decryption path, leaving the workload without a valid credential at sync time.
- Credential access becomes operational rather than adversarial when teams rely on manual encryption, decryption or controller-managed retrieval to move values into the cluster.
- Escalation appears as reconciliation and pruning behavior, where ArgoCD or the controller repeatedly overwrites, removes or recreates the secret based on ownership metadata.
- Impact is failed pod startup, repeated drift, and an unstable secrets lifecycle that obscures which system is authoritative for the credential.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Plaintext avoidance is necessary, but key management becomes the new control surface. Encryption-based approaches remove raw values from Git, yet they substitute operational complexity around decryption access, reviewability and key rotation. That means the security question shifts from 'is the secret visible in the repo' to 'who can decrypt, rotate and re-render every dependent secret safely'. The practitioner implication is that confidentiality gains can be undone by lifecycle friction.
Owner-reference mismatch is a hidden failure mode in ArgoCD secrets management. If a controller creates the live secret after Git sync but the generated object is not tied back to a tracked owner, ArgoCD can prune it as drift. This is a governance gap, not just a tooling quirk, because accountability for the object never stabilises. The practitioner conclusion is that generated secrets need explicit lifecycle linkage, or reconciliation will keep erasing them.
Ephemeral rendering is a better mental model than static secret storage for GitOps environments. The article shows that centralised secret stores work best when they feed cluster-native objects through a governed handoff, not when teams try to force credentials to behave like manifests. That aligns more closely with NHI lifecycle governance than with conventional config management. Practitioners should treat secret materialisation as a managed identity event, not a file sync.
Secret sprawl and secret authority are the same problem at different layers. Teams often try to solve ArgoCD secret handling by choosing between encryption and an external store, but both approaches still fail if the organisation has no single answer for ownership across environments. The real control question is whether the platform can preserve intent, provenance and revocation as secrets move. Practitioners should design that authority model first.
From our research library:
- 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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
ArgoCD secrets management exposes an ownership problem, not just an encryption problem. GitOps assumes the rendered object in the cluster is the object under governance, but generated secrets break that assumption unless the lifecycle handoff is explicit. Platform teams should expect more reconciliation friction wherever secret materialisation happens outside Git.
Secret lifecycle control has to move upstream of cluster sync. Once a secret is rendered by a controller, the important question is not where it was stored but whether the cluster can prove provenance, owner linkage and revocation authority. That is why central secret stores and cluster operators need to be governed as one flow, not separate tools.
Secret sprawl remains the broader control failure. According to the 2024 State of Secrets Management Survey, 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned". For GitOps teams, that concern turns into an architectural requirement: keep one accountable source of truth and make reconciliation respect it.
For practitioners
- 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.
- Centralise credentials before expanding GitOps If multiple clusters or environments consume the same credential, move the source of truth into a central secrets manager before trying to replicate it through per-cluster encrypted files.
Key takeaways
- ArgoCD handles manifests well, but secrets force a separate governance model because credentials cannot be treated like ordinary declarative config.
- Encryption methods reduce plaintext exposure, yet they shift risk toward key handling, review friction and repeated re-encryption work.
- External secret stores work best when ownership, controller tracking and pruning behavior are designed together, not bolted on after deployment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Plaintext secrets in Git and rendered manifests expose the leakage problem this article centres on. |
| NHI-01 — Improper Offboarding | Generated secrets can persist or disappear unpredictably when ownership and lifecycle linkage is weak. | |
| Recommendation — Scan GitOps paths for exposed secrets and remove plaintext credential material from repositories and manifests. Tie every generated secret to a clear owner and revoke resources that no longer have an accountable source. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on credential handling, rotation burden and lifecycle control for secrets. |
| Recommendation — Apply authenticator management controls to govern rotation, revocation and storage of deployed secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Secret access and distribution depend on controlled permissions across Git, controllers and secret stores. |
| Recommendation — Review who can access, render and rotate secrets under PR.AA-05 across the GitOps chain. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential lifecycle and ownership sit at the centre of the secret-management problem described here. |
| Recommendation — Use account management controls to track secret owners, service accounts and rotation responsibility. | ||
Key terms
- GitOps Reconciliation: GitOps reconciliation is the process of keeping live infrastructure aligned with the desired state declared in Git. For Kubernetes, it detects divergence and may restore resources to the repository version. It is useful for configuration control, but it does not by itself prove that the declared state is secure or compliant.
- Owner Reference: A Kubernetes linkage that ties a generated object back to the resource that created it. In secrets workflows, it prevents orphaned resources from being pruned unpredictably and helps reconciliation systems understand which object is authoritative.
- External Secret Store: An external secret store is a separate secrets system that remains the authoritative source for sensitive values while another platform retrieves them on demand. This model is common when organisations already have approved secret governance in place. It helps preserve existing audit, rotation, and access control processes across distributed systems.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 28, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org