Learn Secret Management - Dynamic Database Secrets Engine (Short-Lived Credentials)

#Introduction

In episode 3 you stored static secrets in the KV engine — application passwords that remain valid indefinitely. Episode 4 brings a bigger paradigm shift: dynamic credentials. Instead of storing passwords that stay valid for years, OpenBao creates database users and passwords on-demand, with short lifetimes, then revokes them on its own.

This is one of OpenBao's most impactful features, and in this episode you will practice it directly with PostgreSQL or MySQL.

#From Static to Dynamic Credentials

To understand the value of dynamic credentials, first compare the two approaches:

The key point: with dynamic credentials, no password lingers on a server for long. When an application needs database access, it asks OpenBao, gets credentials valid for only a few hours, uses them, and the credentials disappear. If a configuration file leaks into the internet's digital dumpster, the credentials inside are already useless.

#Setting Up the Database

This practice requires a database that OpenBao can manage — meaning OpenBao must have the rights to create and drop roles. In PostgreSQL, set up one dedicated admin user for OpenBao:

CREATE ROLE "bao-admin" WITH LOGIN PASSWORD 'strong-admin-password';
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "bao-admin";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO "bao-admin";

This is the user OpenBao will use to create temporary users. In MySQL, the concept is similar: OpenBao needs a user with CREATE USER, GRANT, and REVOKE privileges. The same principle applies — OpenBao acts as the intermediary that manages credentials on behalf of applications.

#Configuring the Database Connection in OpenBao

First, enable the database secrets engine:

bao secrets enable database
bao secrets list

Then register the connection to your database. This is where OpenBao learns how to reach the database and which admin credentials to use:

bao write database/config/my-db \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/appdb" \
  username="bao-admin" \
  password="strong-admin-password" \
  allowed_roles="my-role"

bao write database/config/my-db stores the connection configuration. The allowed_roles="my-role" part limits which roles may use this connection — important security so that a single connection cannot be used for unauthorized roles. The username and password placeholders inside the URL are replaced automatically by OpenBao.

#Writing Database Roles

Once the connection is registered, create a role that defines the access rights and lifetime of the credentials:

bao write database/roles/my-role \
  db_name=my-db \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
  GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

creation_statements is the SQL that OpenBao executes every time it creates new credentials — note the name, password, and expiration placeholders that OpenBao fills in automatically. default_ttl="1h" sets the credentials to be valid for one hour; max_ttl="24h" limits the maximum renewal to 24 hours.

#Retrieving Dynamic Credentials

When an application needs database access, it simply requests credentials from the role:

bao read database/creds/my-role

OpenBao immediately executes the creation statements in PostgreSQL, creates a temporary user, and returns the result:

Key                Value
---                -----
lease_id           database/creds/my-role/z8lX3e2KcV9WbN...
lease_duration     1h
password           m7xK2pL9qR4sT8vW
username           v-my-role-3fB2dKzL9pR7aA5s

Note three important things from this output:

• username — the temporary user just created in PostgreSQL.
• password — the random password that only works for this user.
• lease_id — the unique identity used to track and revoke these credentials later.

The same credentials are never issued twice: every bao read database/creds/my-role creates a new user with a new password. This is the essence of short-lived credentials — on-demand, unique, and automatically expiring.

#Lease & TTL

Dynamic credentials live within the lease framework: a temporary contract between OpenBao and the consumer. When the lease ends, OpenBao automatically drops the user in the database. This means:

• Without renewal, the credentials disappear after default_ttl (one hour in our example).
• With renewal, there is still the hard max_ttl limit (24 hours).
• With revocation, the credentials can be destroyed instantly — a full discussion of leases, renewal, and emergency revocation is coming in episode 9.

From the application side, a healthy pattern is to request credentials, use them briefly, and let them expire — or request new ones periodically. Never store dynamic credentials in a permanent configuration file, because that would eliminate their entire benefit.

#Conclusion

In this episode 4, you understood the dynamic credentials concept that changes how you think about credentials, configured PostgreSQL and MySQL database connections in OpenBao, wrote database roles with creation_statements, default_ttl, and max_ttl, and retrieved short-lived credentials via bao read database/creds/my-role.

Key takeaways:

• Dynamic credentials break the leak chain — expired temporary passwords are useless to attackers.
• OpenBao needs the right to create roles — prepare a dedicated database admin user for OpenBao.
• TTL is the balancing control — default_ttl sets the lifetime, max_ttl limits renewals.
• The lease ID is the control key — for renewing, revoking, and auditing every credential.

In the next episode, episode 5, we enter the world of the Transit Secrets Engine — Encryption-as-a-Service. OpenBao will handle the encryption and decryption of sensitive data such as national ID numbers, credit card numbers, or health data through its API, without ever storing that data in OpenBao. You will learn to create encryption keys, encrypt data with base64, and decrypt it again — all from a single bao command. See you in episode 5!