PostgreSQL should emit connection strings

[nevir]

It'd be valuable to have the PostgreSQL backend (and other database backends) emit full connection strings; maybe via a template.

Currently we've gotta wire together that information from multiple locations (e.g. retrieve the address & db name in consul, and user/pass from vault), even though vault should have most/all of the info required

maybe a vault read MOUNT/connection/ROLE?

[jefferai]

Adding to the 0.6 milestone as we have some work around postgres planned for that. I can't promise that this will actually be added, but I want to make sure that we don't forget about it so that it is in the discussion.

[vishalnayak]

If this issue is only about reading the configured parameters, it will be fixed by #1515

[vishalnayak]

Fixed by #1515

[jefferai]

I think this is a different ask -- the connection strings being asked for here will have information about the generated user, not the higher level connection information valid for the static admin user.

[schuylr]

+1 but for MySQL backend, please. I noticed the issue labels don't cover this backend even though you closed another issue for MySQL concerning this as a duplicate.

[jefferai]

Issue labels don't really matter in this context :-)

[schuylr]

Making sure. Thanks :)

Here's another gotcha, what if I need the Vault server to use one hostname/IP or connection string, whereas my application uses a different hostname? Use cases involve multiple AWS VPCs that I've peered together using IPSec and custom hostnames to tunnel AWS RDS instances, where my apps all have direct access to their own RDS no matter what. A definable custom string would be handy for this, although I can always just store this in another generic backend.

[serverhorror]

We could check that hostname is non-loopback and not a local socket

Please don't!
How would you know the local layout of a random company using vault?
It might be intentional

[Andrey9kin]

Any plans to get this one going? Surprised that there are not that many people asking for it. Is there a workaround? I mean something better than building connection string yourself using received temp creds

[jefferai]

@Andrey9kin Not currently, there's very little demand - a handful of requests over the years. If someone wanted to work on a PR we could help with making sure the design is right.

[Andrey9kin]

@jefferai how hard could it be? ;) doesn't feel like something big. I guess extend plugins/helper/database/credsutil/sql.go to return one more value and then roll from there, right?

[Andrey9kin]

or perhaps it should be more specific since databases have a different format for connection strings...

[adamdecaf]

Yea, we never decided on a response format.

[therealgambo]

I think returning the connection_url of the database would be a decent start, not sure if handling the construction of the DSN should be done by vault or leave it to the application making the request.