Platform Engineering · 2025
Just-in-Time Database Credentials
Replaced manually-created, permanently-shared database users with a Bytebase approval workflow issuing time-bound credentials behind pgbouncer, authenticated through GitLab.
- Time-bound
- Credential lifetime
- Approval
- Required per grant
- Auditable
- Request to expiry
How it used to work
Developers doing local development and testing needed database credentials. The process was manual: someone created a user on the database and passed the credentials to the developer directly.
That is a problem in two distinct ways.
It is insecure. The credentials were long-lived and never expired, so access granted for one afternoon’s debugging persisted indefinitely. They travelled over chat, which means they came to rest in message history and on local machines. Nothing forced rotation, and a developer changing teams or leaving did not automatically lose access, because the database user had no connection to their employment record.
It is not auditable. There was no record of who requested access, who approved it, what it was for, or when it should have ended. If you needed to answer “who had credentials to this database in March”, the honest answer was that nobody knew.
What we built
Two components, doing different jobs.
pgbouncer sits in front of PostgreSQL as a connection pooler and proxy. Sessions are multiplexed rather than held open one-to-one, which keeps ad-hoc developer connections from consuming the connection budget the application needs.
Bytebase provides the request and approval workflow, with authentication delegated to GitLab so identity comes from the same account that owns the code.
The flow: a developer raises a request for a specific database, for a stated duration, with a reason. A database administrator or designated approver reviews it and approves or rejects. On approval, temporary credentials are issued. When the duration expires, the credentials are removed from the database automatically.
Why it is better
Access is now bounded by default rather than by someone remembering to revoke it. Every grant has a requester, an approver, a purpose and an expiry attached to it, so the audit question has an answer. And because identity comes from GitLab, someone losing their GitLab account loses the ability to request database access at all.