Why move off argocd-vault-plugin and plugin secret injection

Why argocd-vault-plugin is a risk to move off in Argo CD

A team running argocd-vault-plugin or another Config Management Plugin that renders secrets into manifests should move because the secret values are materialized inside Argo CD's own components, and anyone who can reach those components can read them. The question is not whether the plugin works, but where the plaintext lives during reconciliation and who holds access to it. Argo CD stores generated manifests in plaintext in its Redis cache, so any secret injected during manifest generation is available to anyone with access to the Redis instance or the repo-server. The repo-server is also where Helm and Kustomize run against repository content, so the same trust boundary that handles plugin rendering is the one the Argo CD security documentation asks you to control closely.

The effort to move depends mainly on how many applications are rendered by the plugin, how many clusters they target, and how many teams own the placeholder conventions in their manifests. Each plugin-rendered application needs its secret references replaced by a delivery mechanism that runs on the destination cluster, and each one needs its own test pass before the plugin is removed. This document does not give a duration, and we do not publish prices. Ask any partner, including DeployOpen, to scope the migration from an inventory of plugin-rendered applications, the Vault or OpenBao paths they read, and the number of environments that share them. DeployOpen provides fixed-scope quotes from a written scope, so the inventory is the first deliverable to request.

Interim controls matter while the migration is underway. If plugins must keep running for now, the Argo CD secret management guide advises restricting network access to Redis and the repo-server with network policies and considering a dedicated cluster for Argo CD. Confirm with your security team who can exec into those pods, who can read the Redis service, and whether cluster-admin is granted to anyone who can edit Application resources. Those checks define the exposure you carry until the plugin is removed.

What maps cleanly from argocd-vault-plugin and what does not

This table compares render-time injection by argocd-vault-plugin with secret delivery by operators running on the destination cluster. Read each row as a question to answer for your own applications, and treat any row marked for confirmation as open until your team has tested it. The main takeaway is that the Git change flow and the placeholder syntax can often be kept, but where secret values live and how rotation takes effect change.

Area	argocd-vault-plugin (render-time)	Destination-cluster operator
Where secret values live	Values are fetched during manifest generation and pass through the repo-server and Argo CD's Redis cache in plaintext	Values are fetched by an in-cluster controller and stored only as Kubernetes Secrets in the destination cluster
What Git holds	Placeholder references such as Vault paths in manifests, which the plugin resolves at render time	ExternalSecret or similar references, or encrypted or no secret material, depending on the operator chosen
Rotation behavior	A new value appears only after a re-render, so the rotation process must also trigger a sync or refresh	The operator refreshes on its own interval, and workloads may still need a restart or reload to read the new value
Sync and diff behavior	Rendered output includes secret values, so diffs and cached manifests can expose them to anyone who can view the application	Argo CD diffs reference objects, and the Secret is managed outside the Application's rendered manifests, which changes what appears in the UI
Helm values and Kustomize overlays	Values files can keep plugin placeholders if the plugin still runs in your environment; confirm the chosen plugin mode with your team	Plain values files can usually stay if they contain no secret material; secret keys must be moved to reference objects. Confirm with a test render
Application manifests with placeholders	Placeholder syntax is interpreted by the plugin only, so any manifest copied into a non-plugin path will carry unresolved text	Placeholder references must be rewritten into operator resources and the references the workload reads. Plan this per application
Repo-server and Redis exposure	Secrets exist there during rendering, so network policies and cluster isolation become part of the secret boundary	Secret values are not produced by the repo-server, which narrows what that component must be protected against. Confirm with your security review
Ownership and auditing	Vault access is granted to the Argo CD service identity, which may be broader than any single application needs	Access is granted to the operator's service account per namespace; confirm how your team audits and limits this

Destination-cluster options for replacing the plugin

External Secrets Operator runs on the destination cluster and creates Kubernetes Secrets by reading from an external store such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager or Vault. Git holds only ExternalSecret references, which contain paths and keys, not values. Argo CD syncs those references like any other resource, and the operator writes the Secret into the namespace. Plaintext exists in the cluster Secret object and in the external store, but not in Git and not in Argo CD's Redis cache, because the repo-server never sees the value.

Git contents: only ExternalSecret manifests with store references and key names.
Plaintext location: the destination cluster Secret object and the source store.
Refresh: the operator polls the store on a configured interval, so rotation does not require a Git commit.
Access control: protect the SecretStore credentials and restrict who can read Secrets in each namespace.
Health: confirm how sync failures appear in Argo CD health status before relying on them for alerting.

Confirm with your platform team which external stores the operator supports in your environment and which identity the operator uses to read them.

Documented import and export paths for the move

There is no import tool for argocd-vault-plugin configuration, so the move is an inventory of what the plugin does today and a rewrite of the Application sources that depend on it. The documented paths below give the target state for secrets, repository credentials and the surrounding Argo CD settings that the move touches.

Secret management guide as the starting point

The Argo CD secret management guide is the primary reference for why plugin-rendered secrets are risky and what to restrict if a plugin must stay for now. Use it to justify the migration to the team and to define the interim controls. Inventory every Application or ApplicationSet whose source uses a plugin, and record which secret paths each one reads. Plugin-rendered secrets are cached in plaintext until each source is rewritten.

Repository credentials as Kubernetes Secrets

Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap, so repositories must be defined as Kubernetes Secrets. Any repository entry your team still manages in the old ConfigMap must be recreated as a Secret before upgrading. Check that plugin configuration and repository definitions are not stored together, since they are reviewed and rotated differently. Confirm the exact steps for your installed version in the upgrade notes before changing anything.

Inventory of plugin configuration

The plugin has no import tool, so the first deliverable is a written inventory of its configuration: the plugin sidecar or ConfigMap, the placeholder syntax used in manifests, the Vault or cloud paths referenced, and the Applications that call it. Record which teams own each secret path and how each value is rotated today. This inventory becomes the scope for rewriting Application sources and for any later access review.

Application source rewrite

Each Application that relied on plugin substitution needs a source that deploys only the secret reference, such as an ExternalSecret or SealedSecret, and not a rendered value. Rewrite sources in a branch, compare the rendered output with the old output, and confirm that no secret value appears in the diff. Keep the rewrite per application so that one failure does not block the rest of the migration. Plan the cutover order with the teams that own each workload.

Surrounding RBAC and user access

Changing how secrets are delivered changes who can see and change them, so the access model needs review alongside the rewrite. The user management guide recommends disabling the built-in admin user with admin.enabled set to false once local users or SSO are configured. Confirm that only the teams that own a secret path can change the Applications that reference it. Argo CD's SSO and project RBAC should be checked before the move is declared complete.

HA and cache behavior during cutover

The high availability guide describes Redis as a disposable cache and Argo CD as largely stateless, so removing plugin-rendered manifests from the cache is a expected effect of a cutover, not a data loss event. Plan the window so that repo-server and Redis restarts do not interrupt sync for critical applications. HA manifests need at least three nodes because of pod anti-affinity rules, so confirm capacity before scheduling. Check the HA documentation for the sizing and sharding behavior of your version.

Sequence for moving plugin-rendered secrets to destination-cluster operators

This sequence moves each secret out of plugin-rendered manifests and into a controller on the destination cluster, one application at a time, with a comparison step and a rollback path at every cutover.

Confirm the Argo CD release in use
Before any change, the platform team checks the running Argo CD version against the project's release cadence. The release process states that only the three most recent minor versions receive patch releases, so an install on an older minor should be upgraded first. Confirm the current supported minors on the GitHub releases page and record the version in the migration plan. Done when the team has a written version and a decision on whether an upgrade must come before the migration.
Inventory every plugin-using application
The platform team lists each Application and ApplicationSet that uses argocd-vault-plugin or another Config Management Plugin, along with the repo path, the plugin configuration, the Vault or secret store paths it reads, and the cluster it deploys to. Owners of each application confirm the list. Done when the inventory covers every plugin reference found in the Argo CD configuration and each secret path has a named owner and a target store.
Choose a destination operator and pilot namespace
The team selects one destination-cluster operator, such as External Secrets Operator, Vault Secrets Operator or Sealed Secrets, based on where the source secrets live and who can manage the key material. It then picks one non-production cluster and one low-risk namespace as the pilot. Done when the operator is installed on the pilot cluster, the pilot namespace has its own Argo CD Application, and the team has agreed who approves the cutover.
Run the pilot on the non-production cluster
The team replaces the plugin placeholders in the pilot application with references the operator resolves, commits the change through the normal Git review, and syncs it. The pilot checks that the workload starts, that the Kubernetes Secret has the expected keys and that rotation of one test value reaches the cluster. Done when the pilot runs for a period the team sets, with its health and sync status recorded and no secret value present in the rendered manifests of the Argo CD UI.
Run both render paths in parallel
For each remaining application, the team keeps the plugin version and the operator version side by side in a non-production environment. They compare the resulting Kubernetes Secret keys, labels, annotations and workload references, and they check that sync status and health match. Differences are fixed in the operator configuration or the manifests, not by editing live objects. Done when the comparison shows the same workload inputs for every application and each difference has a recorded fix.
Cut over one application at a time
Each application moves in its own change, with a rollback plan written before the change merges. The rollback is a Git revert to the plugin version, which Argo CD syncs back. The team watches sync status, pod health and the secret values the workload reads after each cutover. Done when every application in the inventory runs from operator-managed secrets and each cutover has a recorded verification result.
Decommission the plugin and its Redis exposure
Once no Application references the plugin, the team removes the plugin sidecar or configuration from the repo-server, revokes the Vault or secret store tokens the plugin used, and deletes any stored credentials that were only needed for rendering. The team also reviews network policies around Redis and the repo-server, since manifests cached before cutover may still hold secrets until the cache is cleared. Done when the plugin is absent from the configuration, the old tokens are revoked, and the team has confirmed the cache no longer holds rendered secret values.

Questions teams ask before moving off argocd-vault-plugin

What drives the cost of moving off argocd-vault-plugin?

The cost depends mostly on how many applications render secrets, how many clusters and environments they span, and how much of the secret store design must change. Each application that uses the plugin needs its secret source mapped to a destination-cluster operator, its manifests reworked, and its sync behavior tested. Ask for a quote that lists the applications in scope, the clusters, the secret backends in use, and whether the secret store itself is being reviewed or only the delivery path. Argo CD and the operators are open source, so the recurring cost is mainly the people who keep the configuration running, plus any licensed secret store you already run. No price is published for this work. A quote follows a written scope agreed before work starts.

How long does a move off argocd-vault-plugin take?

Duration scales mainly with application count and the variety of secret patterns. A small set of applications that share one secret path and one backend is simpler than dozens of applications with per-environment paths, templated annotations and mixed credentials. Plan time for an inventory of every application that uses the plugin, a pilot on one non-production application, a rollout in waves, and a cleanup step that removes the plugin configuration from Argo CD once no application depends on it. We do not give a fixed duration here. Ask for a timeline in the written scope, and confirm with your change calendar how many waves your environments can absorb.

What does the platform team need to provide for the migration?

The platform team provides cluster access, an inventory of existing Argo CD applications, the secret backend and its authentication method, and a change window for each environment. Engineers need permission to review Application manifests and to create the operator resources on the destination cluster. Security should confirm where secret values live today and who may read them. Expect the platform team to review each change through its normal Git flow, since moving to operators changes what is committed and what Argo CD renders. Confirm the access model you need before the scope is signed, including whether your Argo CD instance runs with the upgraded RBAC model in the 3.0 upgrade notes.

Can an internal team move off argocd-vault-plugin without a partner?

Yes, an internal team can do the move if it has engineers who know Kubernetes operators, the secret backend, and Argo CD sync behavior, and if it can carve out time for a pilot and a review of each application. The main risks for an internal team are missed applications that still depend on the plugin, drift between old and new secret paths, and sync conflicts when rendered output changes. A partner adds most value when the inventory is large, several clusters must change at once, or the team lacks someone to own the operator design. Whichever route you take, write down the inventory, the test for each application, and the rollback step before you start.

Does the Vault license change affect the choice of secret backend?

It can, so review it before you choose a backend. HashiCorp announced that future releases would move from MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE file names IBM as licensor for Vault 1.15.0 or later. Each version converts to MPL-2.0 four years after publication. Some uses, such as competitive hosted or embedded offerings, are restricted. The change does not stop you from using Vault internally, but your legal team should read the license terms for your use case. OpenBao is a community fork under MPL-2.0 that is managed under the Linux Foundation's OpenSSF, but its migration guide was tested only against Vault 1.14.1 community edition, so test it against your own Vault version. Ask counsel to confirm which license applies to your deployment.

Which secret injection risks should I check before deciding to migrate?

Check where rendered manifests are stored and who can reach them. Argo CD stores generated manifests in plaintext in its Redis cache, so anyone with access to Redis or the repo-server can read secrets injected during rendering. Review whether the repo-server processes untrusted repository content, since it runs Helm and Kustomize on that content. If you must keep a plugin in the meantime, restrict network access to Redis and the repo-server with network policies and consider a dedicated cluster for Argo CD, as the secret management guide advises. Then review which teams can change Application manifests and plugin configuration, because those changes alter what gets rendered.

How do I confirm the migrated secrets stay out of Git and the cache?

Confirm it with a short test on each migrated application. Render the application, then check that the manifests in Git contain only references to secrets, not values, and that Argo CD's cached manifests do not contain secret values. Also check that the operator on the destination cluster creates the Kubernetes Secret with the expected name and namespace, and that a sync from a clean state succeeds. Record the result as evidence for your change review. Keep the test in your pipeline so that a later change that reintroduces plugin rendering fails review.

What usually goes wrong during the move and how to prevent it

Moving off argocd-vault-plugin is rarely blocked by the new operator itself. Problems tend to appear in the gaps: cached output, leftover plugin references, the parallel run, rotation, licensing assumptions and access changes. Each card below names one of these gaps and the check that closes it before cutover.

Secrets left in Redis after cutover

Manifests rendered by the plugin were stored in plaintext in the Redis cache, so the old values can outlive the change that removed the plugin. Clearing the Application's cached state is not enough to assume the values are gone. Before cutover, confirm who can reach the Redis instance and the repo-server, and plan to rotate any secret that was rendered through the plugin while it was active. Treat Redis as disposable in your runbook and verify the restart or flush step in a non-production cluster first.

Plugin references still in Applications

Some Applications may still name a plugin in their source configuration, so they keep rendering secrets through the old path after the rest of the estate has moved. A single leftover reference can keep a plaintext-rendering path alive. Export every Application and ApplicationSet, search for plugin names and placeholder syntax, and confirm each source type before removing the plugin's sidecar or config. Record the search output as part of the change evidence.

Drift during the parallel run

While the plugin and the operator both manage a secret, the rendered manifest and the operator-created Secret can hold different values. Argo CD may then report a healthy application while the workload reads an outdated value. Pick one source of truth per Secret name and namespace before the parallel run starts, and compare the two values on a schedule. Make the cutover a single step that removes the plugin path, not a gradual overlap.

Rotation gaps

Rotation under the plugin usually meant editing the source store and triggering a re-render, which may not reach every consumer. Operator-managed Secrets need their own refresh interval, and workloads often need a restart to read a new value. Map every secret to its rotation trigger, its refresh interval and the workloads that must restart. Test one rotation end to end in staging, including the old value being rejected at the source.

Vault license and edition assumptions

Teams often assume the Vault they call from a plugin is the same product their operator will reach, but the license and edition determine what is available and under what terms. HashiCorp moved future releases to the Business Source License 1.1, and Enterprise features need a license applied to the cluster. Confirm the edition, license terms and support model in writing with your vendor or legal team before choosing an operator path. Do not assume a community fork has been tested against the edition you run.

Access changes after the 3.0 RBAC model

In Argo CD 3.0, update and delete permissions apply only to the Application itself, and reading logs requires an explicit logs, get permission. Teams that depended on broader rights may find that the operators or engineers who ran the plugin path can no longer see or change what they need. Review the RBAC policy against the new model before the move, and test the actions your on-call staff depend on with a restricted test account.

How DeployOpen scopes and delivers the move

DeployOpen plans the move off argocd-vault-plugin as a written, fixed-scope engagement inside your own infrastructure. We map where plugin-rendered secrets reach Redis, the repo-server and Git, then build and document the replacement on the destination cluster.

How we scope

Inventory every Application that uses argocd-vault-plugin or another Config Management Plugin, and every secret it renders.
Map which Redis instances, repo-server pods and network paths can read rendered manifests today.
Agree the written scope, deliverables and timeline with you before any change is made to clusters.

How we build

Choose destination-cluster operators with your team, such as External Secrets Operator or Vault Secrets Operator, based on your secret stores.
Move secrets into per-environment paths and rewrite manifests so Argo CD deploys only references, not values.
Test sync, health and rotation on a non-production cluster, and apply network policies to Redis and the repo-server where plugins remain.

How we hand over

Document the secret layout, operator configuration, authentication from each cluster and the rotation procedure.
Walk your platform and security engineers through the runbook and the remaining exceptions still needing review.
Record which plugin paths were removed, which were retained and why, so your change records stay complete.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Re-check the Argo CD upgrade notes and Config Management Plugin configuration when you move between minor releases.
Confirm with your secret store vendor and auditors which evidence they expect before the final review.

Why to move off argocd-vault-plugin and plugin-based secret injection