IDEA: Treat secret stores (vaults) as a managed source and later use them for database passwords too

[ozanonurtek]

Hello. I use LibreDB Studio self hosted and I like it a lot. I have a bigger idea and I want to hear if it fits the project or not.

Today the tool connects to many databases and shows their data in one interface. I would like the same for secret stores.

Add a vault as a connection, like adding PostgreSQL or Redis, and then browse and manage what is inside from the same UI. List the secrets, see names, versions, tags and expiry dates, open one to read or edit its value, create new ones, delete old ones. The thing you manage in a key vault would feel like managing a table.

• Azure Key Vault would be the first store, because that is what I use, but the idea is one common interface, like the one used for databases. HashiCorp Vault and AWS Secrets Manager could follow the same pattern. Azure Key Vault speaks plain REST, the same way ClickHouse and Elasticsearch already do here.

• Values could stay hidden by default, the way the display masking feature already works, and shown only on click. Writes could be off by default, so a vault connection starts read only, the same way the agent does.

• There is a second win once this exists. The same interface could also serve database connections. A saved connection could point to a secret in a vault instead of holding the password itself, and the app would read the real value only when it connects. So the vault feature would not just be a new tab, it would also make the database side better. Security teams often ask for exactly this, because they do not want database passwords stored inside yet another app.

I read the thread about which providers belong in the tool, so I am asking here first before writing any code. If you think this fits, I am ready to build it with tests, following the rules in your contributing guide. If you think it does not fit, I would also be happy to hear why.

Thanks for reading.

[cevheri]

Thanks @ozanonurtek for asking first. There are two ideas here and they point in opposite directions(as I understand).

Vault as a connection type: declining. DatabaseType is not just a list, the factory, the connection string parser, the exhaustive UI maps and the explain registry each carry one entry per id, and BaseDatabaseProvider demands getOverview, getSlowQueries, runMaintenance and more that a secret store cannot answer. The heavier reason is that secret values would then flow through the query result path into browser storage, query history, exports and the AI context. docs/STORAGE.md says today that this is not a vault, and I want that to stay true.

A database password sourced from a vault(5 star): taking it. That direction removes secrets from the app instead of adding them, and it has a home already. src/lib/seed/credential-resolver.ts resolves ${ENV_VAR} server side for seed connections, and this is a second scheme beside it. Scope and acceptance criteria are in #937.

Azure Key Vault is a follow-up rather than a no, and it is reachable with fetch alone so it fits the same interface unchanged. Two reasons it is not first. Most of this work is a lazy resolution refactor rather than the backend, and a second auth story on top of that (IMDS or client credentials) makes it too large to land under our coverage gate. The other reason is proof: HashiCorp Vault runs in a dev container so any reviewer can reproduce the end to end read, while a Key Vault read can only be shown from your own tenant. The first backend is the one that defines the interface, so it should be the one everyone can re-measure.

One trap worth knowing, and it outweighs the REST call: getSeedConnectionById resolves the whole list today, so resolution has to become lazy and per connection first. Otherwise listing connections would read every secret.

It is yours if you want it.

[kaya-abdullah]

I really like the direction of using external secret managers, and I agree that Vault should not be treated as a "DatabaseType".

I do, however, have a few concerns about giving LibreDB direct access to Vault and resolving credentials at runtime.

1. The potential blast radius becomes larger

Today, LibreDB may have credentials for a limited number of configured databases. If we give LibreDB a Vault identity, the security boundary becomes different.

For example:

Today:
LibreDB → 2 configured database credentials

With Vault:
LibreDB → Vault → potentially many secrets

Of course, Vault policies can and should restrict access using least privilege. My concern is that if the Vault policy is broader than intended, compromising the LibreDB runtime could potentially expose not only the database credentials LibreDB currently uses, but any other secrets accessible to that Vault identity.

So the security of the LibreDB deployment would become partially dependent on the correctness of the Vault policy as well.

2. User-created connections make this more complicated

I think the "secretRef + host" combination deserves particular attention.

If a user can control both the secret reference and the target host, LibreDB could potentially be used as a bridge between a user's input and secrets accessible through its Vault identity.

I understand why #937 limits this initially to seed connections. My concern is that this limitation may indicate a deeper architectural issue rather than just an implementation detail.

3. We should carefully compare this with the existing Kubernetes approach

For Kubernetes deployments, we can already have something like:

Vault
↓
External Secrets
↓
Kubernetes Secret
↓
LibreDB

The proposed approach gives us an important benefit: credentials can be resolved at runtime and rotation can happen without restarting LibreDB.

That is definitely useful. I just think we should explicitly weigh that benefit against giving LibreDB direct access to Vault.

4. I wonder if a credential-provider abstraction would give us a cleaner foundation

Instead of making Vault part of the database connection/provider model, perhaps we could separate the two concepts:

Database Provider
├── PostgreSQL
├── MySQL
├── Redis
└── MongoDB

Credential Provider
├── Environment
├── HashiCorp Vault
├── AWS Secrets Manager
├── Azure Key Vault
└── GCP Secret Manager

Then a database connection could simply reference a credential:

Database Connection
↓
credentialRef
↓
Credential Provider
↓
Secret / Dynamic Credential

This would allow Vault to be supported without making LibreDB treat Vault as a database, and it could also give us a cleaner path for other secret providers later.

I am not suggesting that we should drop the Vault idea. I think the use case is valuable. My main concern is making sure that we don't unintentionally turn LibreDB into a highly privileged gateway to an organization's broader secret infrastructure.

Perhaps the credential-provider abstraction could give us the same functionality while keeping the security boundary and responsibilities clearer.

[cevheri]

I am also think about it: LibreDB Studio> add database connection > select vault > enter vault user token > list all available databases for related user
so vault can store all database connectionStrings(like a seed-initial-databases yaml file)

[cevheri]

first vault implementation : #944

[ozanonurtek]

@cevheri @kaya-abdullah thank you both for the deep answers.

I want to make one point clearer, because I think we are closer than it may look. I did not mean for a vault to become a full DatabaseType, with maintenance panels, slow queries or an explain registry.

A vault is at heart a key and value store for sensitive data. Some add secret engines on top, but the core is storage. So my picture was never "one more database in the list". It was a lighter thing: a small browser that lives outside the SQL world.

Here is the real motivation. Today a team that runs databases and a vault needs two or three tools open. One to query the data, one to rotate a key, one more for the cloud.

The dream is one safe home for everything that stores data, managed from one point.

LibreDB Studio already speaks to 17 engines, so it feels like the natural place for that. And I would add that databases, by the data they hold, are already the most sensitive access point in this picture.

A leaked database is usually a bigger loss than a leaked key, because the key often opens that same database. So the app already carries a risk of that size today, and it is handled well, with RBAC, audit trail and care.

I only ask that the vault idea is weighed against that bar, and not against a zero risk that does not exist. On the shape, I hear the strongest objection, so let me remove it: values would never enter the query path. No result grid, no query history, no exports, no AI context. Masked by default, shown on click, admin only, read only by default, every read written to the audit trail. A separate page, not a tab in the editor.

One more thought on the shape. This does not need to live in the core at all. It could be a module, not a must to load, and it could be turned on or off at build time or at run time. A default build would then carry none of it, and only the people who ask for it get it. So the core stays as clean as it is today, and the extra surface exists only where someone wanted it.

If this still feels wrong after some thought, a no is fine, and I will take it kindly.

TL;DR

Thank you for the great work, I respect and appreciate it. My real wish is simple: all of these things, the databases and the vaults, in one app, managed from one place. I still hope that home can be this project, and I would gladly build it here, under your rules and with your review.

But if the project wants to stay database only, I understand that too, and the MIT license always leaves me the option of a fork, so the idea can live on either way. Thank you for the honest answers, and good luck with the credential work in #937. That part is good news on its own.