Migrate from Google Cloud Secret Manager to OpenBao

Migrating from Google Cloud Secret Manager to OpenBao: what the work involves

The move is feasible, and most of the effort is a mapping and cutover exercise rather than a rewrite. Each Secret Manager secret becomes a KV path in OpenBao, each IAM binding becomes an OpenBao policy attached to a role, and each workload switches from reading Secret Manager through its service account to logging in through an auth method. Platform engineering usually leads the cluster and storage design, the security team owns the policy model and the audit logging, and application teams change how their workloads fetch secrets. Your organization may be weighing a renewal, a concern about where secret data is held, or a plan to leave GCP entirely, and in each case the work is similar.

OpenBao is an open-source, community-driven fork of Vault, licensed under MPL 2.0 and managed under the Linux Foundation's OpenSSF as a Sandbox project. Because it is a fork, the operating model will feel familiar to teams that already know Vault, but you still own the servers, storage, unseal process, backups and upgrades. Before you commit, confirm the storage backend (integrated Raft or PostgreSQL), the unseal approach your security policy requires, and the number of nodes you need for high availability. The OpenBao migration guide lists the Vault versions it was tested against, so check your current version against it early.

The main risks are cutover timing, version history and the Pub/Sub rotation functions. Plan a period where both stores serve the same secrets, export version history and labels from Secret Manager with the access quotas in mind, and move workloads one group at a time while watching audit logs. Rotation is the largest rewrite, because Secret Manager only publishes notifications and your own functions do the rotating. Ask any implementation partner for a written scope that lists the secrets inventory, policy mapping, workload changes, rollback steps and handover, and confirm each item against your own environment before work begins.

Which Secret Manager capabilities map cleanly to OpenBao

This table maps each Google Cloud Secret Manager capability to its closest OpenBao equivalent and marks it as clean, needs rework or gap. Read the status as a starting point for planning, then confirm each row against your own environment and a test instance before you assume parity.

Secret Manager capability	OpenBao equivalent	Status and what to confirm
Secrets and numbered versions	KV secrets engine (version 2) with versioned writes and reads	Clean for static values. Confirm how many versions you keep, whether deleted versions must be purged, and how your clients address a specific version.
Labels on secrets	Custom metadata on KV entries, or path segments that encode owner and environment	Needs rework. Labels are not policy inputs in the same way, so move the values you filter or grant on into paths or metadata your policies can match.
IAM bindings per secret	Path-based ACL policies attached to tokens or auth roles	Needs rework. Each Google IAM binding must be rewritten as a policy on a path, and you should verify that the deny and wildcard behavior matches what your teams expect.
Workload access from GCP service accounts	GCP auth method with service account or GCE/GKE identity	Clean for most workloads. Test each workload's identity type and token lifetime, and confirm the role bindings on the OpenBao side.
Pub/Sub rotation notifications	Database secrets engine or custom rotation job calling the target system	Gap for notifications alone. OpenBao does not consume Pub/Sub events, so you must replace the notification-driven functions with its rotation features or your own scheduled job, then test each target.
Customer-managed encryption keys (CMEK)	Seal configuration using a supported external key service, plus storage encryption choices	Needs rework. Key ownership and rotation move to your seal and storage design. Confirm which seal types your OpenBao version supports and who holds recovery keys.
Regional replication and data location	Storage backend placement and cluster topology you choose (integrated storage, PostgreSQL)	Needs rework. You decide where data lives and how replicas are placed. Confirm residency requirements with your compliance team and test failover before cutover.
Quotas on access operations	No equivalent quota model; capacity depends on your servers, storage and load tests	Gap. Load test read volume against your own cluster, and confirm which OpenBao version and storage backend you will run for read scaling.

How secret names, labels and IAM bindings become OpenBao paths and policies

Secret Manager identifies each secret by a flat ID inside a project, and it stores everything else about that secret as labels and IAM bindings. OpenBao has no flat namespace of that kind. Its key/value engine stores secrets at hierarchical paths, and access is decided by policies attached to those paths. The migration therefore starts with a naming decision: choose a path convention such as kv/<application>/<environment>/<secret-name> and write it down before any copy begins. A useful check is to export the list of secret IDs and labels, then group them by application and environment to see whether the existing IDs already encode that structure. Where they do not, a mapping table from old ID to new path is the artifact to review with the application owners. Labels such as team, cost center or data classification have no native equivalent on the secret itself, so decide whether they move into the secret's custom metadata, into the path, or into your inventory system. Confirm with your own governance team which of these labels must survive, because they often drive audit evidence.

Project-level IAM roles translate less directly. A role such as Secret Manager Secret Accessor granted to a service account on a project is a permission set that Google evaluates per request. In OpenBao, you write an ACL policy that lists the paths and capabilities, such as read and list, and then bind that policy to an auth role. For Google Cloud workloads, the GCP auth method can issue tokens to a Compute Engine, GKE or IAM service account identity, and the auth role names which policies that identity receives. Group service accounts by application so that one policy covers one path prefix, and avoid one broad policy that mirrors a project-wide grant. Expect some privileges to have no exact match, such as Secret Manager's management roles that let an administrator change IAM policy on a secret. In OpenBao, those actions belong to a separate, narrowly scoped administrative policy held by a small group. Version history carries over through the key/value engine's versioning, and the engine's per-secret version limit and delete behavior are settings you should confirm against your own retention and recovery requirements before you rely on them.

What to export and which integrations to rebuild

Moving off Secret Manager is two jobs: getting every secret value, version and label out of Google Cloud, and re-pointing each workload that reads them. The cards below cover the export path, the metadata you must preserve, encrypted secrets, and the runtime and pipeline integrations that need new auth paths in OpenBao.

Listing and reading within quotas

Export starts with listing secrets and then accessing each version payload through the Secret Manager API. Access calls count against per-project quotas, so a bulk export should be paced and run from a dedicated service account with only the access it needs. Confirm current quota values in your project's quota page before scheduling the run, and record every version number as you read it so the inventory matches what you later write to OpenBao.

Keeping version history and labels

Secret Manager keeps numbered versions and labels on each secret, and applications may pin a specific version. Decide which versions must move: current values only, or history needed for rollback and audit. Store labels as key-value metadata or in a path convention so owners, environments and data classes survive the move. Note which workloads reference latest versus a pinned number, because a pinned reference breaks if you rename paths during migration.

Handling CMEK-protected secrets

Secrets encrypted with customer-managed keys in Cloud KMS cannot be read once the key is disabled or destroyed, and reading them still needs IAM permission on the key. Plan the export while the key remains usable, and make sure the exported copies are protected by OpenBao's own encryption and unseal design. Ask your security team who approves decryption during the cutover, and confirm the key destruction schedule before deleting any Cloud KMS key.

Cloud Run, GKE and Compute Engine

Each runtime reads secrets through its own service account and mounts or environment variable pattern. Replace those reads with the OpenBao GCP auth method, binding roles to service account identities and then to policies that match the secret paths. For GKE, confirm whether pods currently mount secrets through a CSI driver or an in-app SDK, since that determines the change. Test one workload per runtime before moving the rest.

Cloud Build and deployment pipelines

Cloud Build pipelines often pull secrets at build time with the service account bound to the build. Move each pipeline step to a short-lived OpenBao login, scope its policy to the environment it deploys, and remove IAM bindings that only existed for Secret Manager access. Check that build logs do not print retrieved values after the switch, and that the runner can reach your OpenBao endpoint.

Pub/Sub rotation functions

Secret Manager sends rotation notifications through Pub/Sub, and the rotation logic lives in your own functions. Inventory every subscription and function that handles these events, since they will not fire after the secret moves. Decide whether to rebuild the rotation as OpenBao's database secrets engine issuing short-lived credentials, or to keep a custom job that writes new versions through the OpenBao API. Retire the subscriptions only after the replacement rotates successfully in staging.

Migration sequence from inventory to decommission

This sequence moves secrets, access rules and workloads from Secret Manager to OpenBao one application at a time, so each cutover has a tested rollback path and a documented owner. The end state is a verified OpenBao store with the GCP auth method in use and no remaining reads from Secret Manager.

Inventory secrets, versions, bindings and consumers
Export a list of every secret, its labels, its version history, and the IAM bindings on each secret and project. Map each secret to the workload that reads it, using audit logs and deployment manifests to find consumers you have not documented. The platform team owns the inventory, and application owners confirm their entries. The step is done when every secret has a named owner, a named consumer and a decision on whether its old versions must be carried over. Note that OpenBao's own migration guide describes upgrades from Vault, not imports from Secret Manager, so the copy itself is a custom job you will build and test.
Design OpenBao paths, policies and the GCP auth role
Translate the inventory into a KV path layout that mirrors ownership, such as one mount per team or environment, and write one policy per consumer group that grants only the paths that workload needs. Configure the GCP auth method so service accounts and instances authenticate with their platform identity rather than a stored token. The platform team and security reviewers sign off on the policy set. The step is done when a test identity can read its intended path and is denied on a neighboring path, and the results are recorded as evidence.
Pilot one non-critical workload
Choose one low-risk workload with a single secret and a clear owner. Change its code or sidecar to authenticate through the GCP auth method and read the secret from OpenBao, while keeping the Secret Manager read in place as a fallback. Run it through a full release and a restart. The step is done when the workload runs for a full cycle, its audit entries show the expected identity and path, and the owner confirms the behavior matches the old store. Record any quota, latency or permission surprises before scaling up.
Run a parallel period with dual reads
Migrate the remaining secrets for each application into OpenBao while the workload still reads from Secret Manager. Add a comparison check that reads both stores and alerts on any mismatch, and keep Secret Manager as the source of truth for writes. Track Secret Manager access operations during this period, since reads from both stores count against your usage. The step is done when comparison checks show no mismatches across all migrated secrets and the team has reviewed the access patterns in both stores.
Cut over each application
Switch one application at a time to read only from OpenBao, using a configuration flag so the change can be reverted without a rebuild. Update any rotation consumers, including Pub/Sub subscribers and their rotation functions, to call OpenBao's engines or your replacement job. Confirm that the application has no remaining calls to Secret Manager in its logs or traces. The step is done when each application has run on OpenBao alone for a full release cycle, and the owner signs off that the rollback flag is no longer needed.
Decommission Secret Manager and delete old versions
Once every application has been stable on OpenBao, disable any remaining Secret Manager reads and remove IAM bindings that grant access to the old secrets. Delete old secret versions only after the retention decision agreed in the inventory is met and a restore test from OpenBao succeeds. Then disable or delete the secrets themselves and any Pub/Sub topics used only for rotation. Keep audit records of the deletions for your compliance evidence. The step is done when a final audit shows zero access to Secret Manager and the deletion log is archived with the sign-off record.

How to run both stores in parallel and cut over safely

The safest way to leave Secret Manager is to run both stores side by side for a pilot and move one workload at a time, keeping Secret Manager as the fallback until each service has proven it reads the right values from OpenBao. In practice, the application or its sidecar reads from OpenBao first and falls back to the Secret Manager versions/latest payload only if the OpenBao read fails, and the fallback is logged so you can see how often it fires. Keep the fallback in place only for the pilot window, and remove it in code once the service is stable. Before any workload authenticates, confirm the OpenBao HA design. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and since OpenBao 2.5.0 Raft standbys can serve read-only operations, which matters for read-heavy workloads. Confirm your chosen backend, node count and load balancer behavior in a test environment before production traffic moves.

Switch workloads to the GCP auth method one service at a time, starting with a low-impact service whose owner can verify results. Create a dedicated OpenBao policy per service that grants read on only its own KV path, bind it to the service's GCP identity, and do not reuse one broad role across services. Verify the cutover by comparing the value the workload receives from OpenBao with the Secret Manager version it previously read. Record the Secret Manager version number and the OpenBao secret version for each secret in your migration log, then check that the application reports the same version it was built to expect. Pay attention to secrets that are rotated outside Secret Manager, because a version match alone does not prove the consuming system accepts the new value. Confirm with the owners of downstream systems, such as database accounts and third-party API keys, which credential is authoritative during the overlap.

Define rollback criteria before the first cutover, not during an incident. Reasonable triggers include a sustained rise in OpenBao read errors or latency, failed GCP login attempts from workloads, a version mismatch between expected and delivered secrets, or any unexplained change in the audit trail. Rollback should mean pointing the workload back to Secret Manager through a configuration flag that can be changed without a redeploy, and it should be rehearsed on the pilot service. Keep Secret Manager versions and IAM bindings untouched until every consumer has run on OpenBao for an agreed period and the owners have signed off. Only then disable the Secret Manager access grants, and delete versions last. Ask your team and any external auditor to confirm which evidence they need for the change record, such as the migration log, policy definitions and test results, since the exact controls you must show depend on your own compliance program.

What drives migration cost and duration

This table lists the factors that move the cost and schedule of a move from Secret Manager to OpenBao, with the reason each one matters and how to keep it under control. Read it before asking for a quote, because the scope of each driver is what a written estimate should reflect. Most of the effort sits in inventory, workload changes and audit evidence rather than in the OpenBao install itself.

Driver	Why it changes cost or effort	How to keep it down
Number of secrets and versions	Every secret, and every version you choose to keep, needs a mapped path, a migration step and a verification check. Large version histories add export time and review work.	Decide which versions must move (usually the current and recent ones). Record the rest as retired in the inventory.
Consuming workloads and languages	Each workload that reads Secret Manager through a client library, CLI or environment injection needs a code or configuration change and its own test. Mixed languages and runtimes multiply that work.	Group workloads by access pattern. Move the ones that share one client library together, and confirm which ones only read through a sidecar or operator.
IAM complexity	Secret Manager access is granted through Google Cloud IAM bindings on individual secrets and projects. Each binding must be translated into an OpenBao policy and an auth role, and the mapping is rarely one to one.	Export the bindings first, group identities by the access they need, and write policies per group rather than per binding.
CMEK use	Customer-managed encryption keys add a dependency on Cloud KMS during export and cutover. Teams must confirm how decryption access is granted during the move and who can revoke it afterward.	Confirm with your security team which keys protect which secrets and how the export identity is authorized before scheduling work.
Rotation functions to replace	Secret Manager sends Pub/Sub notifications, so any rotation logic is code your team owns. Each function must be rebuilt as an OpenBao engine configuration, a dynamic credential or a scheduled job, and then tested against the target system.	Inventory every Pub/Sub subscriber and rotation function. Prefer built-in OpenBao secrets engines where they fit, and retire functions that no longer rotate anything.
OpenBao hosting and HA design	The cost depends on where OpenBao runs, how many nodes it has, which storage backend it uses (integrated Raft or PostgreSQL) and how it is unsealed. Each choice adds infrastructure, backup and operating work.	Settle the hosting model, storage backend and unseal method early. Ask the implementer to price each option separately so the trade-offs are visible.
Team skills	Platform and security staff need working knowledge of OpenBao policies, auth methods and storage operations. Gaps in these skills usually extend testing and handover time.	Plan a training period for the operators, and ask whether the scope includes knowledge transfer and runbooks.
Change control and audit evidence	Each cutover step may need an approved change record, test results and proof that access was restricted to the intended identities. Assessors will look for this evidence, and gathering it takes time.	Agree the evidence list with compliance before work starts. Ask the quote to state which change records and logs are delivered.
Quote scope (what to ask for)	A written quote should separate one-time work (inventory, mapping, migration, testing, documentation) from recurring work (upgrades, backups, monitoring, support). Without that split, costs are hard to compare with Secret Manager's usage-based bill.	Ask for line items per driver above, the assumptions behind each one, and the recurring items after cutover. Confirm exclusions in writing.

What usually goes wrong and how to prevent it

Most failed secrets migrations are not failures of the new store. They come from data that did not move completely, access that changed silently, and background jobs that nobody remembered. The cards below cover the risks that tend to surface after cutover, with a prevention step for each.

Losing version history and labels

Secret Manager keeps numbered versions, and applications may depend on a specific one or on labels used for ownership and filtering. An export that copies only the latest payload drops the history that rollback depends on. Before cutover, export every version with its metadata, record the mapping from version number to OpenBao path and version, and confirm with a sample read that old payloads match the source byte for byte.

Workloads pinned to old versions

Some services reference a fixed Secret Manager version such as a numbered version rather than latest. After the move, those references still point at GCP, or they point at a KV path that holds only the newest value. Inventory every consumer, including Terraform, Cloud Run and GKE manifests, and decide per workload whether it reads the current OpenBao version or a pinned one before you switch it.

IAM mapping errors that widen or narrow access

Secret Manager grants access through IAM roles on individual secrets or projects, while OpenBao uses its own policies bound to auth roles. A role that was granted per project may translate into a broad OpenBao policy, and a narrow per-secret grant may be dropped entirely. Map each service account to one OpenBao role with the narrowest path capabilities, then test both allowed and denied reads from every workload identity.

Rotation functions stopping silently after cutover

Secret Manager only publishes rotation notifications to Pub/Sub, so the rotation logic is usually a Cloud Function that someone wrote and maintains. When secrets move, that function may keep running and writing to a secret that no workload reads, or it may simply stop being triggered. List every Pub/Sub subscription tied to rotation, decide whether OpenBao's database secrets engine or dynamic credentials replace it, and alert on any rotation that has not produced a new version.

Storage and unseal design gaps

A self-hosted OpenBao cluster depends on its storage backend and unseal method. Integrated Raft storage, PostgreSQL and the in-memory backend have different operating profiles, and the migration guide describes an in-place upgrade path only from a specific Vault Community version on Raft with Shamir unseal. Confirm the storage backend, backup schedule, unseal key custody and failover test before the first production read, and do not assume a Secret Manager style managed recovery exists.

Deleting Secret Manager versions too early

Once versions are destroyed in Secret Manager, the only copy may be gone, and a rollback to GCP becomes impossible. Teams often clean up as soon as the new store responds, before the last consumer has moved. Keep source versions disabled rather than destroyed for an agreed rollback window, record the decision and its end date in the change ticket, and destroy only after a sign-off that no workload still reads from GCP.

How the migration differs by starting point

A single project with a handful of services is the smallest version of this migration. The inventory fits in one listing, the set of identities that read secrets is short, and most work is mapping a few secret names to OpenBao paths and writing one policy per workload. The main risk is underestimating how many places read the secret, such as a deploy script or a scheduled job that nobody lists in the architecture diagram.

Inventory scope: List every secret and version in the project, then trace each reader through its service account and IAM binding.
Auth setup: Configure one GCP auth method role per service account, using the least privilege that the workload needs.
Path design: Use a simple secret/<service>/<name> layout that mirrors the existing names so the application change stays small.
Parallel run: Keep Secret Manager as the source for a short, defined window while services switch one at a time, then remove the old reads.
Operations: Confirm who will run the OpenBao node, its backups and its unseal process before cutover.

Before you start, confirm with your team how many workloads read Secret Manager directly and which ones only receive values through a deploy pipeline.

Questions buyers ask before moving from Secret Manager to OpenBao

How much effort and cost should we expect to move from Secret Manager to OpenBao?

Expect the cost to come from people and infrastructure more than from software, because OpenBao is licensed under MPL 2.0 and carries no per-secret or per-call fee. The main components are the servers and storage you run, the setup of high availability and backups, the policy and auth design, the migration of secret versions and the workload changes, and the ongoing operation of the cluster. Effort rises with the number of secrets, projects, IAM bindings, CMEK-protected secrets and Pub/Sub rotation functions. Ask any implementation partner for a fixed-scope quote that lists each component, who performs it and what is one-time versus recurring, and ask your own cloud team to confirm the infrastructure costs in your account.

How long does a migration from Secret Manager to OpenBao take?

The timeline is set by the size and shape of your estate rather than by a fixed duration. The main drivers are the number of secrets and versions to read, how many applications and pipelines must switch to the GCP auth method, how many IAM bindings must be mapped to OpenBao policies, whether you run a staged cutover or a single switch, and how many environments (development, staging, production) must be proven first. Any duration should come from a written scope agreed before work starts. Ask for milestones that separate the parallel run, the workload switch and the final deletion of Secret Manager versions.

What does our team need to provide during the migration?

The work depends on decisions only your organization can make, so plan for named owners before work starts. You will need a complete inventory of secrets, labels and the projects and service accounts that read them, a list of who may change each secret, and access to the GCP projects, Kubernetes clusters or CI systems that consume secrets. You also need a place to run OpenBao with its storage backend, a decision on unseal and key custody, and a change window for each workload. Ask your implementation partner to confirm the exact access and approval steps in a written plan.

Can our internal team migrate to OpenBao without outside help?

Yes, a capable internal platform or security team can migrate without outside help, provided it has people who already operate Kubernetes or Linux servers, understand Vault-style policies and can run a high-availability cluster. The OpenBao migration guide documents a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. If your source is Secret Manager rather than Vault, you will be writing a new export and import process. External help is most useful for the design review, the testing of failover and recovery, and the evidence needed for compliance readiness. Confirm the skills gap with your team before choosing a path.

How do we replace Pub/Sub rotation functions when we leave Secret Manager?

Secret Manager only sends Pub/Sub notifications when a rotation is due, so the code that changes the credential has always been yours. In OpenBao, the database secrets engine can issue short-lived credentials on request or rotate static database accounts itself, which removes most of that custom code for supported systems. Services that cannot use those engines will still need a rotation job, which you should rewrite to read and write through OpenBao. Ask for an inventory of every Pub/Sub subscriber and rotation function, then confirm with each owner which target system it updates and how a failed rotation is detected and rolled back.

What happens to version history and labels when we move secrets?

Secret Manager keeps versions and labels as metadata on each secret, and OpenBao does not store them in the same form. The usual approach is to export the current payloads and any version history you need for audit, then recreate them as key/value entries with versions where OpenBao supports them, and record labels as metadata or policy scoping. Plan for reading each payload within your project quotas and handling CMEK-protected secrets, which require the key to remain accessible during export. Old Secret Manager versions should be disabled and destroyed only after the new store is verified in production. Confirm your retention requirements with your compliance owner before deleting anything.

What risks should we check before moving production secrets?

The main risks are an outage during cutover, a secret that is copied incorrectly, an unseal key that is lost, and a policy that grants more access than the IAM binding it replaces. Reduce them with a parallel run in which both stores serve the same secrets, a tested backup and recovery procedure for OpenBao, documented unseal custody, and a review of every policy against the old IAM bindings. Test high availability before go-live, because OpenBao relies on an active node holding a lock and on standbys taking over. Ask your implementation partner to list these checks in the written scope, and to state what evidence they will provide to your auditors.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, hardens, documents and supports self-hosted OpenBao inside your own cloud accounts or data centers. For this migration, we start with a written, fixed scope that maps your Secret Manager inventory to OpenBao paths, policies and GCP auth roles before any workload changes.

How we scope

Inventory secrets, versions, labels, IAM bindings and CMEK-protected entries across the projects in scope
Agree in writing which workloads switch to the GCP auth method and in what order
Define the OpenBao topology, storage backend and where the instance runs in your environment
Document which Pub/Sub rotation functions are retired, replaced or kept, with owners named

How we build

Deploy OpenBao in your infrastructure, including the Helm chart route where Kubernetes is the target
Map secret names and labels to KV paths and IAM bindings to least-privilege OpenBao policies
Read versions within your Secret Manager access quotas, with batching and retries agreed up front
Test each switched workload in a non-production environment before cutover, and record the results

How we hand over

Deliver runbooks for unseal, backup, upgrades and access requests, written for your own operators
Provide a cutover log listing each workload, its auth role and the verification performed
Hand over the policy set, configuration and rotation design as code in your repositories
Agree a retirement plan for Secret Manager versions once the new store has run in production

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover OpenBao version upgrades, such as tracking releases published on the project's GitHub page
Confirm response expectations and maintenance windows in the written scope, not in this page
Ask us to scope post-migration security testing of the OpenBao deployment if your policy requires it