ArgoCD secrets management breaks down when Git meets credentials

At a glance

What this is: This explains why ArgoCD secrets management is awkward in GitOps and compares encryption-based and external-store approaches for keeping credentials out of plaintext Git.

Why it matters: It matters because IAM and platform teams need secrets workflows that preserve rotation, ownership, and traceability without fighting reconciliation engines or multiplying control planes.

👉 Read Infisical's analysis of ArgoCD secrets management patterns

Context

ArgoCD treats Git as the source of truth, which works well for declarative workloads but creates a governance gap for secrets. A Kubernetes Secret is still just another resource to ArgoCD, so credentials either end up exposed in manifests or depend on extra tooling to stay out of Git. For identity and access teams, the issue is not deployment convenience alone. It is whether secret ownership, rotation, and lifecycle controls survive GitOps reconciliation.

This is a classic secrets management problem in NHI programmes: the secret is a credential, not a config value. Once encrypted files, controllers, or external stores enter the flow, teams have to manage who can decrypt, who can rotate, and which system actually owns the object in cluster. That is why operational simplicity and governance clarity rarely align unless the workflow is deliberately designed.

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 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. That makes rotation slower and increases the chance of stale credentials surviving because teams defer or simplify the workflow.

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. The tradeoff is that the generated Kubernetes secret must stay correctly tracked, or reconciliation can prune it or leave teams debugging disappearing resources.

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.

Technical breakdown

Why ArgoCD treats secrets like any other resource

ArgoCD applies the same reconciliation logic to a Secret that it applies to a deployment, service, or config map. If the secret is present in Git, ArgoCD applies it. If it is absent, ArgoCD does not manage it. Kubernetes Secret objects are base64-encoded, not encrypted, so committing them directly exposes the credential to anyone who can read the manifest. If the secret is omitted from Git, the application can sync cleanly while downstream pods fail because the credential never materialises.

Practical implication: keep credentials out of plaintext Git and decide explicitly which system owns secret materialization.

How encryption-based secrets handling changes the control model

Tools such as Sealed Secrets and SOPS keep plaintext out of Git by encrypting the secret before commit and decrypting it later. That solves one problem but introduces another: key management becomes part of the delivery path. With Sealed Secrets, every change requires resealing. With SOPS, editors and reviewers need decryption access before they can understand the diff. The real control plane shifts from Git alone to Git plus cryptographic keys, which increases operational friction and makes rotation more expensive.

Practical implication: treat encryption as a workflow control, not a complete secrets governance model.

Why external secret stores depend on ownership metadata

External Secrets Operator and similar patterns keep secrets out of Git by fetching them from a central store and writing them into Kubernetes at sync time. That centralises rotation and reduces plaintext exposure, but it also creates a second lifecycle boundary. ArgoCD can prune generated secrets if it does not recognise a valid owner reference back to the resource that created them. In practice, the generated secret must remain linked to a managed source object or reconciliation can delete it unexpectedly.

Practical implication: verify owner references and resource tracking before relying on any out-of-band secret generator in GitOps.

Threat narrative

Attacker objective: The attacker wants usable credentials that let them move from source control into runtime systems and persistent access.

1. Entry begins when a secret is committed in plaintext or made accessible through a weak encryption and key-handling workflow, which exposes credentials to anyone with manifest access.
2. Escalation follows when those credentials are reused to access Kubernetes workloads, databases, or cloud APIs beyond the original deployment boundary.
3. Impact occurs when reconciliation, rotation friction, or pruning behaviour leaves teams with exposed, stale, or disappearing credentials that break service availability and expand blast radius.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Encryption does not remove the governance burden, it relocates it. Sealed Secrets and SOPS reduce plaintext exposure in Git, but they replace one control gap with another: key custody, resealing discipline, and review visibility. The named concept here is cryptographic workflow friction, where security improves on paper while operational load rises enough to slow rotation and encourage exceptions. Practitioners should read that as a signal that encryption alone rarely scales without process redesign.

External secret stores work only when ownership survives reconciliation. The operator model is sound, but it introduces a dependency on owner references and resource tracking so ArgoCD does not prune generated secrets. This is not a minor implementation detail. It is the difference between a secret being governed as a managed object and a secret being treated as disposable cluster debris.

Centralising secrets is the right direction only if the source of truth is also the source of control. Infisical's pattern shows the value of one control plane for rotation and delivery, but the broader lesson applies across NHI programmes: centralisation without lifecycle linkage just moves sprawl from Git to the operator layer. The practitioner conclusion is to align credential ownership, renewal, and deletion with the same system of record.

ArgoCD exposes the gap between deployment automation and identity governance. Platform teams often assume that if a workload is declared, its dependencies are also governed. Secrets break that assumption because their availability depends on separate policies, credentials, and operators. For IAM and NHI teams, the real task is to make those dependencies explicit before the cluster starts reconciling them away.

From our research:

• 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.
• For deeper context on lifecycle control, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Cryptographic workflow friction: once secret handling depends on resealing, decryption access, and operator tracking, the operational cost of rotation rises fast enough that teams start tolerating stale credentials. The practical result is that GitOps security can look tidy while actual credential lifecycle control gets weaker, which is exactly the kind of gap that NHI programmes need to surface early. For broader control alignment, map the workflow to the OWASP Non-Human Identity Top 10.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026, teams cannot treat plaintext exposure as a rare exception. They need to assume secret sprawl is an operational condition and design around rotation, owner references, and central control.

For practitioners, the next step is to validate whether the deployment layer or the secret source of truth can actually win a delete, resync, or rotation race. If not, the organisation has automation for delivery but not governance for credentials.

For practitioners

• 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. Use a central source of truth for rotation so the same secret is not re-managed in multiple places.
• 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. Review whether the extra review and tooling steps are slowing rotations or forcing exceptions.
• 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. Reconcile a delete and resync cycle to see whether ArgoCD prunes the generated secret unexpectedly.
• Consolidate secret ownership in one lifecycle system Use a single authoritative source to manage secret creation, rotation, and retirement across CI, Kubernetes, and other environments. That reduces drift between the declared manifest and the credential that actually powers the workload.

Key takeaways

• ArgoCD secrets management fails when credentials are treated like ordinary manifests instead of lifecycle-governed identity material.
• Encryption reduces plaintext exposure, but it adds key handling and review friction that can slow rotation and preserve stale access.
• The deciding control is ownership continuity, because generated secrets must stay linked to a governed source or reconciliation will eventually remove them.

Key terms

• GitOps Secret Materialization: The process of turning a declared reference into a live credential at deployment time rather than storing the secret directly in Git. It matters because the control boundary moves from source control to the operator, which changes who owns access, rotation, and deletion.
• 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.
• Cryptographic Workflow Friction: The extra operational burden created when encryption, decryption, key custody, and review steps are inserted into everyday delivery. In secret management, this friction often slows rotation and encourages workarounds, which weakens the security gains the encryption was meant to provide.
• Secret Centralisation: The practice of storing and governing credentials in one authoritative system rather than scattering them across Git, clusters, CI tools, and local files. Done well, it improves rotation and auditability. Done poorly, it simply moves sprawl to another layer.

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

👉 The full Infisical post covers sealed secrets, external operators, and pruning behaviour in more implementation detail.

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.