What replaces Secret Manager rotation schedules in open source
Secret Manager can trigger rotation on a schedule and publish a Pub/Sub notification, but the code that creates the new credential, updates the target system and cleans up the old one is yours to write and run. In open source, OpenBao's database secrets engine can rotate static database accounts on a schedule, or avoid rotating a shared password altogether by issuing short-lived credentials that expire on their own. Infisical offers secret rotation and dynamic secrets for databases such as PostgreSQL and MySQL. The right choice depends on three things: the database type, whether your applications can fetch credentials at runtime, and how much custom logic the rotation needs.
Start with the database engine. OpenBao's built-in plugins cover Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey, and other types need a custom plugin. Static roles map one OpenBao role to one existing database user and rotate its password on a schedule, which suits legacy applications that cannot change how they read credentials. Static roles are not available for Valkey, so confirm the engine behavior for your database before you design around it. Ask the vendor or check the OpenBao documentation for the exact rotation statements your database version needs.
Then decide how much change your applications can absorb. Dynamic credentials require each workload to request a lease and reconnect when it expires, which means connection pooling and retry logic must be ready before rollout. If an application only reads a file or environment variable, a static role with a scheduled rotation and an agent or sidecar that refreshes the value is the lower-effort path. Plan a test window for rotation failures, and confirm how Infisical's rotation templates handle your target system before you commit, since custom rotation logic in either platform is work your team will own.
Mapping rotation capabilities to open-source options
This table maps each rotation-related capability your team relies on in Secret Manager to what OpenBao and Infisical provide, and marks where the answer depends on the database or secret type. Read the cells as a starting point: confirm each target against the current documentation and a test in your own environment before you plan a cutover.
| Capability | OpenBao | Infisical |
|---|---|---|
| Scheduled rotation of a static database password | Static roles rotate the password of one existing database user on a schedule, for supported database plugins | Rotation is built in for supported targets; confirm the database and secret types in current Infisical docs |
| Short-lived dynamic credentials | Dynamic roles issue database credentials that are revoked automatically when the lease expires | Dynamic secrets for databases such as PostgreSQL and MySQL; confirm version support |
| Database engines covered | Built-in plugins for Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey; other types need a custom plugin | Confirm the full target list for your database versions before relying on it |
| Rotation for Valkey | Gap: static roles are not available for Valkey, so plan another rotation path | Confirm whether Valkey or Redis targets are supported before planning |
| Notification to consumers after rotation | Consumers read the new value from OpenBao or receive a lease; you still decide how workloads reload | Kubernetes operator reloads deployments when secrets change; confirm behavior for other workloads |
| Version history and point-in-time recovery | Versioned key/value storage; confirm version retention settings for your rotated paths | Secret versioning with point-in-time recovery is documented in the README |
| Access control on rotated secrets | Identity-based policies with auth methods such as AppRole, JWT/OIDC and Kubernetes | RBAC, temporary access and approval workflows for machine identities |
| Audit of rotation and reads | Confirm audit device configuration and log destinations in your deployment | Confirm audit log coverage for rotation events in your edition |
Which rotation option fits which workload
Secret Manager gives you rotation notifications, not rotation. The three options below differ in who writes and runs the rotation logic, and that choice drives most of the operating effort. Match each one to the kind of credential, the team that owns it and the skills you can staff.
OpenBao database secrets engine
Use this when database credentials are the main rotation load and you want OpenBao to issue them. Dynamic roles create short-lived database users and revoke them when their lease expires, while static roles map one role to an existing user and rotate its password on a schedule. Built-in plugins cover MySQL, MariaDB and PostgreSQL, among others. Your team must operate the OpenBao cluster itself, including unseal, backups and upgrades. The trade-off is operating effort: confirm your team can run an HA cluster before you retire the Pub/Sub functions.
OpenBao static roles for fixed accounts
Use static roles when an application cannot take a dynamic credential, such as a legacy service account that is hard-coded or referenced by a fixed name. OpenBao rotates the password of the existing database user on a schedule, so the application reads the current value from OpenBao instead of a Secret Manager version. Check that the target database type supports static roles, because Valkey does not. The trade-off is that the account still exists, so access reviews and least privilege work remain your responsibility.
Infisical secret rotation and dynamic secrets
Use Infisical when application teams manage their own secrets through projects and environments and want rotation in the same tool. It includes rotation for supported secret types and dynamic secrets for databases such as PostgreSQL and MySQL, with machine identities authenticating through Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth. Confirm the exact rotation providers you need against the current documentation. The trade-off is licensing: SSO and gateways require an enterprise license under the self-hosting documentation, so price that in before adopting.
Custom rotation functions on an open-source store
Use this when rotation logic is already tested, tied to a particular vendor API, or too specific for a generic engine. You keep your functions and schedule them with your own scheduler, storing the new value in OpenBao or Infisical instead of Secret Manager. This keeps the Pub/Sub-style code you already trust, but your team owns retries, failure alerts, rollback and the test environment. The trade-off is that the rotation code stays yours indefinitely, so budget for maintaining it as APIs change.
How OpenBao rotates static and dynamic database credentials
A static role in the OpenBao database secrets engine maps one OpenBao role to one existing database user. The application keeps using the same username, and OpenBao changes that user's password on a schedule it manages. This is the closest equivalent to a Secret Manager secret that your own Cloud Function rotates, except the rotation logic lives inside OpenBao rather than in code you write and operate. Clients read the current password from OpenBao, so the rotation step does not require redeploying the application that holds the account.
- One user, one role: each static role points at a single pre-existing database account, so the account must already exist and be managed for this purpose.
- Scheduled password change: OpenBao rotates the password of that account on the rotation period configured for the role.
- Read on demand: applications fetch the current credential through the API, so they receive the new value without a code change.
- Engine support: static roles are not available for every plugin, and the documentation lists Valkey as one where they are not offered.
- Your database permissions: the account OpenBao uses to change passwords needs rights in the database, which you should scope and document.
Before migrating, confirm with your database team which plugin you will use, which account OpenBao will manage, and how your applications will handle a password change that happens while a connection is open.
A dynamic role does not rotate an existing account. When a client requests credentials, OpenBao creates a new database user from the role's configured statements and returns it with a lease. When the lease expires or is revoked, OpenBao removes that user. Because each consumer gets its own credential, you can revoke one workload without affecting others, and the question of when to rotate shifts toward how long a lease lasts. The documentation describes this generation and revocation cycle; confirm the exact lease settings for your version before you set policy.
- Generated per request: each client receives a unique database user created from the role definition.
- Automatic revocation: when the lease expires, OpenBao revokes the credential and the database user is removed.
- Bulk and manual revocation: operators can revoke leases in bulk, which supports incident response.
- Built-in plugins: the engine ships plugins for MySQL and MariaDB, PostgreSQL, Cassandra, InfluxDB and Valkey, and custom types can be added through a plugin interface.
- Application changes: applications must request credentials at startup or renew them, so connection handling needs to be designed for this model.
Ask your application owners whether their drivers and connection pools can reconnect cleanly when a lease ends, and whether the database can absorb the account creation load your expected workload will generate.
The database secrets engine covers only the systems it has plugins for. Many secrets that Secret Manager rotates through Pub/Sub notifications, such as third-party API keys, webhook signing secrets, or credentials for systems without a built-in plugin, have no rotation built into the database engine. For those, OpenBao stores and serves the value, but generating the new secret at the provider and writing it back is still work your team must design. The key-value engine keeps version history for these values, which helps with rollback, but it does not contact the provider on your behalf.
- Storage without rotation: the key-value engine stores these secrets, and rotation timing comes from your own scheduler or pipeline.
- Provider-side changes: the new value must be created at the external provider, which the database engine cannot do for you.
- Custom plugins: a database type without a built-in plugin needs a custom plugin built against the plugin interface, which requires development and testing.
- Scheduling outside OpenBao: a cron job, CI pipeline or workflow engine can call the API to write new values, and you own its failure handling.
- Consumer updates: applications that cache secrets need a way to pick up new versions without downtime.
Before you decide, list every secret currently wired to a Pub/Sub rotation function, mark which ones have a supported database plugin, and confirm the owner of each rotation process in writing.
What stays with your team after the switch
Moving rotation into OpenBao or Infisical moves the schedule, not the accountability. The first responsibility that stays with your team is the database permissions behind the rotation account. In OpenBao's database secrets engine, a static role maps one OpenBao role to one existing database user and rotates that user's password on a schedule, so the account the engine connects with must hold the privileges to change passwords for the accounts it manages and nothing broader. Someone on your side still has to decide which database accounts the engine may touch, create that connection account with least privilege, and review those grants whenever the schema or ownership of an application changes. Confirm the exact statements the plugin needs for your database version in the OpenBao database secrets engine documentation before you grant anything.
Second, your teams must test how applications behave when a password changes or a dynamic lease expires. Rotation only succeeds operationally if connection pools reopen with the new credential, long-running jobs fetch a fresh secret, and services do not hold a credential beyond its lease. These behaviors live in your application code and deployment tooling, not in the secrets manager, so a rotation test in a staging environment that restarts real workloads is the only reliable proof. Your team also owns monitoring for rotation failures. Failed password changes, lease renewal errors and sync failures to downstream platforms need alerts routed to the people who can fix them, and someone must decide what happens when a rotation fails halfway, including how to roll back to the previous credential.
Third, your team owns the OpenBao cluster itself: backups of the storage backend, unseal and recovery material, version upgrades and security patches, and the high availability design you choose. Decide which secrets are rotated at all. Some credentials, such as third-party API keys or accounts owned by people outside your team, cannot be rotated without coordination, and rotating them without a plan causes outages. Record the owner, the schedule and the rollback step for each rotated secret. Ask Infisical or your OpenBao support provider, in writing, which of these operational duties their support covers and which remain yours.
Running rotation in open source alongside the rest of GCP
Moving rotation out of Secret Manager does not remove the rest of your Google Cloud estate. Pub/Sub topics, GCP-authenticated workloads, Cloud Logging trails and databases may all keep running during and after the change, and each one affects how OpenBao is connected and audited.
Pub/Sub topics used by others
Secret Manager rotation notifications often share topics or subscriptions with other consumers, such as monitoring jobs, alerting or unrelated functions. Removing the rotation function does not remove the topic. Before retiring anything, list every subscription attached to the rotation topic and confirm which consumers depend on it. Some may need the messages replaced by a job that calls OpenBao directly.
Workloads using the GCP auth method
Workloads on Compute Engine, GKE or Cloud Run can authenticate to OpenBao with the GCP auth method using their attached service account identity, so they no longer need a long-lived key. Confirm which service accounts map to which OpenBao roles, and whether any workload still reads from Secret Manager through its IAM binding during the cutover period.
Cloud Logging for remaining services
Secret Manager access events are recorded in Cloud Audit Logs, which many teams query alongside other GCP services. Once rotation moves to OpenBao, the rotation actions appear in OpenBao's audit device, not in Cloud Logging. Confirm where your security team expects to find rotation and access records, and whether alerts or retention rules must be rebuilt in your SIEM.
Databases that stay on GCP
The OpenBao database secrets engine connects to PostgreSQL, MySQL and other supported databases over the network, so a database hosted on Cloud SQL or on a virtual machine still works if OpenBao can reach it. Confirm network paths, private IP access, and which database roles OpenBao will create, rotate or revoke, and who owns those accounts when they change.
Hybrid ownership of secrets
During the transition, some secrets may still live in Secret Manager while others move to OpenBao, and rotation responsibilities can split between Cloud Functions and OpenBao. Write down which team owns each secret path, which system rotates it, and how a failed rotation is detected and escalated. Unclear ownership is the most common source of stale credentials in mixed estates.
Network reachability and recovery
OpenBao must reach the systems it rotates, and the systems must accept its connections. Confirm firewall rules, VPC routes and egress paths from the OpenBao hosts, and test the path from an isolated network segment. Also confirm how OpenBao cluster state is backed up, since a rotation schedule that cannot reach a database will fail silently until the next expiry.
Migrating Pub/Sub rotation functions to open-source rotation
This sequence moves each rotation schedule from Secret Manager's Pub/Sub triggers and custom functions into OpenBao or Infisical rotation, with the old and new paths proven side by side before any consumer switches.
Inventory every rotation function and schedule
The platform or security team lists each secret that has a rotation schedule, the Pub/Sub topic that receives its notifications, the Cloud Functions or Cloud Run services that act on them, and the function's service account. Start from the Secret Manager console, the gcloud CLI and the function source repositories, because the rotation logic lives in your code rather than in the service. The inventory is complete when every secret with a notification topic maps to one function, one schedule and one owner.
Classify secrets by database type and consumer
For each inventoried secret, record the target system (for example PostgreSQL, MySQL, MariaDB or Cassandra for the database plugins that OpenBao ships), whether the function changes a password for an existing account or creates a new one, and which workloads read the secret. Mark secrets that rotate API keys or certificates, since those need a different mechanism or custom plugin. The output is a classification table that tells you which secrets can move to a database secrets engine role and which need a manual decision.
Stand up OpenBao or Infisical and connect the rotation account
Deploy the chosen platform in a non-production environment, following the OpenBao Helm chart or Infisical's self-hosting options, and configure storage and unseal or key handling for your environment. Create a dedicated database account with only the privileges needed to change passwords or create users, and register it with the database connection in OpenBao or with the rotation settings in Infisical. The step is done when the platform can connect to each target database and report a successful test, with the account's credentials held only inside the secrets platform.
Create static or dynamic roles for each secret
For secrets tied to an existing account, create an OpenBao static role that maps to that database user and sets a rotation period. For workloads that can take short-lived credentials, create dynamic roles that issue a new credential per lease and revoke it at expiry. Use Infisical's rotation or dynamic secret configuration where your team has chosen Infisical. Record each role name against the inventory entry. The step is done when each role issues or rotates a credential in the test environment and the old Pub/Sub function is still untouched.
Run new rotation alongside the old one in non-production
In a non-production environment, let the Pub/Sub function and the new rotation both run for a period your team sets, and confirm that test applications can authenticate after each rotation event. Check for conflicts, such as two actors changing the same password, and disable one path for any secret where they overlap. Confirm that failed rotations surface in your alerting. The step is complete when the team has observed clean rotations through its agreed test window and has written down any password-change conflicts it found and resolved.
Switch consumers to the new secret source
Update each workload to read from OpenBao or Infisical, using the auth method that matches its runtime, such as the GCP auth method for GCP-hosted workloads or Kubernetes for cluster workloads. Move one consumer group at a time, starting with the lowest-impact services, and keep the Secret Manager value in place until each group is confirmed. The step is complete when every consumer authenticates to the new platform, reads its credential from a role, and no workload still depends on a Secret Manager version that the new rotation updates.
Retire Pub/Sub triggers and functions
Once no consumer depends on the old path, disable the Pub/Sub notification subscriptions, remove the rotation functions and their service accounts, and delete the topics if nothing else uses them. Keep the function source in version control for your audit trail. Confirm that the Secret Manager rotation schedule is cleared from each secret. The step is done when the inventory shows zero active notification triggers and zero rotation functions for migrated secrets.
Plan the export of versions and labels separately
Rotation migration does not carry over existing secret versions, labels or IAM bindings. Plan a separate export that captures version history you must keep, label metadata used for ownership or classification, and the IAM policies that governed access, then map these to OpenBao paths and policies or Infisical projects. Ask your compliance lead which records must be retained and for how long. The plan is ready when each category has a named owner and a documented destination, and it runs on its own schedule from the rotation cutover.
Questions buyers ask before replacing Secret Manager rotation
What drives the cost and effort of replacing Secret Manager rotation?
The main drivers are how many database accounts and rotation functions you run today, how many applications read those secrets, and whether you need the new platform to rotate credentials or only to issue them. Secret Manager bills per active secret version, access operation and rotation notification, but the rotation code itself is yours to build and maintain. With OpenBao, the cost shifts to running the servers, storage and backups, plus the work to configure database roles and update applications. Infisical adds a subscription or self-hosting license decision if you need enterprise features such as SSO. Ask any partner for a written quote that separates one-time setup, migration of existing rotation functions, and recurring operations.
How long does the migration take and what sets that time?
The duration depends on the number of database accounts, the number of applications that consume each secret, and how many rotation functions must be retired or replaced. No duration is published in this page's sources, so ask for a timeline in the written scope rather than relying on a general figure. Time is typically spent on mapping roles to existing database users, testing rotation against non-production databases, and scheduling cutovers for each workload. Environments with many consumers or strict change control take longer than a single test database.
What does the team need to provide during the rotation migration?
Plan to provide four things before work starts:
- Administrative access to the target databases so the secrets engine can create or manage accounts.
- Named application owners who can confirm which workloads read each secret and approve changes.
- Change windows for each production cutover, especially for workloads that cannot tolerate a brief credential change.
- Access to the existing Secret Manager projects, IAM bindings and Pub/Sub rotation functions so that current behavior can be documented.
Confirm these requirements with your partner and your own change board before scheduling.
Can an in-house team replace Secret Manager rotation without a partner?
Yes, a capable in-house team can do this, provided it has experience with database administration, identity configuration and change management for production systems. OpenBao's documentation covers the database secrets engine, static roles and dynamic credentials in detail, so the work is largely configuration and testing rather than writing new code. The risks are mostly operational: rotation that breaks a consumer, lease handling that surprises applications, and the ongoing effort of upgrades and backups. Teams that lack spare capacity often bring in an implementation partner for the cutover period and keep operations in-house afterward.
Which databases does OpenBao support for rotation?
OpenBao's database secrets engine ships built-in plugins for Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey. Custom database types can be added through a plugin interface. Dynamic credentials generated from roles are revoked when their lease expires, while static roles map one OpenBao role to one existing database user and rotate its password on a schedule. Confirm that your exact database engine and version are covered by the plugin list in the current OpenBao documentation before committing to a design.
What happens to Valkey static roles in OpenBao?
Static roles are not available for Valkey in OpenBao's database secrets engine. Valkey is still supported through the built-in plugin for dynamic credentials, so teams that need short-lived access can use that path. If your current rotation schedule depends on rotating a fixed Valkey account on a timer, you will need a different approach, such as a custom rotation process or a change to how the application authenticates. Confirm this design choice with your engineers and test it in a non-production environment first.
Does SSO in Infisical require an enterprise license?
Yes, according to Infisical's self-hosting documentation, enterprise features such as SSO or gateways require enterprise licensing. The core secrets, rotation and dynamic secrets features are part of the open-source repository, which is MIT licensed except for content in the ee directory. Before choosing Infisical for SSO-dependent access, confirm the exact license terms and cost for your deployment with Infisical, and ask your partner to include license fees as a separate line in any written quote.
How DeployOpen scopes and delivers rotation migrations
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For teams replacing Secret Manager rotation schedules, we start with an inventory of the credentials that rotate today and the consumers that depend on them, then agree a fixed scope in writing before any work begins.
How we scope
- Inventory every secret that rotates through Pub/Sub notifications and the functions that handle them today
- Classify each credential as dynamic, static-role rotated, or still owned by the application
- Record the agreed scope, deliverables and timeline in writing before any work starts
How we build
- Configure OpenBao's database secrets engine for supported databases such as PostgreSQL and MySQL
- Map each Secret Manager rotation function to a dynamic role or static role, confirming plugin support first
- Test rotation and revocation in a staging environment against each consuming workload before cutover
How we hand over
- Document role definitions, lease settings, policies and the rotation runbook for your operations team
- Provide evidence of tested rotation and revocation paths for your internal and external assessors
- Walk your engineers through lease expiry, failed rotation handling and retirement of old Pub/Sub functions
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Agree upgrade and patch responsibilities for OpenBao and any database plugins in the written scope
- Retest rotation paths after database, OpenBao or application changes that affect credentials
