We’re trying to setup Boundary and Vault to connect to the Vault API to pull secrets. Here is the scenario we have:
We have a Vault cluster running in our Dev environment and we want our engineers to be able to pull secrets from Vault and populate their local environment variables files. Currently Vault requires authentication to access (via the root token, which isn’t advised).
We want connect to Boundary, authenticating via OIDC and Okta and then use the Vault API to pull in secrets and populate local environment variables. However, after the initial authentication with Boundary, Vault requires authentication as well, which leads me to my question.
What would it looks like to have Boundary connect to Vault to issue dynamic credentials to access the Vault API to pull secrets?
You’d need to set up an auth method in Vault that Vault could itself generate dynamic secrets for, then Boundary would need a Vault token with permission to read those secrets embedded in a credential library pointed at that secret path. Then you’d set up a target pointed at the Vault API and link that credential library to it as a brokered secret.
I’m not sure this is a great idea though, because doing that will break TLS — the Vault server certificate will not have localhost in it, and you shouldn’t add localhost to it (that would basically negate the value of TLS subject name validation). So either you have to modify the Vault server cert in a not-recommended way, point the Vault server name to the localhost IP (not-great also), or disable your API client’s TLS validation.
(As a side note, whatever credential you use would have to be displayed to the user and entered by them to authenticate to Vault, because right now there are no injections supported for any of the available Vault auth methods. That might or might not matter to you but it would be important to know.)
What kind of secrets are these environment variables? If they’re some form of credential there might be a more direct way of doing what you need for this.
The Boundary team is actively looking at what could be done to minimize or eliminate some of these issues, but for the moment there isn’t a tidy solution for this specific use case.
Most of the environment variables are credentials to external services (e.g. AWS, SendGrid, Google Maps, etc) and I wanted to confirm if there was a way to do what I suggested or if there was something I overlooked.
It’s mostly around trying to solve the problem of distributing those credentials in a way that minimizes them from leaking and using Teller (https://tlr.dev/) to redact environment variables and sync them between vault and local env file.