OpenBao dynamic database credentials guide

Why teams move from static database passwords to OpenBao dynamic credentials

Static database passwords shared through config files, wiki pages and CI variables leave most teams unable to answer a basic question: who holds this credential right now? The same login often serves a web tier, a batch job and an engineer's laptop, so rotating it means coordinating a change everywhere it was copied. OpenBao dynamic credentials issue a unique database login per request or per workload, with a lease that expires and is revoked automatically. Each login maps to one consumer, so revoking a lease removes one access path without breaking everything that shared the password. The point of this move is to replace a shared secret with short-lived, traceable leases that someone owns.

The model is simple to describe, but the rollout takes more planning. Onboarding is the first hurdle. Every application that reads a static password must change how it obtains credentials, and each team needs an agreed way to authenticate to OpenBao, such as AppRole for servers, Kubernetes for workloads or another method from the auth methods catalogue. Until every consumer has moved, the old static password stays in place, so the database carries two access paths for a period you must plan and time. Ask each application owner for a list of consumers, their authentication method, and whether they request credentials at startup or must refresh them while running.

Lease expiry is where applications most often fail. A connection pool holds sessions opened with a credential that OpenBao later revokes, so when the lease ends the pool must reconnect and request a new login without a restart. Test this with the actual driver and pool library your services use, and confirm how each one handles a credential change during operation. Choose lease durations with each workload's renewal behavior in mind. Short leases increase renewal traffic, while long leases widen the window in which a leaked login stays valid. Confirm the exact lease and renewal settings for your database engine version in the OpenBao documentation before you fix any values.

OpenBao needs its own database account with the privileges to create and drop logins, and that account becomes the most sensitive credential in the design. Scope its privileges tightly, keep its password out of configuration files, and decide who can rotate it and how each rotation is recorded. Lease ownership also needs an explicit rule. Name the team responsible for each database role, the OpenBao policy that grants access to it, and the person who answers when a lease fails. Without these names, revoking access during an incident turns into a search through logs and tickets.

OpenBao lists dynamic secrets for SQL databases among its documented capabilities, alongside leasing with automatic revocation and bulk revocation. Before you commit, confirm in the OpenBao documentation which database plugin and version your engine supports, because supported databases and the statements used to create roles can change between releases. Check the release notes for the minor line you plan to run. Then test credential creation, renewal, expiry and bulk revocation against a non-production copy of your database before any application depends on the engine.

Which OpenBao components make up a dynamic database setup

A dynamic database setup in OpenBao is several cooperating objects, not a single switch. Each one controls a different part of who can request a login, which database account creates it, and how long it lives. Review the components in this order before you connect your first application.

Database secrets engine mount

The database secrets engine is mounted at a path in OpenBao, and every connection and role sits beneath that path. Mount it once per database environment you intend to manage, and choose the path so that teams can read it as a boundary. If the mount is created in the wrong namespace or with the wrong path, applications will request credentials from an endpoint that does not match your policies or documentation.

Connection configuration and privileged account

The connection configuration stores how OpenBao reaches the database and the privileged account it uses to create and drop logins. That account is the most sensitive credential in the design, so give it only the privileges that role creation requires and plan how it is rotated. If it is over-privileged, a leak exposes the whole database, and if it is under-privileged, every credential request fails.

Roles and SQL statements

A role maps a request to the SQL statements that create a login, grant its access, and revoke it later. It also sets the default and maximum lease durations, which determine how long each credential is valid before renewal. Test the creation and revocation statements against a non-production database, because a wrong revocation statement leaves orphaned logins that continue to work after the lease ends.

Auth method for application identity

An auth method lets each application prove its identity and receive its own OpenBao token. AppRole suits servers and Kubernetes or JWT/OIDC suits workloads that already have platform identities. Shared credentials or one token for all services defeat the purpose of per-application credentials, so confirm that each workload authenticates separately before it requests database access.

Policies that scope each identity

Policies decide which database roles each token can read, and they are the main control on who can obtain which database account. Grant read on the specific role path for each application, not on the whole database mount. A broad policy lets one service request credentials for another service's database, and that mistake is hard to see until an audit or an incident.

Namespaces for environment separation

Namespaces divide one OpenBao cluster into isolated areas, such as tenants or environments like staging and production. Put a database mount in a namespace only when its policies, auth methods and administrators should be separated from other areas. Namespaces that are created inconsistently make it unclear which secrets engine a token can reach, so document the namespace layout before you add mounts.

Decisions to settle before building dynamic database roles

This table compares the main design choices for OpenBao dynamic database credentials: how roles are scoped, how servers and workloads authenticate, how lease lengths balance renewal against reconnects, and who manages the connection account. Read each row as a decision point, and treat the last column as the operational cost you accept by choosing that option.

Decision	Option and when it fits	Operational cost
Role scope	One database role per application fits when each service needs its own audit trail and tightly separated grants.	More roles and policies to create, review and keep aligned with schema changes as the number of applications grows.
Role scope	Shared roles per privilege level fit when many services need the same access profile and per-application grants are not required.	Audit logs show a shared role, so attributing a query to one application depends on client-side tagging or other logging.
Workload authentication	AppRole fits servers and long-running services that are not on a platform with its own workload identity.	Secret ID delivery and rotation become your problem, so the bootstrap path must be designed and tested.
Workload authentication	Kubernetes or JWT/OIDC fits workloads that already receive platform identity, avoiding a separate secret to distribute.	Requires configuring trust with the platform issuer and mapping identity claims to roles correctly.
Lease length	Short leases with frequent renewal limit how long a leaked credential stays valid.	Clients must renew on schedule, and renewal failures can cause outages if renewal logic is missing or untested.
Lease length	Longer leases with fewer reconnects reduce renewal traffic and simplify client code for connection pools.	A compromised credential remains usable for longer, and revocation depends on bulk revocation or manual action.
Connection account	Letting OpenBao manage the connection account with rotation removes a standing privileged password from configuration.	OpenBao must itself reach the database with a privileged account, so its own credential and rotation need governance.
Connection account	Keeping the connection account under a separate process fits teams whose database policy requires a different custody path.	The rotation process is outside OpenBao, so its failure modes and audit evidence must be documented separately.
Human access	Route developer and operator access to database credentials through a human login method such as Userpass or identity-based login, not the workload path.	Human access needs its own policies, MFA decisions and review cadence, separate from service identities.

How a dynamic credential is issued, renewed and revoked

A dynamic database credential is a short-lived login that OpenBao creates on request and removes when its lease ends. Understanding the lifecycle matters because your applications, your database administrators and your incident responders each depend on a different step of it. The sequence has five stages: an authenticated identity requests credentials from a role, OpenBao runs the role's creation statements against the database, the client receives a username, a password and a lease, the client renews or re-requests before expiry, and OpenBao revokes the lease by running the revocation statements. The first two stages are where your design decisions sit. The identity that asks for credentials must first authenticate through an auth method, such as AppRole for servers or Kubernetes for pods, and the policy attached to that identity determines which database roles it may read. Each database role holds the creation statements that define what a new database user looks like, including its privileges and how long it lives. Those statements are written by your database team, so the reader should review them as carefully as they would review a schema change. Confirm the exact statement syntax with the OpenBao database secrets engine documentation for the version you run, because the templating options depend on the database plugin in use. Leasing with automatic revocation is the part that changes daily operations. Each issued credential carries a lease. When the lease expires, or when someone revokes it, OpenBao runs the revocation statements, and the database login stops working. An application that still holds an expired password will fail to connect, so expiry is a control, not a warning. Renewal extends a lease within the limits configured for the role and the secrets engine, and a client that cannot renew must request a new credential instead. Exact default lease durations and maximum TTLs should be confirmed in the OpenBao documentation for your release before you set them for production. Bulk revocation exists for incident response. If a credential set, an auth method or a whole role may be compromised, operators can revoke every lease that matches a prefix or mount in one operation, and the database users are dropped through the same revocation statements. Rehearse this path before you need it, because the number of applications that will reconnect at once is a planning input. Your runbook should state who may trigger bulk revocation, how the team confirms it worked, and how services recover. The application side is the most common source of outages. Clients must refresh credentials while they run, without a restart. Build a component that tracks lease expiry, renews early, re-requests on failure, and rebuilds its connection pool with the new credentials while draining the old connections. Test this against a forced revocation in a non-production environment and record how long existing sessions survive, since that behavior depends on your database and driver.

Build sequence for OpenBao dynamic database credentials

This sequence replaces shared static database passwords with credentials that OpenBao issues per application and per login, each with a lease. Every step closes with a check you can run before moving to the next one. The result is a working set of mounts, roles, policies and application changes that can be cut over one application at a time.

Confirm the cluster is ready
The platform team confirms the OpenBao cluster is initialized, unsealed and reachable over TLS from the hosts that will request credentials. Check the health status on each node, confirm the server certificate chain is trusted by client hosts, and confirm the unseal method matches your key custody plan. The step is done when a status query from a client host returns initialized and unsealed, and an HTTPS request completes without certificate errors. If any node is sealed, resolve that first, because no secrets engine can issue credentials while the cluster is sealed.
Enable the database secrets engine
Enable the database secrets engine at a dedicated mount path, such as one per database or per environment, so policies and audit records can target it precisely. The platform team makes this change through the CLI or API with an administrative token that is used only for setup. The check is that the mount appears in the list of enabled secrets engines with the expected path and type. Keep a record of the mount path, because every role, policy and application configuration in later steps refers to it.
Configure the privileged connection account
Create a database account that OpenBao uses only to create and revoke logins, with no rights to read or change application data. Configure a connection in OpenBao that points to this account, including the connection string, TLS settings and the password OpenBao rotates. Confirm the database host accepts the connection from the OpenBao nodes. The check is a connection test in OpenBao that succeeds, followed by a database query showing the account has no grants beyond login management. Record who owns this account, since it is the most sensitive credential in the design.
Define roles with creation and revocation statements
For each application, define a role that contains the SQL statements OpenBao runs to create a login and to revoke it. Scope each role to the schema and privileges that application needs, and no broader. Set default and maximum lease durations that match how long the application runs between restarts. The check is that OpenBao generates a credential for each role with the expected statements, and that a test login has access to the intended schema and nothing else. Review the statements with the application owner before any production use.
Enable auth and bind identities to policies
Enable the auth method chosen for your workloads, such as AppRole for servers or Kubernetes for cluster workloads, then create an identity for each application. Bind each identity to a policy that permits reading only its own database role path and nothing else. Keep the root token out of application configuration. The check is a login with the application identity that succeeds, and a read attempt against another application's role path that is denied. Confirm the policy and identity mapping in writing with the owners of each application.
Test issuance from a non-production client
From a non-production client that carries the same identity as the application, request a credential from its role path. Use the returned username and password to log in to a non-production database, then confirm the login works and the intended privileges apply. Check that the lease appears in the lease list with the expected time to live, and that revoking the lease removes the database login. This test shows the entire issuance and revocation path works before any application depends on it. Keep the test output as evidence for your change record.
Update the application to read and refresh
Change the application so it authenticates to OpenBao, reads a database credential at startup, and uses it for connections. The application must also refresh credentials before the lease expires, and reconnect cleanly when a credential is replaced. Engineers test this behavior in a staging environment with forced lease expiry and forced revocation. The check is that the application keeps serving requests through a refresh cycle, and that logs show new logins and no reuse of revoked credentials. Also confirm the application does not write the credential to disk or to logs.
Cut over one application at a time
Move one application to dynamic credentials in production, monitor it through at least one full lease cycle, and only then move the next. When the cutover is stable, disable the static password for that application's database account and remove it from configuration stores. The check is that the old static password fails to log in, the lease list shows active leases for the new identity, and the static password has been rotated or removed from every place it was stored. Keep the old account in place for a documented rollback period, then retire it.

What drives the effort of a dynamic database credentials rollout

This table lists the factors that move cost and duration in an OpenBao dynamic database credentials rollout, with a practical way to keep each one contained. Read it as a checklist for scoping: the more of these drivers a rollout touches at once, the more work a fixed-scope quote will need to cover. Ask any partner to price against these drivers explicitly.

Driver	Why it changes effort	How to keep it down
Database engines and schemas	Each engine needs its own database secrets engine configuration, connection setup, and role definitions, and each schema adds grants to test.	Start with the engines that hold the most sensitive data and standardize the role pattern across schemas that share an owner.
Number of applications and languages	Every application needs its own role, policy, and auth path, and each language or framework may handle credential renewal differently.	Group similar services and reuse one role template per group instead of writing a bespoke role for each application.
Connection pool behavior	Pools hold connections opened with credentials that expire, so renewal and pool rotation must be designed, not assumed.	Standardize on one client library pattern per language and confirm its pool drain and reconnect behavior early.
Clients that refresh without restarts	Applications that cannot reload credentials need a restart window per lease cycle, which adds coordination with application owners.	Inventory each client's reload capability first and schedule the non-reloading ones as a separate, later wave.
Number of environments	Each environment needs its own OpenBao mounts, roles, network paths, and test evidence, and drift between them is a common source of rework.	Define roles as code and promote the same definitions through environments rather than configuring each by hand.
High availability requirement	An HA cluster adds storage backend choice, failover testing, and backup and restore verification to the scope.	Confirm the availability target with your own operations team before scoping, and treat the HA design as its own workstream.
Identity sources to integrate	Each identity provider or auth method for workloads and operators adds configuration, group mapping, and testing.	Limit the first rollout to one workload auth method for the pilot services and add others in later phases.
Compliance evidence	Assessors usually want documented role design, lease and revocation settings, audit log records, and proof of rotation, which takes time to assemble.	Agree the evidence list with your compliance team and assessor before work starts, then generate it as part of the build.

How the setup changes on a single node, in HA, on Kubernetes and in air-gapped networks

A single node is the fastest way to prove dynamic credentials against one database before you commit to a cluster. The logical design (the database secrets engine, roles, policies and auth methods) matches production, but nothing takes over if the node fails, so the pilot should be a learning environment and should not carry production traffic.

Storage: Use one storage backend on one host. The in-memory backend is useful for throwaway tests, but it does not keep state across restarts, so do not use it to test lease behavior after a restart.
Roles and auth: Userpass is convenient for developer machines in a pilot, but OpenBao recommends AppRole for servers, so use AppRole for the application under test.
Network path: OpenBao holds one connection path to the database and clients reach one address. There is no standby to redirect to, so every client depends on that single endpoint.
Failover: There is none. A restart means unsealing again, and the unseal method you choose for the pilot should match the one you plan for production.

Before you copy this configuration to a cluster, check that a planned restart, a database password rotation and a manual lease revocation behave the way your application team expects.

How to protect the database account and the credentials OpenBao issues

Dynamic database credentials move risk from long-lived passwords to the OpenBao configuration that issues them. The controls below cover the privileged account OpenBao uses, the statements it runs, the transport it uses, who can request credentials, and how you trace and revoke them.

Least-privilege connection account

OpenBao connects to the database with its own account and uses it to create and drop users. This account is the most sensitive credential in the design, so grant only the create, alter and drop rights the configured statements need, and nothing that reads application data. Check that the account is not a superuser or database owner, and write down who can rotate its password and how OpenBao is updated when that happens.

Constrained role creation statements

Each dynamic role is defined by the SQL statements OpenBao runs when it issues a login. Keep those statements narrow: grant only the specific database roles, schemas and privileges the application needs, and avoid grant options and wildcards. Review every creation and revocation statement against the database's own documentation before a role goes live, because a loose statement lets every issued login inherit that breadth.

TLS between OpenBao and the database

The connection carries the connection account's password and the usernames and passwords OpenBao generates, so it must be encrypted and verified. Configure the database to require TLS, have OpenBao validate the server certificate against your internal CA, and reject plaintext fallback. Confirm the setting with the database's own documentation for your engine and version, since parameter names differ between platforms.

Read access to each role's credential path

Any identity allowed to read a role's credential path can obtain a working database login for that role. Write policies that grant each application read access only to the paths for its own roles, and keep platform administrators out of application roles unless required. Review the policies periodically, because a broad wildcard in an older policy quietly widens access as new roles are added.

No root tokens in application configuration

A root token bypasses the policy controls described above and is never needed by an application. Keep root tokens out of application configuration files, container images, environment variables and CI variables. Confirm that the workloads authenticate with AppRole, Kubernetes or another documented method, and that any root token used during setup is revoked once the initial configuration is complete.

Audit device for issuance and revocation

Without an audit device, you cannot tell which identity received a database login or when a lease was revoked. Enable at least one audit device, confirm that it records requests and responses with sensitive values hashed, and send logs to storage that the OpenBao operators cannot silently edit. Test that a single issued credential can be traced from the requesting identity to its revocation.

Bulk revocation plan for incidents

If a credential or host is compromised, you need to revoke many leases at once and keep the application impact predictable. Document which lease prefixes map to which roles, who is authorized to run bulk revocation, and how applications recover once their leases are revoked and they must request new credentials. Rehearse the procedure on a non-production cluster so the steps and their effect on running services are known before an incident.

How to test that dynamic credentials work and fail safely

Before any application is moved off its static database password, the team should run a written test plan that proves dynamic credentials behave as designed in your environment. The tests fall into three groups: identity isolation, credential lifecycle and failure behavior. Each test should name the identity, the database role it is expected to receive, the expected result and the evidence that will be kept. Treat the plan as a deliverable of the onboarding work, not a one-off check run by whoever happens to be available on cutover day.

Start with isolation. For each application identity, request credentials through the database secrets engine and confirm that the issued login maps only to the database role defined for that identity. Then confirm the negative case: the identity should not be able to request a role that belongs to another application, and a token scoped to one path should not read another path's credentials. Once a login is issued, connect with it and attempt both the operations the application needs and a set of operations it should not have, such as schema changes or reads on tables outside its scope. The result should show the intended privileges and nothing more. Record the exact statements tested and the outcome of each.

Next, test the lifecycle. Confirm the lease duration returned at issuance matches the configured default and maximum for the role, and that the database rejects the login once the lease has expired. Renewal needs its own test: run a long-lived client that renews its lease on schedule and verify it stays connected through several renewal cycles, then confirm that a client which stops renewing loses access when the lease ends. Revocation is the control that matters most during an incident, so test a single lease revocation and a bulk revocation for a role or prefix. In both cases, measure whether existing connections are dropped and new logins are refused, and note how long that took in your environment. Ask your database administrator how connection pools handle a dropped login, because pool behavior often determines what the application sees.

Test failure behavior explicitly. Seal a non-production OpenBao node, or make it unreachable from the application network, and observe what the application does with credentials it already holds, what it does when it must fetch new ones, and whether it retries with backoff or fails in a way that floods logs or alerts. Confirm the behavior is what the runbook says. Verify that audit logs record every issuance and revocation with the identity, role and time, and that someone can reconstruct the sequence for a given login from those entries. Finally, document the rollback path to the static password and rehearse it before cutover, including who can restore the old credential, where it is stored and how the application is switched back.

Keep the test results as evidence. Store the plan, the executed steps, timestamps, screenshots or command output, and the audit log extracts in a location your compliance and security teams control. These records support your own internal assessments and any independent audit of the controls. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. The auditor you engage decides what evidence is sufficient. Confirm the required format and retention period with them before testing begins.

What to monitor, back up, upgrade and document after go-live

Once applications receive dynamic credentials, the work shifts from building to operating. Monitoring shows whether leases and database connections behave as designed, backups and upgrades protect the cluster, and a maintained register records who owns each role so incidents and revocations can be handled quickly.

Monitor lease counts and issuance failures

Track the number of active leases for each database role and the rate of failed credential requests from OpenBao. Review both daily during the first weeks after go-live, then weekly once the baseline is stable. A rising lease count can mean applications are not renewing or releasing credentials as expected, and a spike in failures often points to a policy mismatch or an unreachable database. Keep dashboard exports and alert history as evidence of ongoing review.

Watch database connection errors

Alert on failed connections from OpenBao to each database target, because the secrets engine uses its own database account to create and revoke users. Look for authentication failures, TLS errors and connection exhaustion, and separate errors raised by OpenBao from those raised by applications. Record the database account OpenBao uses, its permissions and when it was last rotated, and confirm the rotation approach with your database team. Keep timestamped error logs tagged with the role name involved.

Check audit device health

Confirm that at least one audit device is enabled and writing, and alert when any device reports a failure. Test how your configuration behaves when an audit device fails, since that determines whether requests continue to be served. Verify that audit entries reach your log platform and that credential values do not appear in them. Repeat these checks after every restart and upgrade. Keep the device configuration and a sample of audit entries for each role.

Back up storage and test restores

Back up the storage backend that holds OpenBao data, either integrated storage (Raft) or PostgreSQL, on a schedule written down in your recovery objectives. Restore a copy into a separate environment on a fixed cadence and confirm that the cluster unseals and returns a known secret. The managed database has its own backup process, so restoring OpenBao does not restore the database. After any restore, review the leases it reports, because credentials may no longer match the current database state. Keep restore test records and the unseal procedure used.

Plan upgrades on release lines

Track OpenBao's minor release lines and read the release notes for your running version before scheduling any change. OpenBao v2.7.0 was released on September 23, 2026 and v2.7.1 on October 1, 2026, and v2.6.4 was released the same day for the previous minor line. Test each upgrade against a copy of your storage and database roles, and check whether any role or auth behavior has changed. Keep the release notes, test results and change record for each upgrade.

Document roles, owners and runbooks

Maintain a register with one entry per database role, listing the owning team, the target database, the lease durations and every application bound to the role. Store the revocation runbook beside the register and rehearse it, covering revocation of a single lease, revocation of all leases for a role and emergency revocation for a suspected compromise. Update the register when applications change and at each upgrade. Keep each reviewed register version and the rehearsal notes as evidence.

Questions teams ask before onboarding applications to dynamic credentials

What drives the cost of moving applications to OpenBao dynamic database credentials?

Cost follows the number of databases, applications and access patterns in scope, plus the infrastructure the OpenBao cluster runs on. OpenBao is licensed under MPL-2.0 and has no paid edition, so license fees are not the cost driver. The spend is people and infrastructure.

One-time work: designing roles and policies, configuring the database secrets engine, changing application connection code, testing revocation and cutover.

Recurring work: operating the cluster, on-call response, reviewing roles as applications change, and keeping database and OpenBao versions current.

Ask any partner for a quote that lists each database, each application, whether it needs code changes, and who performs each step.

How long does a first dynamic credentials rollout take?

The timeline depends on how many databases and applications are involved, whether an OpenBao cluster already exists, and how change approvals work in your organization. No general duration applies to every environment, so treat any single number with caution.

The factors that most often extend the schedule are applications that need code changes, database teams that must review role permissions, and production change windows. A common starting point is a pilot with one database and one application, which tests the lease, revocation and failure paths before wider rollout (illustrative approach).

Ask for a written timeline with milestones, the approvals each milestone needs, and the dependencies on your database and application teams.

What do our database administrators, platform owners and developers need to do?

Each group owns a different part of the work, and the rollout stalls if any one of them is missing from planning.

Database administrators define which privileges each generated user needs, configure the connection account that OpenBao uses, and confirm that revocation works in the database.

Platform owners operate the OpenBao cluster, decide the storage backend and high availability design, manage unseal and backups, and own the audit configuration.

Application developers change how services request credentials, handle lease renewal and reconnect after rotation.

Security reviewers approve auth methods, policies, lease durations and the audit trail.

Name an owner for each role before work starts.

Can our team implement dynamic database credentials alone using the OpenBao documentation?

A skilled team can build a small pilot from the OpenBao documentation, particularly the database secrets engine, auth methods and leasing concepts. The documentation explains how each component works, and the current release line is v2.7.x, so check the docs for that version before you start.

The harder parts are outside the reference material: deciding the storage backend and high availability layout, designing roles for many applications, changing application code, testing failover and revocation under load, and hardening the cluster for production. These steps need someone who has run the platform before and a written test plan.

Be honest about staff capacity. If the team cannot staff the platform and application work alongside its normal duties, a fixed-scope partner engagement with written deliverables is one way to close that gap.

How should we handle applications that cannot refresh database credentials?

Start by inventorying which applications cannot re-read credentials without a restart or a code change. Those applications are the main risk in a dynamic credentials rollout, and they need a decision before cutover.

Common options include:

Adding a sidecar or agent that fetches and renews credentials and writes them where the application reads them.
Scheduling a restart during a maintenance window after each credential change, if the lease design allows it.
Changing the application to reconnect on credential failure, which is usually the lasting fix.
Keeping a managed static secret for a short period, with a documented owner and a retirement date.

Each option has operational cost. Confirm with the application owner which option fits, and record the decision in the written scope.

What should a partner include in a written scope for this work?

A written scope should make ownership and acceptance clear before any work starts. Ask the partner to list the following:

Inventory: each database, its version, each application, and its connection method.
Design: auth method per workload, role and policy design, and the lease durations agreed with your security reviewers.
Platform: storage backend, high availability approach and where the cluster runs.
Testing: lease expiry, revocation, failover and application reconnect tests, with pass criteria.
Cutover and handover: the sequence per application, rollback steps, documentation and training.
Exclusions: anything not covered, such as application rewrites or database upgrades.

DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for the same level of detail from any provider.

Does OpenBao revoke database access automatically when a lease ends?

Yes. OpenBao leases dynamic secrets and revokes them automatically when the lease ends, and it supports bulk revocation for incident response. Automatic revocation depends on the database account OpenBao uses having the privileges needed to drop or disable users, so the database team must confirm that before go-live.

Test the full path in a non-production environment: issue a credential, let the lease expire, confirm the database user is removed, and confirm the application fails cleanly and recovers after reissue. Also test a bulk revocation, since that is the action you would take during a suspected compromise.

Record the lease durations you chose and the reason for each, because they set how often applications must renew.

How DeployOpen works on this

DeployOpen scopes OpenBao dynamic database credentials in writing before work starts, then builds the secrets engine, roles and application onboarding inside your own infrastructure. Each engagement ends with documented handover and an optional retainer for ongoing support.

How we scope

Agree the database engines, versions and hosts that will issue dynamic credentials before any build starts.
Map which applications and teams need per-request credentials, and which static passwords are retired.
Record lease durations, revocation behavior and the storage backend in the written scope and deliverables list.

How we build

Configure the database secrets engine with least-privilege creation statements and role-level policies for each consumer.
Test lease issuance, renewal and automatic revocation against a non-production database before cutover.
Onboard each application through its chosen auth method, and confirm that it renews or re-requests credentials correctly.

How we hand over

Deliver runbooks covering role definitions, lease settings, revocation procedures and emergency bulk revocation steps.
Document the application onboarding pattern so your own teams can add new database roles consistently.
Walk through the test evidence with your security and operations staff, and confirm open items in writing.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
Review OpenBao release notes and advise on patches for the minor line you run, before you schedule upgrades.
Confirm the support boundary, response expectations and responsibilities in the retainer agreement before signing.