Vault username_templating

hi,

Can username_template options in Vault terraform resource vault_database_secret_backend_connection configuration be override when boundary_credential_library_vault read dynamic db credential through vault api token? (new feature required)

The issue is boundary_credential_library_vault use a vault token for the api call to get backend db dynamic credential which vault_database_secret_backend_connection configured username_templating pattern option [auth-method]-[user]_[random characters] (e.g. in above case dynamic credential boundary connect will have token-token_ue1LD0vkDWLaAWJn9jdx to connect to backend target DB. As an administrator I cannot audit who is that user in real world actually access the db). So would like to pass boundary oidc user/account name to vault which can override the [user] option of vault username_templating pattern before dynamic credential generated and returned back to boundary connect response as “username”: “token-amos.c_ue1LD0vkDWLaAWJn9jdx ”.

Leave this previous discussion on HashiCorp Discuss as a reference

Thanks

1 Like

Can anyone help with this please?

@amosc did you manage to solve the issue?

Does following this work for you/get you closer? The username generated for the DB has the role name included

"username": "v-token-**analyst**-1ee37SuBH6J92Ex6RDRp-1624921756"

thanks for the reply @jonathanfrappier !
My aim is to somehow bind generated username with user login in boundary

As I understand this setup, Boundary is the Vault client. There would need to be a way for Boundary to pass the username details through to Vault and Vault would also need to be able to accept that detail coming in from Boundary so Vault could include it when creating the user/role in the target database instance you are connecting to.

I don’t think that is possible today (based on the other thread and Jeff is very close to Boundary development).

I am going to put an item in my teams backlog to investigate, but off the top of my head I think for now my best guess is to correlate logs in your logging platform (though I also need to setup an environment to see the logging formats, and what comes in from both Boundary and Vault when making this request).

If you have an account manager with us, I would also suggest asking them to raise a feature request.

@jonathanfrappier thanks for the reply!

I was happy to see this feature in bounday’s docs.
If that’s not it then I cannot really understand it’s purpose, could you explain it to me please

as for logs correlation, I dont really undesrstand, how use boundary’s audit logs, I need emails and usernames in cleartext. But unfortunately nobody answered my question, maybe you could give some advice on it?

That is going to be part of what I hope to research (I am not a developer or in support so I can’t look at the source to understand what the intent was).

@dmitryroshchin - Didn’t want to leave you hanging but so far I’ve only been able to confirm I don’t see a way to make this work the way I think you/OP wanted. I am going to try one more test tomorrow/next week where I have multiple Vault roles, but a single cred store that has the username template as part of it. Not sure that is the correct answer either, but the best my co-worker and I have come up with.

@jonathanfrappier the strange thing is that boundary seems to able to send user data to cred store in request, but vault just can’t handle POST read creds requests!

@dmitryroshchin @amosc so here is what I have found. I think this was mentioned in the other thread but think maybe context was missing.

Boundary supports templating IN Boundary. Vault is not aware of Boundary’s templating patterns (hence the error when trying to pass something like {{ .User.Name }} to Vault.

The templating support in Vault is specific to constructs that Vault is aware of (such as the Vault role name).

Part of the Boundary doc that you referenced that may not have been clear was this section:

“For example, this can allow picking the correct role when asking for database credentials (if roles are separated per-user)”

I read this line as “if VAULT roles are separated per-user”, but a coworker took it as Boundary roles.

The setup to get what you are looking for today - to have the Boundary username as part of the target DB dynamic credentials would be to have the Boundary credential library set up with the username template:

boundary credential-libraries create vault-generic \
    -credential-store-id $CRED_STORE_ID \
    -vault-path "database/creds/{{ .User.Name }}" \
    -name "northwind dba"

You would then need a corresponding Vault role for each Boundary login:

vault list database/roles
Keys
----
bill
jonf
thea

With the credential library configured with the username template, the command would be the same:

boundary targets authorize-session -id $DBA_TARGET_ID

But the call to Vault, Boundary would replace the username template with the authenticated Boundary user (looks like this):

GET https://vault-cluster:8200/v1/database/creds/jonf

Boundary substituted the username as part of Boundaries support for templates, and is making an API call to Vault with the substitution in place. The Vault API would need to support receiving additional data/metadata. Currently that API (Database - Secrets Engines - HTTP API | Vault | HashiCorp Developer) does not support POST.

The Vault role then produces the username, which is based on the Vault role for jonf.

  Credentials:
    Credential Store ID:           csvlt_uvSWjCiR4E
    Credential Source ID:          clvlt_ZhhZREKiCb
    Credential Source Type:        vault-generic
    Credential Source Name:        northwind dba
    Secret:
      {
        "password": "1XaeNPuy-1qKn51nyqld",
        "username": "v-token-**jonf**-WAdhXxNh1RzIGGmoOnLQ-1700663217"
      }

There are some other internal discussions going on around how to provide an auditable experience for this as well since correlating the logs of Vault, Boundary, and the RDBMS would likely not be possible today.

If you have an account manager, I would suggest asking them to submit a feature request or making a feature request in - probably the Vault GitHub repository since Vault needs to be able to accept some sort of additional data/metadata about the Boundary user but may require additional work from both Vault and Boundary.

@jonathanfrappier Perferct research of an issue! Thanks!
But in my case(multiple OIDC users) single role for each user is not an option. Seems that it is ease to make vault to be able to accept POST requests with user data from boundary. I’ll think about feature request

You are welcome - wish I could have found a better solution, but it seems to have at least sparked some discussions internally.

@dmitryroshchin did you end up creating a feature request for vault? If so, do you have a link so maybe I can +1 it?

Hi @jonathanfrappier, do you have any update on this discussions?

How to support this, more generally (i.e. it may not be the exact method suggested in this thread but rather a way to correlate Boundary users with generated Vault users), is being researched. I do not know of an ETA for when that research will be complete or when feature development may start. Escalation would be best done through your account manager/customer success manager.

For now, the closest setup is the one I proposed where you create a Vault role for each person who requires access to the RDBMS to match the Boundary username.