so i have the postgres plugin working fine: i can get new credentials using
vault read database/creds/<role>
however, i was wondering why one should have so many different sessions based on each call of vault read - ie i would prefer if the database pg_user table only has a single entry to each user. i know i can override
however, if the user uses a different login method (ldap vs oidc for example), display name changes. is there a way to have non-unique usenames in the database?
also, once a user has their username and password for the database session, is it possible to retrieve those details again for an existing ‘session’?
thirdly; strange usecase - but is it possible to never expire the password? is it a simple case of modifying the creation_statements to exclude the VALID UNTIL?
What are you actually trying to achieve, as it sounds like maybe Vault isn’t a great match for what you are wanting to do.
The dynamic secret functionality isn’t a general password creation and management system for a database, but instead is really for creating short-lived locked down credentials for an application/pod/service/etc to allow for a better security setup than the more common “single user/pass for all instances” or “single user/pass for all apps”. Once Vault is integrated into the application it is no harder to have lots of short lived focussed passwords (with permissions limited to exactly what a specific use case needs) than a single long lived wide ranging user.
So your questions don’t seem to marry with that - reusing users, creating users and not removing them or fetching details aren’t needed at all for the standard usage.
thanks @stuart-c; i understand the benefits of short lived credentials, however we are granting actual users rather than applications or developers access to the database, so we have to compromise somewhat of usability versus security.
as we have actual users trying to psql into the database they would like to have longer lived passwords (say on the order or a week or month). as you mentioned, vault isn’t fully integrated into our workflow currently, so it’s a bit of a chore for our users (in the hundreds) to continually login/renew leases. in addition, they will tend to forget their password so having an ability to have vault echo it back would be handy (especially if we could spit it out on the vault webui).
as we make use of vault’s alias-entity relationships, it would be useful to identify the user (entity) as opposed to the alias in the temporary postgres credential. the templating only seems to offer the {{.DisplayName}}. is there someway to get the entity name instead? (perhaps some golang templating magic regex etc?)
I’d suggest that Vault might not be the best fit for what you are trying to do. Instead I might look at using whatever user auth system you are using (LDAP, AD, etc.) directly with your database, so users can authenticate directly via their normal credentials (and then use Vault for application access).
Alternatively I’d still use short lived credentials and expect users who need to access to create a set of credentials only when they need access to a specific database. I’m thinking of the support type use case, where users rarely need direct SQL access, generally only for support issues which are relatively infrequent and short lived.
Hi @stuart-c
For this relatively infrequent and short lived access, is there a way to audit the user db query activities after user credential expired and removed from db?
as I aware of dynamic credential generated by vault will be removed from target db instance after the credential expired. Do you know whether it will remove related users’ events from db as well?
a further question, if we configure boundary integrate with vault to connect to target DB instance from local by running boundary connect CLI via boundary worker proxy, boundary controller credentials store need to be configured to get db dynamic credential (db username and password) with a vault token. So all end user will basically receive a dynamic db user having same vault username templating since they all have been generated by the token (based on vault username templating, dynamic credential username will be generated like “[auth method]-[username]-xxxxxx” username for token access is always “token” eg. “token-token-xxxxx”). Do you have any ideas how we can identify the exact user who actually read the dynamic db credential from vault connections to talk to db? Is that possible? or having a way to work around?
If you configure the database to store audit logs then that shouldn’t disappear.
To trace things through you’d need to reference both the Vault audit logs (to see the database user created by a specific user) and the database audit logs (to see what that temporary user did).