Google Cloud Secret Manager alternative for multi-cloud and hybrid

Why teams running beyond GCP replace Google Cloud Secret Manager with one self-hosted store

Teams running workloads across GCP, AWS, Azure and on-premises clusters often end up with secrets spread across Google Cloud Secret Manager, AWS Secrets Manager, Azure Key Vault and cluster-level stores such as Kubernetes Secrets. Each store has its own access model, its own audit trail and its own rotation habits, so a question like "who could read the production database password last quarter" takes several consoles and several log formats to answer. A single self-hosted service, either OpenBao or Infisical, can replace those separate stores by authenticating workloads from every environment through one control plane. Secret Manager can remain in place for GCP-native services that depend on it directly, so the decision is about where the consolidated store runs and who controls it, not about removing GCP support.

The choice depends on two requirements that should be settled before any design work. The first is identity: OpenBao documents auth methods including JWT/OIDC, Kubernetes, TLS certificates and AppRole, and Infisical documents Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities. Confirm that each cloud's workload identity can be expressed through one of these methods, and that your platform team can map existing IAM bindings and service accounts onto the new policies. The second is data location: a self-hosted store runs wherever you deploy it, so you decide the region, the cloud account and the network path for every cluster that reads from it. Check whether any regulator or internal policy requires secrets to stay in a specific jurisdiction, and whether a single store spanning clouds would cross that boundary.

Plan for the operating burden before committing. A consolidated store becomes a critical dependency for every environment, so high availability, backups, unseal or key management procedures and upgrade paths need an owner. OpenBao's migration guide describes an in-place path from one Vault Community version, which matters if you already run Vault, but it was tested only against that specific version. Ask any implementation partner, including DeployOpen, to document how the chosen service will be deployed, monitored and recovered in your environments, and keep Secret Manager for GCP-native workloads until that operating model has been tested.

What a multi-cloud secrets service must support

A secrets service spanning several clouds and data centers has to authenticate workloads the way each platform issues identity, apply one policy and audit model, and keep secrets protected and available wherever they run. The cards below set out those requirements and what to check against OpenBao or Infisical before you replace Secret Manager in one environment.

Workload authentication across clouds

Each cloud and cluster already issues workload identity: GCP service accounts, AWS IAM roles, Azure managed identities and Kubernetes service account tokens. OpenBao documents auth methods for Kubernetes, JWT/OIDC, TLS certificates and AppRole, and Infisical documents Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities. Check which method each workload type will use, and confirm in the current documentation whether the GCP and Azure login paths cover your identity types before you plan the cutover.

One policy and audit model

Separate secret stores in each cloud mean separate access rules, separate audit trails and separate rotation habits. A single OpenBao or Infisical instance lets you express who may read which path once, and review access in one place. Ask how audit logs are exported to your SIEM and whether the reviewers who own the policy can read them without access to the secret values themselves.

Encryption before storage

OpenBao encrypts secrets before they are written to the storage backend, so a copy of the data store alone does not expose plaintext values. Confirm where the unseal keys or auto-unseal key material are held, who can operate them, and how that custody maps to your key management policy. Storage encryption protects data at rest; it does not replace controls on the servers and operators that hold the keys.

High availability across sites

OpenBao's active node holds a lock in the data store and standby nodes take over, with integrated storage (Raft) and PostgreSQL as the officially supported HA backends. Map each site to a failure domain, decide whether a second data center can hold a quorum or needs a separate replica, and test failover before any workload depends on the service. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, which affects where you place readers.

An exit path if the license changes

HashiCorp moved future releases of its products to the Business Source License 1.1 in August 2023, while OpenBao remains MPL 2.0 and governed under the Linux Foundation's OpenSSF. Keeping secrets in a self-hosted store under an open license means your exit is an operational move rather than a contract negotiation. Confirm the license of every component you deploy, including the Infisical enterprise directories if you use SSO or gateways.

Which option fits which estate

When most workloads run on Kubernetes, pods should authenticate with their service account instead of a cloud IAM identity. OpenBao documents a Kubernetes auth method, and its Helm chart is the recommended way to install it on Kubernetes, which requires Helm 3.6 or later. Infisical also supports Kubernetes auth for machine identities and ships a Kubernetes operator that delivers secrets to workloads.

OpenBao on the cluster: install with the OpenBao Helm chart, then choose integrated storage (Raft) or PostgreSQL, the two officially supported HA backends.
Infisical operator: the operator syncs secrets into workloads and reloads deployments when values change, which suits teams that want no code changes in their applications.
Multiple clusters: Kubernetes auth works the same way on GKE, EKS, AKS or self-managed clusters, but confirm network paths from every cluster to the secrets server.
Operating load: OpenBao's active and standby nodes need a clear owner for upgrades, backups and unseal procedures.

Confirm which Helm chart and Kubernetes versions you will pin, and whether your intended use of the Infisical operator falls under the free self-hosted features.

OpenBao and Infisical compared against Secret Manager for multi-cloud use

This table compares how OpenBao, Infisical and Google Cloud Secret Manager authenticate workloads across clouds, how access is governed, what each license allows, and where each option falls short. Read the authentication row first, since cloud-specific auth details should be confirmed against each product's own documentation before you commit to a design.

Dimension	OpenBao	Infisical	Keep Secret Manager
Workload authentication across clouds	Documents AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates and tokens. Confirm how GCP, AWS and Azure workload identities map to its auth methods.	Lists Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities. Confirm the exact configuration for each cloud in the current docs.	Authenticates GCP workloads through IAM service accounts. Non-GCP workloads typically need a separate credential path, which you must design and secure yourself.
Access governance	Identity-based policies and namespaces control which paths each identity reads. Policy design and review are your responsibility.	Role-based access control, temporary access, access requests and approval workflows are documented. Confirm which of these need the enterprise license.	Governed by Google Cloud IAM roles bound per secret or project. Cross-cloud access rules must be reconciled with each provider's own IAM.
Licensing	Open source under MPL 2.0, with the project run under the Linux Foundation's OpenSSF. No license fee applies to the software itself.	Core repository is MIT Expat, with content in any ee directory under a separate license. Enterprise features such as SSO or gateways need an enterprise license.	Managed service billed by Google Cloud. Pricing depends on secret versions, access operations and notifications, so check the current published rates.
Operating model and trade-offs	You run the servers, storage, unsealing and upgrades. Confirm the Raft or PostgreSQL storage choice, HA design and backup approach before rollout.	Self-host with Docker, Compose or the Helm chart, which bundles PostgreSQL and Redis. Confirm that these bundled components meet your database and backup standards.	No servers to run and native integration with GCP services. Secrets stay tied to Google Cloud, which adds operational work when workloads run in other clouds or on premises.

When keeping Secret Manager for GCP-native services still makes sense

Keeping Google Cloud Secret Manager is often the right call for workloads that are tightly bound to it through IAM, Cloud Run, GKE or other GCP-native integrations. Those integrations already resolve secrets, apply IAM bindings and audit access without extra components to run. Moving them to OpenBao or Infisical means rewriting how each service fetches credentials, rebuilding access policies and taking on another system's upgrades and availability. Before deciding, list every workload that reads from Secret Manager and mark which ones depend on a GCP-specific mechanism. Those that do are usually the cheapest to leave in place, while the remaining non-GCP workloads are the strongest candidates for consolidation.

Moving only the non-GCP workloads reduces migration scope and risk. Your AWS, Azure and on-premises workloads can authenticate to a self-hosted OpenBao or Infisical instance through their own identities, while GCP workloads keep reading from Secret Manager. A hybrid pattern is also workable: a sync job or controlled read path can copy specific secrets from Secret Manager into the central store when a non-GCP system needs them, though this creates a second copy that must be rotated and revoked in both places. Decide early which system is the source of truth for each secret to avoid divergent values.

Before setting the boundary, confirm three things with your GCP and security teams. First, confirm the data location settings of each Secret Manager secret and whether your data residency rules allow the same secrets to live in a self-hosted store in a different place. Second, check whether any secrets use customer-managed encryption keys (CMEK), since those keys and their IAM grants stay in Cloud KMS and affect what can move. Third, review your current project and API quota usage for Secret Manager so you know whether the remaining GCP workloads will still operate comfortably after the non-GCP reads are removed. Ask Google for the current quota documentation rather than relying on older figures.

How to deploy one secrets service across clouds and clusters

This sequence takes one OpenBao or Infisical service from storage choice to a running, audited deployment that GCP, AWS, Azure and Kubernetes workloads can all authenticate against.

Choose the storage backend and HA layout
The platform team picks where encrypted secret data lives before anything is installed. OpenBao supports integrated storage (Raft), PostgreSQL, PebbleDB and in-memory storage. Integrated storage keeps the cluster self-contained, while the OpenBao storage documentation describes PostgreSQL as an easier backend to operate safely than Raft. For high availability, OpenBao uses one active node that holds a lock in the data store, with standby nodes that forward or redirect requests. Integrated storage and PostgreSQL are the officially supported HA backends. Done when the team has a written decision, the node count and the storage location agreed with the database or infrastructure owners. Confirm the current read scaling behavior for your version in the HA documentation, since standbys can serve read-only operations on Raft and, from v2.7.0, on PostgreSQL.
Install OpenBao or Infisical in your cluster
On Kubernetes, the platform team installs OpenBao with the OpenBao Helm chart, which the project recommends and which requires Helm 3.6 or later. Teams that prefer Infisical can use its official Helm chart, which bundles PostgreSQL and Redis, or Docker Compose for a smaller footprint. Infisical also offers a single container and Linux packages. Install into a dedicated namespace with its own network policy, and keep the chart version pinned. Done when the pods report healthy, the server answers its health endpoint from inside the cluster, and the chart values are committed to version control so the install can be reproduced.
Initialize and unseal the cluster
A security administrator initializes OpenBao and records the unseal material with split custody, so no single person can open the store alone. With Shamir unseal, each node is unsealed separately after restarts, so the runbook must say who holds which key share and how an unseal is authorized. Infisical manages its own encryption keys during setup, so the team confirms in its self-hosting documentation how the encryption key and database credentials are stored and rotated. Done when a test restart of one node is followed by a documented, successful unseal, and the key custodians have signed the procedure.
Enable cloud and Kubernetes auth per environment
The platform team enables an auth method for each environment that needs secrets. OpenBao documents Kubernetes, JWT/OIDC, TLS certificate and AppRole methods, and Infisical lists Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities. Configure one method per trust boundary: for example, a GCP workload identity path for GKE and Compute Engine services, an AWS path for EC2 or EKS, an Azure path for AKS, and a Kubernetes path inside each cluster. Confirm the exact method names and required parameters in the auth documentation for your version before configuring trust. Done when a test workload from each cloud authenticates and receives a token or machine identity limited to its own path, and a workload from one cloud is denied on another cloud's path.
Define policies and roles per team
The security lead and team owners write access policies that match secret paths or projects to the teams that own them. In OpenBao, policies are attached to roles on each auth method, so a workload gets only the paths its role allows. In Infisical, the equivalent is role-based access control per project and environment, with temporary access and approval workflows for elevated needs. Keep production and non-production paths separate, and keep read and write rights apart. Done when the policy set is in version control, each team's role has been tested for allowed and denied paths, and the access review owner is named.
Connect each cloud's workloads
Application teams move workloads from Secret Manager to the new service one environment at a time. Each workload receives the address, the role name for its auth method and the path it needs, usually through the Kubernetes operator or an injecting agent in Infisical, or the OpenBao agent or a direct API call. Where a workload still reads from GCP Secret Manager, keep that read in place until its replacement has been tested. Done when a workload in each cloud has been moved, its secret reads are visible in the audit log under its own identity, and the old Secret Manager access binding for that workload has been removed.
Turn on audit logging and test backups
The platform team enables audit logging on the server, sends the output to the organization's log platform and sets retention to match the policy the compliance lead has agreed. Backups cover the storage backend, such as Raft snapshots or PostgreSQL dumps, and they must be stored separately from the encryption keys. Test a restore into an isolated environment before go-live. Done when the audit events for a test read and a denied read appear in the log platform, and a restored copy in the isolated environment returns the same secret values as the source. DeployOpen can prepare these controls and evidence for a compliance assessment, but independent auditors issue any audit opinion.

Evidence auditors ask for across cloud boundaries

When secrets move from several cloud-native stores into one OpenBao or Infisical service, auditors follow the same questions across every boundary: what secrets exist, who can reach them, how each cloud identity is authenticated, and whether the service can be restored. The cards below list the records that answer those questions. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any attestation.

Inventory of secret paths and owners

Build one register that lists every secret path, the cloud or cluster that consumes it, the owning team and the rotation method in use. Secret Manager names, labels and IAM bindings from GCP, and any equivalent stores in AWS, Azure or Kubernetes, should map to a single path scheme in the new service. Auditors look for orphaned paths with no owner and for secrets that still exist in the old store after cutover. Ask the team to reconcile the register against live listings at each stage of the migration.

Auth method configuration per cloud

Export the configuration for each auth method in use, including GCP, AWS, Azure, Kubernetes and any OIDC or AppRole roles. Each record should show the trusted identity source, the bound service accounts or roles, and the token lifetime. Auditors check that every cloud identity maps to a named role with the narrowest policy it needs. Keep the configuration in version control so changes are dated and attributable.

Policy exports

Export every policy attached to the auth roles and check that it grants only the paths each workload uses. Compare these exports against the IAM bindings that existed in the original GCP projects, since those bindings define what was previously allowed. Record who approved each policy and when it last changed. Policies that grant wildcard paths across clouds are the first thing reviewers flag.

Audit log samples by cloud identity

Collect audit log entries that show reads and writes from each cloud identity, such as a GCP service account, an AWS role, an Azure managed identity and a Kubernetes service account. Samples should prove that each identity reads only its own paths and that denied requests are logged. Confirm with the vendor or your environment team where logs are stored, how long they are retained and who can alter them. Pair the samples with the retention policy your auditors accept.

Backup and restore test records

Keep dated records of backup runs and of restore tests into a separate environment. For OpenBao, the test should cover the storage backend in use, whether integrated storage (Raft) or PostgreSQL, and the unseal procedure, since a backup that cannot be unsealed is not a recovery plan. Record who ran the test, which version was restored and how long recovery took. Ask the implementation partner to document the restore steps as part of the runbook.

License terms in force

Keep a dated copy of the license for each component in the stack and the version it applies to. For example, the OpenBao repository is under MPL-2.0 and Infisical's repository is under the MIT Expat license except for content in ee directories, which carries its own license. Record which features depend on enterprise licensing, such as SSO in self-hosted Infisical. Review these records at each upgrade, because license terms can change between releases.

Questions buyers ask before moving off Secret Manager

How much effort does a multi-cloud secrets migration take?

The effort depends on how many secrets, cloud accounts, clusters and workloads move, and on how much of the current access model you rebuild. No single duration is supplied for this migration, so ask for a scoped estimate built from your own inventory. The main drivers are the number of GCP projects and secret versions in scope, how many workloads read secrets directly through the Secret Manager API, how many AWS, Azure and Kubernetes clusters need new auth paths, and whether rotation runs through Pub/Sub functions you must replace. Teams with clean naming, few projects and mostly static secrets usually finish faster than teams with dynamic credentials and many legacy consumers.

Can our own team migrate off Secret Manager without outside help?

Many teams can, provided they have engineers who already run Kubernetes or Linux services, understand their cloud identity model and can own a Vault-compatible server afterward. OpenBao's migration guide covers an in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, but it was tested only against that version, so a Secret Manager move is a new deployment rather than an upgrade. Ask internally who will operate unseal, backups, upgrades and access policies after go-live. If that ownership is unclear, a fixed-scope engagement can cover planning, implementation, hardening and handover, with ongoing support available as a retainer.

What does the work need from our team?

The work needs decisions and access more than heavy coding. Expect to provide an inventory of secrets, consumers and cloud identities, a named owner for each application team, change windows for workloads, and network paths from each cloud and cluster to the new service. Your security team should define the policies, auth roles and audit requirements before implementation starts. On the infrastructure side, you will need a place to run OpenBao, either on Kubernetes using the OpenBao Helm chart, which requires Helm 3.6 or later, or on virtual machines. Put these inputs in the written scope so the quote reflects the real work.

Can we keep Secret Manager for GCP-native services?

Yes, keeping Secret Manager for services that only run on GCP and integrate natively with it can still make sense. Cloud Run, Cloud Functions and GKE workloads often read from Secret Manager with minimal configuration, and moving them adds work with little benefit when nothing else depends on them. A common split is to keep Secret Manager for GCP-only workloads and use one OpenBao or Infisical service for secrets shared with AWS, Azure, on-premises systems or CI pipelines. The trade-off is two control planes to audit, two sets of access reviews and two places where a secret can drift, so document which store is the source of truth for each secret.

Which cloud auth methods does OpenBao support for multi-cloud workloads?

OpenBao documents auth methods including AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens and username and password, plus login MFA. Cloud identity sign-in such as GCP, AWS and Azure is handled through the auth methods your deployment enables, so confirm the exact cloud methods available in the version you choose before you design the roles. OpenBao recommends Userpass for developer machines and AppRole for servers, which you should reflect in your policy design. Ask for a written mapping from each GCP service account, AWS role and Kubernetes service account to an OpenBao role and policy.

How does the Infisical license affect SSO and gateways?

Infisical's repository is licensed under the MIT Expat license, except content in any ee directory, which uses the separate license in ee/LICENSE. Its self-hosting documentation states that enterprise features such as SSO or gateways require enterprise licensing. Before choosing Infisical, confirm which features you need, read the ee/LICENSE terms with your legal team, and ask the vendor for the current licensing terms for your deployment size. If SSO is a hard requirement, include the license cost in your comparison with OpenBao, which has no separate enterprise tier to buy for basic operation.

Does moving to OpenBao carry licensing risk for us?

OpenBao is licensed under MPL-2.0 and is a Sandbox project of the Open Source Security Foundation under Linux Foundation stewardship. HashiCorp announced on August 10, 2023 that future releases of its products would move to the Business Source License 1.1, while its APIs and SDKs stayed under MPL 2.0. Your risk depends on your use case, so have counsel review the license terms of each component you deploy. Also confirm the support model you need, since OpenBao is community-led and any commercial support must be contracted separately from the project.

What a fixed-scope engagement covers

A fixed-scope engagement covers the full path from a chosen secrets service to a running, documented system inside your own environment. DeployOpen plans, implements, integrates, hardens, backs up and documents OpenBao or Infisical in your cloud accounts, data centers or air-gapped network, so the secrets never leave infrastructure you control. Scope, deliverables and timelines are agreed in writing before any work starts, which means the decisions that drive cost and risk, such as which clouds authenticate to the service, which clusters are in scope and where the storage backend runs, are settled on paper first.

Planning starts with an inventory of the secret stores in use and the workloads that read from them. For each cloud, the written scope should name the auth method to be configured, for example the GCP, AWS, Azure or Kubernetes methods for OpenBao, or the GCP, AWS, Azure and Kubernetes machine identity options in Infisical. Integration covers the policies or roles that map each workload to its paths, the high availability design and the storage backend, with the operating choice between integrated Raft storage and PostgreSQL recorded as a decision. Hardening, backups and the documentation of recovery steps, including unseal or key handling, are listed as deliverables so you can check them at handover. Ask the implementation partner to name each deliverable and the acceptance test for it.

After handover, the work changes shape. Upgrades, vulnerability response, periodic backup restore tests and continuous security testing are typically handled under a retainer, which you should price and scope separately from the initial build. Ask what the retainer includes, how security fixes are applied to your environment and who holds administrative access. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work. Confirm that distinction with your assessor before scoping, and confirm the upgrade path for your current OpenBao or Infisical version against the vendor's release notes.

How DeployOpen deploys one secrets service across your clouds

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a multi-cloud secrets service, that means one OpenBao or Infisical deployment reachable from GCP, AWS, Azure and Kubernetes workloads, with authentication, policies and operations defined once for all of them.

How we scope

Inventory every secret store in use across GCP, AWS, Azure and Kubernetes, including Secret Manager, AWS Secrets Manager and Azure Key Vault.
Agree in writing which workloads move first, which stay on cloud-native stores and which auth methods each cloud needs.
Define hosting location, storage backend, high availability and backup targets before any build work begins.

How we build

Deploy OpenBao or Infisical in your chosen accounts or data centers, with the Helm chart for Kubernetes where that fits your platform.
Configure GCP, AWS, Azure, Kubernetes and approle or OIDC auth methods, mapped to least-privilege policies for each workload group.
Test secret retrieval, lease revocation and failover from each cloud, and record the results for your review.

How we hand over

Document the architecture, auth configuration, policy catalog, backup and restore procedure and upgrade steps for your team.
Walk your platform and security engineers through runbooks for onboarding a new cloud, rotating root material and responding to incidents.
Prepare control mappings and evidence for your compliance assessors, while independent auditors and certification bodies issue any formal reports.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after handover, scoped in writing.
Track new OpenBao and Infisical releases, plan upgrades in a test environment and apply them on a schedule you approve.
Confirm with the vendor whether a feature you need, such as SSO or gateways in Infisical, requires an enterprise license before scoping it.

Google Cloud Secret Manager alternative for multi-cloud and hybrid environments