Production database access without sharing passwords

You give developers production data access without sharing a password by putting a broker between them and the database: the credential lives in one place, people submit statements instead of connecting, and a second person approves before anything runs. The reason to bother is not tidiness. A shared password is the one control that cannot answer “who did this?”.

What is wrong with a shared password?

Three things, and each one gets worse as the team grows.

• It has no owner. If two engineers know it, the database sees one user. An audit entry that says app_rw ran a DELETE tells you nothing about which person typed it. What database access control is puts it as a principle: every action should trace to a person.
• It is a copy the moment it is used. It gets pasted into a client, a shell history, a .pgpass file, a chat thread. The bastion host comparison describes the same effect: the credential stays valid until someone rotates it, which in practice is when somebody leaves.
• Rotation is all or nothing. Changing it breaks every person and script that uses it at once, so it does not get changed.

Do a bastion host or a vault fix this?

They fix a different problem. A bastion makes reaching the database mean reaching a jump box first, which means a key and a nameable person. A vault keeps the password out of a wiki. Both are real improvements and both end where the session begins. After the connection is forwarded, the engineer holds a live session and the credential, nobody reviews the statement, and the result comes back whole.

AWS IAM database authentication goes further on identity: it replaces the password with a short-lived token per person. It still does not read the statement or ask a second person. Authenticated and authorized are different questions. Access platforms such as StrongDM and just-in-time access and PAM tools decide who gets in and for how long, and Hoop.dev puts a guard in front of the database; the comparison pages say where each fits.

What does a broker change?

A broker takes the credential out of people’s hands and puts a workflow where the connection used to be. With QueryProxy:

1. A DBA registers the target database. Host, port, database, username and password are encrypted at rest with AES-256, and the password is not shown again after saving.
2. A DBA grants a connection to a developer. Ungranted connections are invisible in the editor.
3. The developer submits SQL. The statement is parsed against the SQL guards first, so a WHERE-less UPDATE never reaches a reviewer.
4. A DBA approves or rejects. Self-approval is blocked, and an administrator override is flagged in the audit log.
5. The worker connects with the stored credential, runs the statement, and writes each step to the audit log.

The reference for each step is the approval workflow. The point is the shape of the change: the developer holds an identity in the portal, not a secret for the database.

Where does this fall short?

• It is one more component. The portal now holds your database credentials, so its host, its application key and its HTTPS setup matter. The production hardening guide lists what to do before exposing it.
• It is slower for ad hoc work. A pending request waits until someone decides; there is no auto-expiry. If your team debugs production all day, a queue is friction by design.
• Database-side limits are not there yet. Read-only execution and a statement timeout enforced on the database are planned for v0.3.0. Until then, give people who only read a connection with SELECT-only privileges.
• Keep a break-glass path. An incident at 3 a.m. should not depend on the queue.

Who should not bother?

A team of three with one database and migrations run from CI has no shared password problem worth a portal. The pain starts when several people need to look at production by hand, and you can no longer say who ran what. The engine pages show where this lands on your stack: PostgreSQL and MySQL and MariaDB.