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.
How to recognise ArgoCD and secret controller drift
The clearest signal is timing: the secret exists immediately after a sync or refresh, then vanishes again after ArgoCD reconciles the cluster state. That pattern usually means ArgoCD is not recognising the secret as a managed outcome, so the external controller and GitOps reconciliation loop are fighting over ownership rather than cooperating.
Another clue is inconsistency across reconciliations. If the controller can re-create the secret, but ArgoCD keeps pruning it or marking it as out of sync, the problem is rarely the secret value itself. It is more often metadata, ownership, or tracking, which is why external secret workflows depend on clear lifecycle rules and stable object references, not just correct payload delivery.
When this happens repeatedly, look for the relationship between the generated secret and the source resource that should govern it. The question is not only whether the secret was produced, but whether ArgoCD can track it as an intended object, preserve it through reconciliation, and avoid deleting a resource that another controller expects to own.
Which configuration mismatches usually cause the symptom
The most common misalignment is missing or incorrect owner references. If the external secret controller creates a child object that ArgoCD does not understand as part of the declared application set, the GitOps engine can treat it as drift and remove it on the next pass. A second common issue is creation policy, especially when the secret is meant to be generated only under certain conditions but the policy does not match the deployment model.
Resource tracking mismatches are just as important. ArgoCD may rely on labels, annotations, or tracking methods that the controller does not preserve consistently. In that case, the secret can exist and still be invisible to the reconciliation logic that decides whether it should remain in the cluster. The result is an object that appears valid to the controller but orphaned to ArgoCD.
Misalignment also shows up when the external controller and ArgoCD disagree about source of truth. If the secret is declared in one place, generated in another, and tracked by a third mechanism, the lifecycle becomes fragile. In practice, that means the deployment may succeed once, but the next sync turns the same object into a conflict.
What this means for GitOps operations and secret governance
At an operational level, this is a lifecycle problem, not just a sync glitch. A generated secret must have a stable ownership model, predictable regeneration behaviour, and tracking metadata that survives reconciliation. If any one of those breaks, teams may see intermittent outages, repeated redeployments, or silent secret churn that is hard to diagnose from the application side.
For practitioners managing secrets through GitOps, the safest approach is to confirm that the secret controller’s output model matches ArgoCD’s tracking model before the workload depends on it. That is why secret management guidance stresses lifecycle clarity, rotation handling, and whether a workload should consume generated material directly or through a more explicit abstraction such as a secret management workflow. NHIMG’s Secrets Management Guide is useful background when you are checking whether the controller is creating the right object in the right way.
Risk and Threat Considerations
Misaligned secret reconciliation is more than an annoyance, because repeated delete-and-recreate cycles can create access instability, failed authentications, and windows where a workload briefly runs without the secret it expects. If the secret is also long-lived or broadly reused, the same misalignment can hide drift, delay rotation, or mask whether a credential has actually been updated.
Failure mechanism: the controller and ArgoCD apply different ownership or tracking rules, so one system recreates the secret while the other prunes it as unmanaged drift.
Impact: workloads may fail unpredictably, secret rotation may not stick, and teams can lose confidence in which controller actually governs secret lifecycle state.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Secret/controller drift is a lifecycle ownership problem for non-human credentials. |
| NHI-02 — Secret Leakage | The topic concerns secret objects and their safe handling through reconciliation. | |
| NHI-06 — Insecure Cloud Deployment Configurations | ArgoCD and an external secret controller can misbehave through cluster config and tracking setup. | |
| Recommendation — Define a single owner for generated secrets and prevent conflicting cleanup or pruning rules. Verify secrets are created, tracked, and rotated without exposure during sync cycles. Align deployment tracking and creation policy so generated secrets are not repeatedly pruned. | ||
Practitioner Guidance
What to verify: confirm the secret’s owner references, labels, annotations, and creation policy are aligned with the exact tracking method ArgoCD uses in that cluster. If the secret appears and disappears on alternate reconciliations, treat that as a control-plane mismatch first, not a content problem.
Decision rule: if the secret is intended to be generated externally, make sure the generated object is either deliberately excluded from pruning or explicitly tracked in the way ArgoCD expects; if it is meant to be declarative, move the ownership boundary back into Git rather than letting two systems compete for it. The practical test is whether one reconciliation cycle can explain the object’s entire lifecycle without manual intervention.
Common mistake: teams often validate only that the secret value is correct, while ignoring whether the object metadata survives reconciliation. In GitOps setups, metadata consistency is the difference between a durable secret and one that is continuously reaped and recreated.
Practitioner takeaway: when a secret keeps reappearing and disappearing, assume an ownership or tracking mismatch until proven otherwise, and validate the lifecycle contract before chasing application-level symptoms.