Argo CD can keep the desired state in Git while the external secret controller fetches sensitive values from the secret manager and writes them into Kubernetes on demand. That separation lets teams reconcile infrastructure declaratively without exposing the raw secret in the repository. The practical result is tighter control, cleaner auditability, and less direct handling of sensitive material.
How Argo CD and external secrets controllers divide responsibility
Argo CD is still reconciling the Kubernetes manifest, but it is not the system that owns secret material. The Git side usually contains a reference to an ExternalSecret, SecretStore, or similar object, while a separate controller resolves the reference and writes the concrete value into the cluster. That means Git tracks intent and structure, while the secret manager remains the source of truth for sensitive data.
This separation is useful because the desired state can be versioned, reviewed, and promoted without embedding raw credentials in the repository. It also means a healthy Argo CD sync does not prove the secret value itself is present, current, or usable, only that the reference and supporting objects match the desired state.
When the reference is synced, the workload usually sees a normal Kubernetes Secret or a projected secret volume after the external controller completes its fetch-and-write cycle. In practice, the deployment can appear “in sync” even while the runtime secret has not yet been refreshed, so operational checks need to distinguish manifest reconciliation from secret material availability.
What changes operationally when the secret lives outside Git
The main change is that secret lifecycle moves out of the application delivery path and into a dedicated secret management path. Instead of updating a secret value in a repo and waiting for GitOps reconciliation, teams rotate or revoke the value in the external manager and let the controller propagate the update. That reduces direct handling of sensitive material, but it also creates a dependency on controller health, namespace permissions, and the secret manager’s availability.
For practitioners, the key question is whether the reference and the value are both being governed correctly. A synced reference can still point to a missing, expired, or inaccessible secret, and an app may fail at runtime even though Argo CD reports success. This is why secret freshness, controller events, and application readiness all need to be observed together.
The most useful mental model is that Argo CD controls configuration convergence, while the external secrets controller controls secret material convergence. Those are related, but they are not the same control plane. In larger estates, that split is often what makes rotation safer and cleaner, because the deployment pipeline never needs to see the raw credential at all.
For background on why that split matters, NHIMG’s Ultimate Guide to NHIs and the Guide to the Secret Sprawl Challenge both explain why keeping secrets out of code and repositories materially improves control and reduces exposure.
Failure modes, drift, and why sync success can be misleading
The common failure is assuming that a green Argo CD sync means the workload now has a valid secret. In reality, the reference may be correct while the external fetch fails because of broken IAM, a bad secret path, a controller outage, a namespace mismatch, or a rotated value that has not yet been materialized. The application may then fail later, at the first real authentication attempt.
Another subtle issue is drift between desired state and runtime state. Argo CD can keep the cluster aligned to the manifest, but the external secret manager can change independently. If rotation happens upstream, the Kubernetes object may lag until the controller refreshes it, so there is a short window where the deployment is “in sync” but the credential is stale.
This pattern also changes incident response. If a secret is suspected compromised, the remediation path is to revoke or rotate it in the external manager, then confirm the controller has repopulated the cluster object and the consuming workloads have reloaded it. That sequence matters because repairing the manifest alone does not remove exposure.
These failure modes are closely related to the risks described in NHIMG’s Top 10 NHI Issues, especially secrets sprawl, excessive access, and lifecycle gaps.
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 address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | External secret delivery is a core non-human secret lifecycle concern. |
| NHI-03 — Overprivileged Access | Secret fetchers and consuming workloads need bounded access to the secret store. | |
| NHI-05 — Lifecycle and Rotation | External secrets introduce refresh, rotation, and revocation timing that must stay controlled. | |
| Recommendation — Manage secret material outside Git and rotate it through the source-of-truth secret store. Restrict controller and workload permissions to the minimum secret paths required. Set refresh and rotation expectations so runtime secrets do not linger after upstream change. | ||
| CIS Controls v8 | 5 — Account Management | Secret access depends on tightly governed service and workload accounts. |
| 8 — Audit Log Management | Controller fetches and secret writes should be auditable for incident and drift detection. | |
| Recommendation — Review and remove unnecessary accounts that can retrieve or consume secret material. Log secret retrieval and write events so refresh failures and abuse are detectable. | ||
| NIST Zero Trust (SP 800-207) | 3 — Continuous Diagnostics and Mitigation | Runtime secret freshness and controller health need continuous verification, not one-time trust. |
| Recommendation — Continuously verify secret delivery, controller health, and workload access before assuming trust. | ||
Practitioner Guidance
What to verify: Confirm that the reference object, the external secret manager path, and the consuming workload all agree on namespace, name, versioning, and refresh behavior. A healthy GitOps sync should be treated as necessary but not sufficient evidence that secret delivery is working.
What to measure: Track secret materialization latency, controller error rates, refresh success, and the age of the last successfully written secret. If those signals degrade, the cluster may still look declarative while authentication failures are building underneath.
Common mistake: Teams often rotate the external secret and assume the application is safe immediately. The real check is whether the controller propagated the new value and whether the workload reloaded it without a manual restart or hidden cache delay.
Practitioner takeaway: Treat Argo CD as the reconciling layer for references, not the authority for secret validity. The real control objective is to keep the reference, the external secret, and the runtime consumer aligned across the full secret lifecycle.
Related resources from NHI Mgmt Group
- When should organisations use external secret stores with runtime references instead of static values?
- What happens when Kubernetes Secrets are managed without external secret storage and auditing?
- What is the difference between rotating a secret and revoking access?
- When does secrets rotation actually reduce NHI risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
