Argo CD with HashiCorp Vault or OpenBao

A new Vault value reaches the cluster at the next refresh of the operator that owns the Kubernetes Secret. The interval is set in the operator resource: refreshInterval on an ExternalSecret for External Secrets Operator, and the refresh setting on a VaultStaticSecret for Vault Secrets Operator. Each refresh reads the source, compares it with the Secret it already holds, and rewrites the Secret only when the data differs. Shorter intervals increase read load on Vault or OpenBao and on the auth backend, so set them per secret class. Dynamic secrets follow a different path, covered below. Check the field names against the CRD versions you install, because they change between releases. Confirm in the operator status that the last sync succeeded before you rely on a rotation.

Argo CD does not redeploy workloads when a synced Secret changes. It compares manifests rendered from Git with the live state, and a Secret written by an operator is not part of Git, so the application can stay Synced while pods run with old values. Plan the restart explicitly. Common patterns are a reloader controller that watches Secrets and rolls the Deployments that reference them, or an annotation on the pod template that changes when the secret version changes. The annotation approach needs a value that changes with the secret, and you must confirm how your chosen operator exposes that value. Keep the restart trigger out of Git-rendered values where it would cause a diff loop on every sync. Test the full chain once in a non-production cluster.

Environment variables are fixed when a container starts, so a process that reads them keeps the old value until it restarts. Secrets mounted as volumes are refreshed by the kubelet, so files update without a restart, but the application must reopen or reread them. Many applications read configuration once at startup, which makes a mount update invisible to them. Choose the pattern per workload: mounted files with a file watcher or reload endpoint, or environment variables combined with a rolling restart. Confirm for each application whether it rereads its credential file or caches it, and whether a database connection pool keeps old credentials alive after the file changes. Document the choice in the workload's chart so reviewers know how a rotation reaches the process.

Static KV values change only when someone writes a new version, so rotation is a write followed by a sync. Dynamic secrets are generated on request: Vault or OpenBao issues a database user or cloud credential with a lease, and revokes it when the lease ends. Leases have a time-to-live and can be renewed up to a maximum, so the consumer or the operator must renew before expiry or request a new credential. Revocation removes access at the source, which is a stronger control than a long-lived password, but a failed renewal can also cut off a running workload. Ask which secret types your operator supports for dynamic credentials, how it handles renewal failures, and whether the application can accept a new username without a restart. The OpenBao overview describes the lease model.

Rotate Vault or OpenBao auth material on the secret store side and leave the Git manifests unchanged. With Kubernetes auth, the cluster's service account tokens are the credential, and the Vault role binds a service account and namespace to policies. Changing a policy or role does not change any Argo CD manifest. When the review JWT or cluster CA that Vault uses to validate tokens changes, update the auth configuration in Vault directly and verify it with a test login. With AppRole, rotate the secret_id and deliver it to the cluster through a secret that the operator or your pipeline writes, not one committed to Git. Record each change in an audit trail and confirm the operator's next refresh logs in successfully. Edit role names in Git only when the workload's identity actually changes.

Ownership splits across three groups, and the split should be written down before rotation runs. The security or secrets team owns values, Vault policies and dynamic engine settings. The platform team owns operator configuration, refresh intervals, cluster auth roles and the restart mechanism. Application teams own how their code reads the value and whether it reloads. Recurring work includes reviewing refresh settings, checking operator health and testing a rotation after each Vault, operator or Argo CD upgrade. Cost follows the number of secret paths, environments, auth methods and dynamic engines in scope, plus the application changes needed for reload. Ask any partner for a written responsibility matrix and runbook, and for a clear split between one-time build work and ongoing support.

Most rotation failures show up in operator status, Vault audit logs or in pods that never restart. Typical failures include an expired or revoked token, a Vault policy that no longer allows the read path, an unreachable Vault during refresh, a dynamic lease that failed to renew, and workloads still running on the old value. Operators generally keep the last good Secret when a refresh fails, so the cluster keeps running on stale data, which makes alerts on sync status essential. Test in a staging cluster: change a test value, observe when the Secret updates, confirm the pod restarts or reloads, and verify the application uses the new value. Then test failure by revoking the test token and confirming the alert fires. Repeat both tests after each Vault, operator or Argo CD upgrade.

DeployOpen can plan and implement the rotation chain as part of a fixed-scope engagement covering operator configuration, auth roles, refresh and restart design, test cases and a runbook. Scope, deliverables and timelines are agreed in writing before work starts. Scope depends on how many secret paths and environments are involved, which secret engines need dynamic credentials, how many applications need reload changes, and whether high availability or disaster recovery of the secret store is included. Ongoing testing and upgrades can be covered by a retainer. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. To get a quote, prepare a written list of secrets, workloads, environments and auth methods.

Pick the product whose license, support model and feature set match your organization's rules, because both expose the same basic pattern to Argo CD. HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE names IBM as licensor and bars competitive hosted or embedded offerings. IBM completed its acquisition of HashiCorp on February 27, 2025. OpenBao is a community fork under MPL-2.0 managed under the Linux Foundation's OpenSSF. Ask your legal and procurement teams which license terms are acceptable, then confirm the Vault and OpenBao versions you plan to run against the Vault LICENSE file and the OpenBao migration documentation.

No. The integration pattern works with Vault Community Edition binaries and with OpenBao, and the Enterprise decision depends on the features your environment needs. HashiCorp's Vault Enterprise documentation lists features such as performance and disaster recovery replication, HSM support, namespaces, seal wrapping, FIPS compliance and Sentinel policy as code as features that need a license applied to the cluster. Argo CD does not need any of them to read secrets through an operator. Decide based on your recovery objectives, audit requirements and regional footprint, and ask any vendor to confirm in writing which features each option includes.

The main effort drivers are the number of clusters, the number of environments per cluster, the count and shape of secret paths, and the authentication methods you must support. Each cluster usually needs its own Kubernetes auth configuration or JWT trust, and each environment needs a separate path and policy so that a staging workload cannot read production values. Rotation rules, the number of operators you deploy, and whether you need dynamic database credentials all add work. A written scope should list each cluster, environment, namespace group and auth method so the effort can be estimated from named items.

You must provide administrative access to the Vault or OpenBao cluster for policy and auth method configuration, cluster administrator access to install and configure the operators, and ownership of the Git repositories that hold the ExternalSecret or VaultStaticSecret references. Security should approve the secret path layout, the policy model and the rotation schedule before build starts. Platform engineering should confirm the Argo CD version, its SSO setup and the namespaces that will receive secrets. Name one owner for each of these items in the written scope, because gaps in access are the most common cause of delayed handover.

Yes, a capable platform team can build it, provided it has people who know Kubernetes RBAC, Vault or OpenBao policies, and Argo CD sync behavior. The work is mostly configuration, but mistakes in policy scope or auth bindings can expose secrets across environments, so review and testing matter more than the install itself. A partner adds value when the team lacks one of these skills, needs a fixed delivery date, or wants an independent review of the policies and rotation design. Decide by listing the skills in your team and checking them against the scope you write.

Ask the provider to name the secrets engine and auth method for each environment, the operator chosen for each cluster and why, and the exact secret path layout with an example for each environment. The scope should state how cluster authentication works, how tokens or roles are renewed, how rotation is tested without a production outage, and how Argo CD health is checked when a secret refresh fails. Require a list of deliverables such as policies, Kubernetes manifests, runbooks and a verification checklist, plus the acceptance tests and the people responsible for each sign-off. Fixed-scope agreements of this kind are agreed in writing before work starts.

Check whether any secret still reaches Git, the Argo CD Redis cache or the repo-server through a plugin, because those paths are the ones the operator-based approach is meant to remove. Confirm that the Vault or OpenBao auth role for each cluster is limited to the namespaces and service accounts it needs, and that the Argo CD SSO and RBAC settings prevent unauthorized users from changing the secret references. Also confirm the Argo CD version is supported, since only the three most recent minor versions receive patch releases according to the Argo CD release process.