Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add kv configuration or policy option disallowing users to "Download secret value". #23981

Closed
ipaqmaster opened this issue Nov 3, 2023 · 12 comments

Comments

@ipaqmaster
Copy link

Is your feature request related to a problem? Please describe.
This feature appeared a while ago. When I go to vault I'm reminded that authenticated users can now save secret data as a plaintext file. I'm not sure how this feature made it into vault /ui/ but giving users the ability to save any secret they want onto a potentially unmanaged and unencrypted machine with one click and no protection on said secret isn't wonderful. Monitoring the Network tab under Developer Tools reveals that the Vault web client doesn't reach out with another API call and instead just saves what it has in memory with JS.

Describe the solution you'd like

A per-kv-engine or policy option to disable the download button feature on kv secret values.

Describe alternatives you've considered

Removing this feature.

Explain any additional use-cases

I cannot think of any good reason for Vault to offer users the opportunity of exporting secrets as a plaintext files in their Downloads folder.

Additional context

Searching online returns no results relating to this secret download feature or any discussion about it. A little confusing while searching for ways to disable the feature or learn more about it such as the release it were added in or relevant documentation. It appears to be part of ui/lib/core/addon/components/masked-input.hbs with relevant commits 01d5d1d, 43258c2, 88ed074, b5e82f5 and even includes a line {{#if @allowDownload}} though I cannot seem to find documentation about this feature with my poor searching skills.

@ccapurso
Copy link
Contributor

ccapurso commented Nov 3, 2023

Hi @ipaqmaster, I have not used this feature directly but access to the underlying secret entry in the KV backend is always provided via policies defined within Vault. The UI does not have a means to bypass Vault's policy checks. It essentially just a client making requests on your behalf with the token provided in the login response. Does this context decrease your concerns?

@ipaqmaster
Copy link
Author

Hi @ccapurso and thanks for your reply.

Sorry for the confusion - I don't mean to imply that the ui is doing anything special to save the data. I'm merely pointing out that pressing that save button makes no additional request to Vault for an opportunity to 403 the attempt. It just saves what has already been fetched earlier without the cluster knowing nor having a say in the data being saved locally by the client.

This was an observation on the topic of disabling or preventing the feature from being used. Its implementation appears impossible to disable as its an entirely client side /ui/ feature.

@ccapurso
Copy link
Contributor

ccapurso commented Nov 3, 2023

Oh, thank you for the clarification @ipaqmaster! In this case, the user has already been permitted to retrieve the raw secret data which is stored in the browser's memory. Having the ability to prevent users from saving the plaintext secret data on their computers seems like a useful enhancement. I will label this issue to account for that. An enhancement like this would require internal review to determine a best course of action. We are also welcome to reviewing contributions if someone from the community has the desire of providing a solution.

@hellobontempo
Copy link
Contributor

The original request was here #6364

We did improve this functionality by adding a modal to confirm the download which prevents users from accidentally clicking the download icon #23260 (merged in v1.14.4)

Image

A policy option is not possible here because the download action is not an API request to a separate endpoint. I'm going to close this issue, but if the modal does not satisfy your request and instead you would like a separate/admin configuration for this specific action please re-open this issue and I can update the title of the request. Thank you for filing this issue!

@Brado231
Copy link

I agree with the OP on this one.

It is good that you have added a confirmation modal to download the secret, but we need an option to disable this functionality in the GUI altogether. In my use case, this functionality is a recipe for disaster... we will end up with usernames and passwords scattered on local machines unencrypted all throughout our environment. Telling people not to use this functionality is not enough, as there will always be people who do it regardless. For us there are major security implications to this feature and I have not been able to upgrade ever since this functionality was introduced as a result.

Can we please have an option to disable this from the GUI completely?

@adrianmoisey
Copy link

+1

Removing the ability to download secrets will be nice to have. I know that if someone has access to the secret, you can't stop them from getting it. But making it easy for them to get secrets isn't ideal.

@ipaqmaster
Copy link
Author

I'm not sure what the motivation for this download button feature was.

Maybe one-off passwords. But still, allowing a user to download it as plaintext seems entirely outside the scope of using Vault in the first place.

@Brado231
Copy link

Brado231 commented Jan 2, 2025

100%.

My company will not allow me to upgrade while this functionality is present.

@hellobontempo
Copy link
Contributor

hellobontempo commented Jan 3, 2025

Reopening due to additional requests for this. I'll bring it up in our next internal product meeting and give an update

@hellobontempo
Copy link
Contributor

We've removed the button for now until downloading secret data can be properly gated (either by a policy or kv engine configurations). I'm going to close out this issue as it was opened in response to the aforementioned feature.

I am reopening #6364 - please comment there, or if you're an enterprise user discuss with your sales and support team, to get help prioritize that work

@Brado231
Copy link

Brado231 commented Jan 7, 2025

This is great news. Thank you

@ipaqmaster
Copy link
Author

Indeed. Thanks team

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants