Keep secrets out of Argo CD's rendering path. The Argo CD documentation strongly recommends populating secrets on the destination cluster with an operator, so that Argo CD never reads them, and strongly cautions against injecting them during manifest generation, because generated manifests are cached in plaintext in Redis.
What are the two approaches?
The Argo CD operator manual describes two ways to populate secrets in GitOps: on the destination cluster, or in Argo CD during manifest generation.
Destination cluster style uses a tool that lives in the cluster. The manual names Sealed Secrets, External Secrets Operator and the Kubernetes Secrets Store CSI Driver as examples, and also lists a Vault Secrets Operator. Git holds a reference or an encrypted object. The operator in the cluster resolves it.
Generation style uses a config management plugin, such as argocd-vault-plugin, to fetch the real value while Argo CD renders manifests.
Why does the documentation prefer the first?
The manual gives two reasons. For security, Argo CD does not need access to the secrets, which lowers the risk of leaking them. For user experience, secret updates are decoupled from application sync operations, so a rotated password is not applied by accident in an unrelated release.
For the generation approach it warns of the opposite. Argo CD needs access to the secrets. It stores generated manifests in plaintext in its Redis cache, so injecting secrets there raises risk. It also says that approach is incompatible with the Rendered Manifests pattern, which it calls increasingly a best practice, and that it will not prioritise new features that only support the generation style.
What if you already use a plugin?
The manual acknowledges many teams do, and that migrating takes effort. It offers advice for reducing risk: the plugin output, including injected secrets, is cached in Redis and is also available through the repo server's gRPC API, so anyone who can reach those can read the secrets. Treat the Redis instance and the repo server as secret stores. Restrict network access to them and consider the transport protection the security chapter describes, such as TLS and mutual TLS for the repo server.
A constructed migration: a team with 40 applications uses a vault plugin. They move one namespace at a time to External Secrets Operator, replace the placeholder in each chart with an ExternalSecret object, confirm the cluster secret appears, then remove the plugin from that application. After the last application moves they can delete the plugin sidecar.
What credentials does Argo CD itself hold?
Argo CD needs credentials to read repositories and manage clusters. The user guide covers HTTPS and SSH credentials, GitHub App credentials, and workload identity for Azure repositories. Prefer short lived, narrow identities such as a GitHub App or workload identity over a personal token, and use credential templates so you do not copy a secret into every repository entry.
The security documentation also states that API authentication uses JSON Web Tokens, that the local admin token expires after 24 hours, and that changing the admin password revokes existing admin tokens. It stores the admin password as a bcrypt hash in the argocd-secret Secret. Prefer single sign on and disable local admin use after setup.
How to check or apply this
- List where each application's secrets come from: operator, plugin or plain Kubernetes Secret in Git.
- Move any plaintext secret in Git to an encrypted or referenced form first.
- Plan migration of plugin injected secrets to a destination cluster operator.
- Restrict network access to Redis and the repo server, and enable the documented TLS options.
- Replace personal access tokens with GitHub App or workload identity credentials.
- Use single sign on, and rotate the admin password so old tokens are revoked.
- Scan manifests and charts in CI so a leaked key is caught before sync.
Quick check
Is it ever acceptable to inject secrets through a plugin?
The documentation says it will keep supporting it but strongly cautions against it. If you must, secure Redis and the repo server API as secret stores.
Where do generated manifests live in Argo CD?
In a Redis cache, in plaintext according to the Argo CD manual, and they are also served by the repo server API.
Sources
Last reviewed: 18 October 2026.
