Export data from Google Cloud Secret Manager

How to export your data from Google Cloud Secret Manager starts with what you can read out

If you are facing a renewal, a move off Google Cloud, or a lock-in concern, start by knowing that secret names, labels, version metadata and payloads can all be read through the Secret Manager API and client tools, but only under the permissions of the identity making the call. Google Cloud Secret Manager has no single bulk export button, so leaving means running a set of authorized reads that you script, review and record. Before you build anything, decide which principals will perform those reads, in which projects, and which versions you need to carry over. That decision shapes the rest of the exit plan.

Some things will not leave with the secret values. Workload-side access rules, the IAM bindings that grant services and people permission to read each secret, and the Pub/Sub rotation functions that react to rotation notifications all stay behind. Your OpenBao policies, auth roles and rotation jobs will have to recreate what those bindings and functions did. The export is a controlled read, not a file download: every access is authenticated and authorized against the caller's identity, so the reading identity is also the one whose activity you will need to explain later. Confirm with your team whether Data Access audit logs are enabled for each project in scope, because that determines the evidence you will have for the read operations.

Secrets encrypted with customer-managed encryption keys need extra attention. Reading those payloads also requires the reading identity to use the Cloud KMS key that protects them, so an export account may need permissions beyond Secret Manager itself. Ask the platform team to list every secret that uses customer-managed keys, the key versions involved, and whether any key is scheduled for disabling or destruction during the migration window. Keys that retire early can make some versions unreadable before you have copied them, so resolve that dependency first.

What Secret Manager data you can export and how

This table lists each category of Secret Manager data you need to move, the documented method to read it, the output you get, and the limits to check before you start. Use it to plan a read-only export pass per project, and confirm every quota against Google's current per-project quota page before running large jobs.

Data	Documented method	Output and format	Quota or access limits
Secret names and resource paths	gcloud secrets list, Secret Manager REST API projects.secrets.list, or client library list calls	Secret IDs and full resource names, paged output, easy to script into a mapping file	Confirm list call quotas on the per-project quota page; list calls need the secret list permission
Labels and annotations	gcloud secrets describe or the secrets get call in the REST API	Key-value label pairs attached to each secret, returned as JSON or YAML	Read access follows the same IAM role as the secret metadata; check the quota page for read request limits
Replication settings	gcloud secrets describe, reading the replication field in the REST API	Automatic or user-managed replica locations, plus any customer-managed key reference	Metadata reads are included in the secret read permission; confirm any location-specific limits with Google
Version numbers and states	gcloud secrets versions list or the versions list call in the REST API	Version IDs, creation times and states such as enabled, disabled or destroyed, as JSON	Versions listing is paged; confirm the page size and per-project quota before large sweeps
Secret payloads (active versions)	gcloud secrets versions access, or the versions access call in the REST API or a client library	Raw payload bytes, usually decoded to text or a file, one request per version	Each access is an billable operation and counts against access quotas; check the quota page and plan batches
Payloads of disabled or older versions	Access call on a specific version number, only if the state allows it	Payload bytes for enabled versions only; destroyed versions return no data	Disabled versions cannot be read; decide with the team whether history is needed before export
CMEK-protected payloads	Access calls with the caller holding decrypt rights on the Cloud KMS key	Same payload format, but the call fails if the key is disabled or access is revoked	Confirm key permissions and Cloud KMS quotas with Google before the export window
IAM bindings on each secret	gcloud secrets get-iam-policy or the getIamPolicy call in the REST API	Role and member pairs in JSON, used to map access to OpenBao policies	Requires IAM read permission on each secret; output is a planning input, not a direct import

What does not export and the workaround for each

Secret payloads are only part of what sits in Secret Manager. Access rules, rotation wiring, audit history and encryption keys tie the service to GCP, so each one needs its own replacement or handover plan. The cards below cover what stays behind and how to rebuild or hand it over before the cutover.

IAM bindings and conditions

Secret-level IAM bindings, including any IAM Conditions on time or resource attributes, do not travel with the payload. Each binding grants a principal a role on one secret or project, and none of that maps one-to-one to OpenBao. Export the bindings with gcloud or the IAM API, then write the equivalent OpenBao policies and auth roles for each workload identity. Check that every conditional grant has a matching time limit or path restriction, because a silent gap there is easy to miss. Test each workload against its new policy before you remove the old binding.

Pub/Sub subscriptions and rotation functions

Secret Manager rotation only publishes Pub/Sub notifications on a schedule. The subscriptions, topics and the Cloud Functions or services that consume them are your code, and they stay in the project when you leave. Inventory every topic, subscription and push endpoint attached to a secret, then decide per secret whether OpenBao's database secrets engine or Infisical's rotation will replace it. Plan to disable the old subscriptions only after the new rotation has run successfully at least once. Record which application owns each rotation so no credential expires unnoticed during the switch.

Cloud Logging audit history

Data Access audit logs for secret reads and writes live in Cloud Logging and are not part of the secret payload. Retention follows your log bucket settings, so older entries may expire on their own schedule. Before the cutover, export the relevant log entries to a store you control, such as a SIEM or object storage with immutability, and confirm that Data Access logging was enabled for the Secret Manager service in the periods you need to cover. Ask your compliance lead which records must be kept and for how long, because that answer sets the export window.

CMEK key material in Cloud KMS

When secrets use customer-managed encryption keys, the key material stays in Cloud KMS and cannot be exported as plain bytes. Secret Manager payloads encrypted under that key can only be read while the key is enabled and accessible to the caller. Plan with the key owner to decrypt the payloads in a controlled window, then re-encrypt them under the OpenBao or Infisical root or transit key on the destination side. Confirm who holds the decrypt permission, how the decrypted values are handled in transit, and what happens to the KMS key after the migration, including scheduled destruction.

The export sequence from inventory to verified copy

The sequence moves every secret version out of Secret Manager into a controlled copy that has been checked against the source, so that no version is destroyed until its replacement is confirmed. Each step produces a record that the next step relies on.

Inventory every project and secret
Platform or security engineering lists every Google Cloud project that holds Secret Manager resources, then lists the secrets in each one. Use a dedicated read-only service account for the listing so the inventory itself is logged and attributable. The output is a written inventory of project IDs, secret names and the owning team for each secret. The step is done when the inventory has been reviewed by the application owners and nothing is known to be missing.
Record versions, labels and bindings
For each secret, record every version with its number, state (enabled, disabled or destroyed), creation time, labels and the IAM bindings that grant access. Keep this metadata separate from the payloads so that the mapping to OpenBao paths and policies can be planned before any value is read. The output is a metadata file per project that can be checked against the inventory. The step is done when every secret in the inventory has a metadata record with its version count.
Read enabled payloads under a scoped service account
Run the export with a service account that holds only the Secret Manager accessor role on the specific secrets being exported, and confirm that Cloud Audit Logs record each access. Read the enabled versions within the per-project access quotas, and retry on quota errors rather than widening the account's permissions. Write each payload to the staging location as it is read. The step is done when every enabled version has been read once and the access log entries match the read count.
Store the copy encrypted in a controlled location
Write the exported payloads to a location your security team has approved, encrypted at rest with a key the export account cannot use for anything else, and restrict read access to the migration team for the duration of the project. Keep the metadata file next to the payloads. If a secret is protected with customer-managed encryption keys, confirm that the export identity can still decrypt it before the export starts. The output is an encrypted archive plus a manifest. The step is done when the archive is stored and its access list has been reviewed.
Verify names, version counts and payload hashes
Compare the exported copy with the source. For every secret, check that the name and label set match, that the number of enabled versions matches, and that a cryptographic hash of each payload matches the hash of the value read back from Secret Manager at the same time. Record any mismatch as an exception and investigate it before continuing. The output is a reconciliation report signed off by the owning teams. The step is done when every secret reconciles or each exception has an agreed resolution.
Load and confirm the new store before cutover
Import the verified copy into OpenBao or Infisical and confirm that workloads can read each secret through their new authentication method. Keep Secret Manager running and its versions enabled while workloads are switched and tested. The output is a list of secrets confirmed in the new store, with the workload that reads each one. The step is done when each production workload has read its secrets from the new store in a non-production check and the owning team has agreed the cutover date.
Disable, then destroy, the old versions
Once workloads no longer read from Secret Manager, disable the old versions first so that any missed dependency fails visibly while the value still exists. Destroy them only after a monitoring period your team has agreed. Destroying a version is irreversible, so keep the verified archive under your retention policy before removing anything from Google Cloud. The output is a final record of disabled and destroyed versions, matched to the reconciliation report. The step is done when the destroy log matches the reconciled inventory.

Handling CMEK-protected secrets and per-project access quotas

Secrets protected with customer-managed encryption keys (CMEK) cannot be exported with a plain read permission alone. The identity running the export needs decrypt permission on the Cloud KMS key that wraps the secret, in addition to the Secret Manager accessor role on the secret itself. Before the first run, confirm which secrets use CMEK, which key version protects each one, and which service account or user will perform the reads. Grant the decrypt role on the specific key rather than across a key ring, and record the grant so it can be removed later. Treat the key as part of the migration: do not disable, schedule destruction for, or rotate away the key version until every exported value has been read back from the new store and verified against the source.

Read pacing is the second constraint. Secret Manager enforces per-project quotas on API requests, so a bulk export that loops over every secret and every version can hit throttling errors partway through. Structure the job to list secrets first, then read payloads in controlled batches, and retry throttled or transient errors with exponential backoff and jitter. Log each secret name, version number and result so a failed batch can be resumed without re-reading or double-writing values. Run the export in a window that does not compete with production workloads that read the same secrets at runtime, because those reads draw from the same project quota.

Quota values change and differ by project and by API, so do not plan the export around any number from this page. Open the quotas page for the Secret Manager API in the Google Cloud console, check the current read limits for the project that holds the secrets, and request an increase before the migration window if the planned pace exceeds them. Also confirm whether your organization applies Cloud KMS quotas or organization policies that restrict key use, since those can block decrypt calls even when the Secret Manager permissions are correct. Documenting the quota values and the backoff settings you actually used gives your change record and any later audit evidence a concrete basis.

Choosing an export path by team size and secret count

A small set of secrets, often fewer than a few dozen and mostly owned by one engineer, can be read by hand with the gcloud CLI. This path suits a single application or a pilot before you commit to a migration. The operator needs read access to the specific secrets, not project-wide roles, and should run the commands from a managed workstation rather than a shared jump host.

Named access: Grant the operator roles/secretmanager.secretAccessor on individual secrets only, and remove it when the export ends.
Explicit versions: Read each version by number with gcloud secrets versions access, so the record shows exactly which payload left the service.
Local handling: Write output to an encrypted location, never to chat, tickets or shell history, and delete it after import into the new store.
Audit trail: Record the secret name, version, time, operator and destination. Cloud Audit Logs capture each access event, so keep the export window and the operator identity in your change record.
Limits: This path does not scale past a few secrets and gives no repeatable process for the next team.

Before you start, confirm with your security team which logs they require for secret reads and who approves a manual export.

What to plan before the Secret Manager contract or project ends

Leaving Secret Manager is less a single switch than a sequence of decisions. The cards below cover the choices that determine whether the export is safe, reversible and auditable, from the dual-running period to the final deletion of versions.

Set the dual-running window

Decide how long Secret Manager and the new store will both serve the same secrets. During this period, workloads can fall back if OpenBao or Infisical misbehaves, but every rotation must be written to both places or one will go stale. Write down the start date, the exit criteria and the owner who signs off on moving on. Keep the window short enough that drift between the two stores does not become a second source of truth.

Decide when to disable old versions

Disabling a version in Secret Manager stops it from being served while keeping it recoverable, and destroying it removes the payload. Agree in advance which versions are disabled at cutover, which are kept for a recovery period, and which are destroyed. Record the decision per secret class, since database credentials and signing keys often need different handling than static API tokens.

Retain backups under your own policy

The exported payloads, version metadata and IAM bindings are records your retention policy must cover, not Google's. Store the export in an encrypted location you control, with access limited to named administrators and an expiry date that matches your policy. Confirm with your security and legal teams whether exported plaintext may exist at all, or whether the export should be re-encrypted and held as sealed material.

Notify teams that consume secrets

Every application, pipeline and operator that reads a secret needs to know the new path, the new authentication method and the date the old reads stop. Build the list from audit logs for Secret Manager access rather than from memory, because forgotten consumers are the most common cause of outages at cutover. Send the notice early enough that teams can test in a non-production environment first.

Update CI pipelines and workloads

Build pipelines, Kubernetes manifests, Cloud Run and Compute Engine configurations, and Terraform modules often reference Secret Manager resource names or service account bindings. Inventory each reference, change it in a branch, and deploy to staging before production. Remove the old service accounts only after no job has used them for an agreed period, so that a missed reference does not fail silently.

Confirm billing and retention terms with Google

Ask Google in writing how active secret versions are counted during the overlap, when billing stops after a version is disabled or destroyed, and how long Google keeps audit logs and any deleted secret data on your account. Also confirm whether any committed use or support agreement has notice periods that affect the end date. Terms can depend on your contract and project setup, so rely on the written answers rather than the public pricing page alone.

Deleting versions only after the new store is live

Do not disable or destroy any Secret Manager version until every workload reads from the new store. Before you touch the source, confirm that each service account, Cloud Run revision, GKE workload and CI job has switched to OpenBao or Infisical and has run successfully against it. Check the audit logs for AccessSecretVersion calls against the old project for a period you choose, and treat any remaining caller as a blocker. Schedules, scripts and forgotten batch jobs are the usual cause of surprises, so ask each owning team to confirm in writing which secrets they consume.

Once the cutover is confirmed, keep the Secret Manager versions as a rollback source for a window you set with the application owners, based on how quickly they can detect a fault and how long your change process takes to approve a reversal. During that window, the old versions stay readable, so the rollback path is a configuration change rather than a restore from an export. Disable a version first, which blocks access while keeping the payload recoverable. Destroying a version is a different step. Secret Manager documents that a destroyed version's payload is removed and cannot be recovered, so confirm your export archive and new store contain every version you still need before running it.

Be careful with deleting the whole secret. Removing a secret deletes all of its versions, including the history you may need for an audit or a rollback, so delete only after the retention decision for that history is recorded. Work from an inventory that lists each secret, its version count and its last access time, and sign off on it with the data owner. Ask your compliance lead to confirm how long version history must be retained under your own policies, because that requirement, not the migration schedule, should set the date of final deletion.

Questions teams ask before exporting Secret Manager data

How long does an export from Secret Manager take?

The time depends on the number of secrets, the number of versions you keep, and how many projects and regions are involved, so no single duration applies to every estate. Reading payloads is the slow part, because each version is a separate access operation that counts against per-project quotas. Teams with many small secrets usually spend more time on naming, mapping and verification than on the reads themselves. Before you plan a window, inventory secrets and versions per project, check your quota headroom in the Google Cloud console, and ask any partner to base the timeline on that inventory in the written scope.

Can our team export Secret Manager data without outside help?

Yes, most teams with cloud and platform engineers can script the export, since the Secret Manager API lists secrets, versions and labels and returns payloads for enabled versions. The harder questions are operational: deciding which versions to carry over, mapping names to new paths, and proving that every consumer has been switched. Outside help is most useful when many teams depend on the secrets, when CMEK-protected secrets need a documented key handling plan, or when the audit trail for the move must be defensible. A small internal pilot on non-production projects is a practical way to test the approach first.

What access and infrastructure does an export require?

The export needs a principal with permission to list secrets and versions and to access secret payloads in each source project, plus a target store that is ready to receive them. Typically that means a narrowly scoped, temporary identity, not a standing owner role. If secrets are protected with customer-managed encryption keys, the principal also needs decrypt access to those keys in Cloud KMS, and the key policy must allow it. On the target side, plan the OpenBao or Infisical cluster, its storage and its auth methods before the first write. Confirm the exact IAM roles against Google's current documentation for your organization.

What does a consultant's fixed-scope export cover?

A fixed-scope engagement at DeployOpen is defined in writing before work starts, so the scope, deliverables and timeline are agreed up front. For an export, that typically covers an inventory of secrets, versions, labels and IAM bindings, a mapping to target paths and policies, the transfer procedure, verification steps, and the handover documentation. It does not usually include changing every application that reads the secrets unless that is written into the scope. Ask for a list of what is in and out, the acceptance criteria, and what happens if the inventory turns up more secrets than expected. DeployOpen does not publish a price list, so a quote follows from that written scope.

Does version history survive the move to a new store?

Only if you copy it deliberately, because a new store does not inherit Secret Manager version numbers or their history. You can read each enabled version and write it to the target as a separate version, keeping a record that maps old version numbers to new ones. Disabled or destroyed versions cannot be read, so their history will not carry over. Decide which versions must be retained for rollback or audit, and record that decision in the migration plan. Confirm with your compliance owner how long historical values need to remain available.

How do we prove the copy is complete and correct?

Prove completeness with a reconciliation report, not with a sample check. Generate an inventory from Secret Manager with secret names, version states, label sets and a keyed hash or checksum of each payload, then generate the same inventory from the target and compare them line by line. Keep both reports, the script version and the timestamps as evidence. Only delete source versions after every consumer has been switched and the comparison has passed. Independent auditors and certification bodies decide what evidence satisfies a given control, so ask your assessor which artifacts they expect before you finalize the process.

What happens to CMEK-protected secrets during export?

Customer-managed encryption keys add a dependency on Cloud KMS, so the export must be planned around key access. The principal performing the read needs decrypt permission on the key, and key availability, disabled key versions or scheduled destruction can block the export. Keep the keys enabled until the migration is verified, and record which secrets used which key. Once values are in the new store, they are encrypted under that store's own key hierarchy, so plan how those keys are generated, backed up and unsealed. Confirm the key configuration for each project before scheduling the work.

How DeployOpen scopes and delivers a Secret Manager exit

DeployOpen treats the export from Google Cloud Secret Manager as a fixed-scope engagement with written deliverables, agreed before work starts. We plan, build, test, document and hand over the extraction tooling and evidence inside your own GCP projects and target environment.

How we scope

Inventory of secrets, versions, labels, IAM bindings and replication settings across each project in scope
Quota and access-rate review so the export runs within your per-project Secret Manager limits
Identification of CMEK-protected secrets, their key rings and who controls the decrypt permissions
Written scope, deliverables and timeline agreed with your team before any export work begins

How we build

Export tooling that reads versions and payloads with a service account scoped to the minimum required roles
Mapping file that carries names, labels and version history into the target store without manual retyping
Test runs against non-production secrets to confirm payload integrity, version ordering and label fidelity
Documented handling for secrets that cannot be copied directly, such as CMEK-protected material needing key access

How we hand over

Runbook covering the export steps, rollback path and the order in which workloads switch to the new store
Reconciliation report comparing secret counts, version counts and checksums between source and target
Gated deletion plan for Secret Manager versions, executed only after your sign-off that the new store is live
Written record of access changes, service account removals and audit log locations for your compliance team

How we support

Post-cutover support for workloads that still read from Secret Manager during the transition window
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Confirmation with your team of who owns key custody, retention of audit logs and future secret rotation
Clear quote basis: the written scope sets the effort, so ask us to itemize tooling, testing and handover work

How to export your data from Google Cloud Secret Manager