Writing static secrets from Boundary to Vault

[japneet-sahni]

Is your feature request related to a problem? Please describe. We want to leverage Boundary as one stop solution or all PAM capabilities which means apart from proxying connections to targets, also making Boundary capable of writing/reading static secrets to/from Vault.

Reading secrets from Vault isn't an issue with Boundary, the only constraint being we would end up creating targets (with dummy host address) for every vault/credential path.

But when it comes to writing secrets, we want to restrict access to Vault for writing/reading secrets. In turn, we want Boundary to be the interface even for writing secrets. I checked if it's possible to create a static secret from Boundary into Vault. The answer is "YES" but not a great experience to do the same. Steps followed:

• Created a credential library stated below with the secret name and POST request with actual value to be written in this secret.
• Created a target and associated this library with the target.
• Granted user access to this target.
• User clicks on "Connect" on this target from the Boundary desktop application and the secret is created (had to update Boundary controller policy to write secrets rather than just reading secrets).

Describe the solution you'd like

The main challenge would be automating and making this developer friendly. If you notice, I had to create a credential library with an already known value of secret and its value, had to associate this with a target and then user clicks on connect to finally create a secret (it sends a POST request in the background on clicking connect). It would have been really pleasant to see if the user was prompted with the path and the secret value while clicking on connect rather than configuring a credential path beforehand.

[covetocove]

Hi @japneet-sahni, thank you for the interest in this capability and for the helpful writeup!

I want to make sure I understand the motivation for this request. From your post it sounds like there are two reasons: 1) consolidating the workflow into a single tool, and 2) possible security benefits of shifting the workflow to Boundary.

I can certainly see that it would consolidate the workflow into a single tool, but want to better understand any perceived security concerns when you write "we want to restrict access to Vault for writing/reading secrets".

From a security perspective, HashiCorp Vault has a number of capabilities designed to secure and manage access to writing secrets - including Vault's support for MFA and large ecosystem of authentication providers, and its granular permissions/policies model. From a network perspective, you can also further limit access to Vault by making it a Boundary target so that users can only access Vault by going through Boundary. We are working on making this latter workflow even easier by simplifying the ux for connecting to https endpoints through Boundary targets. Are there other concerns I'm missing?

From a UX perspective, I can understand where writing secrets from Boundary may consolidate the workflow for managing secrets. Boundary itself is not intended to serve as a secrets management tool, but rather as a secure access tool and a simple/secure way to establish sessions. As such, we would expect secrets management workflows (eg writing secrets) to happen within Vault whereas Boundary would tightly integrate with an organization's existing solution, such as HashiCorp Vault, and act as a secrets consumer as part of the session creation process. This limits the amount of functionality we need to duplicate between Boundary and Vault and instead allows us to invest our time in enhancing Boundary's session establishment ux and session controls.

However, if there is strong demand from the community we will reflect on where this line should be drawn between Vault/Boundary functionality. We will keep this request open to gauge interest for this request from the community in consolidating this workflow. Thanks as always for being a great partner to the team!

[tckhandelwal]

Hello Pete - the request from Japneet came from our requirements. I completely agree with you that we don't want to change the role of vault and create functionality in two places unless absolutely necessary. What Japneet proposed will not create functionality in Boundary that is already in Vault. Every Privilege Access Management solution has the ability to vault passwords and only access them and update them through authorized access. By enabling Boundary to read and write to Hashicorp Vault - where Vault still stores the passwords, Boundary will be closer to parity with other PAM solutions - and there will be one standard interface for humans. My hypothesis is that the development effort to achieve this would be low, while the payback to enabling enterprise use cases would be high. -Tarun