Deploy PostgreSQL on OpenShift, configure OpenBao database engine for dynamic credential generation, and deploy a sample application that uses the OpenBao Agent sidecar to automatically inject rotated database credentials.
Prerequisites checklist
Confirm these before running steps:
- OpenBao deployed, initialised, unsealed with Kubernetes auth configured
- OpenBao Agent Injector installed (part of Helm chart)
1Create the lab namespace
Create a single project for PostgreSQL and the sample application so the test stays isolated.
oc new-project myapp-dboc create serviceaccount myapp-sa -n myapp-db2Deploy PostgreSQL
Start a lab PostgreSQL instance that OpenBao will use as the backend for dynamic roles.
Use the official
postgres image (same pattern as TC-OPENBAO-DB-001) so bao_admin can CREATE ROLE.Manifest in Commands / YAML tab.
3Wait for PostgreSQL to be ready
Confirm the database Deployment is Available before configuring OpenBao against it.
oc wait --for=condition=Available deployment/postgresql -n myapp-db --timeout=180s4Enable the database secrets engine
Mount the database engine so OpenBao can create short-lived database users on demand.
bao secrets enable database5Configure the PostgreSQL connection in OpenBao
Tell OpenBao how to connect to PostgreSQL and which static admin user it may use to create roles.
bao write database/config/myapp-pg \
plugin_name=postgresql-database-plugin \
allowed_roles=myapp-readonly \
connection_url='postgresql://{{username}}:{{password}}@postgresql.myapp-db.svc:5432/myapp?sslmode=disable' \
username=bao_admin \
password=adminP@ss→ Success! Data written to:
database/config/myapp-pgVerify:
bao list database/config must include myapp-pg (not only postgresql from TC-OPENBAO-DB-001)bao read database/config/myapp-pg6Create a dynamic role with a short TTL
Define SQL that OpenBao runs to create and later revoke a readonly role; set a short TTL so rotation is easy to observe in the lab.
bao write database/roles/myapp-readonly \
db_name=myapp-pg \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl=2m \
max_ttl=10m→ Success! Data written to:
database/roles/myapp-readonlySmoke-test credentials before deploying the app:
bao read database/creds/myapp-readonly7Create a policy for the application
Allow the app token to read only the dynamic credential path for this role.
bao policy write myapp-db -<<'EOF'
path "database/creds/myapp-readonly" {
capabilities = ["read"]
}
EOF8Create a Kubernetes auth role for the application
Bind the
myapp-sa ServiceAccount in namespace myapp-db to the myapp-db policy.bao write auth/kubernetes/role/myapp-db bound_service_account_names=myapp-sa bound_service_account_namespaces=myapp-db policies=myapp-db ttl=2h9Deploy the sample application with Agent sidecar annotations
The injector adds a sidecar that authenticates as
myapp-sa and writes credentials into /vault/secrets.Step 1: Copy the OpenBao CA into
myapp-db so the Agent trusts https://openbao.openbao.svc:8200 (from TC-OPENBAO-OCP-001).Step 2: Deploy the sample application with Agent sidecar annotations.
Commands to copy the secret and apply the Deployment are in the Commands / YAML tab
Step 3: Wait for the deployment to be available.
oc wait --for=condition=Available deployment/myapp -n myapp-db --timeout=120s10Verify the sidecar injected credentials
Confirm the agent rendered a shell-friendly credentials file inside the app container.
oc exec -it deploy/myapp -c app -n myapp-db -- cat /vault/secrets/db-creds11Test the dynamic credentials against PostgreSQL
Source the injected file and open a
psql session to prove the ephemeral user can connect.oc exec -it deploy/myapp -c app -n myapp-db -- sh -c 'source /vault/secrets/db-creds && psql -h postgresql.myapp-db.svc -U $DB_USER -d myapp -c "SELECT current_user;"'12Observe credential renewal before TTL expiry
Watch the injector/sidecar logs. The agent renews the lease before
default_ttl (here 2m) so the app keeps working without a restart.oc logs -f deploy/myapp -c vault-agent -n myapp-db→ Expect renewal messages within about 1 minute (roughly half of the 2m TTL).
Re-check
cat /vault/secrets/db-creds after renewals: the same username/password usually remain while the lease is renewed.A new username/password appears only after the lease can no longer be renewed — wait up to `max_ttl` (10m) in this lab, or lower
max_ttl if you want to see rotation sooner.13Cleanup
Remove the lab namespace created for this test case.
oc delete project myapp-db