Add buttons to copy and show/hide a secret

[rptxcosmo]

[djenriquez]

Hi @rptxcosmo.

I don't really see a value in this feature. Secrets aren't displayed on your screen in Vault-UI unless you click it. It feels like this would just add unnecessary actions for the user.

Did you have a specific use case where this is important?

[alexunwin]

I agree with @djenriquez. I am not sure the need of this feature

[rptxcosmo]

It's mainly for privacy purpose : When you are for example in an open space, everybody can see your screen.

[djenriquez]

Ah I think I get what you're asking, instead of opening the secret, have the ability to just copy the value behind the secret. This way the value is in your clipboard, but the value was never shown in the screen. Is this accurate?

[rptxcosmo]

Yes, that's the idea. :)

[msessa]

The issue is secrets are not simply values, they are full JSON objects. So how do you choose which field to copy?

An option would be to enable this functionality only when the root key bias is applied

[djenriquez]

I agree with @msessa's, not sure how we would implement this for full JSON objects. Our priority at this point is to represent full Vault functionality before adding these nice features. We will gladly review PRs for this if the community would like to submit one, but for now, won't be able to design/implement this.

[tallpauley]

I get where @rptxcosmo is coming from, I have a similar need for a vault UI that works similar to a password manager. @msessa @djenriquez I think this would be best implemented w/ a plug-in or "custom view" system that triggers custom views when metadata exists on a given path in vault.

I could see if you have a path secrets/passwords that you wanted to show up as a password manager view, you would vault write secret/passwords .vault-ui-plugin=password-manager. In vault-ui, when you navigate to secret/passwords would look for secret/passwords/.vault-ui-plugin and display the custom view password-manager w/ COPY and SHOW buttons and assume secret/passwords is made up of key->value pairs.

Thoughts?

[andrewsav-bt]

@tallpauley vault write secret/passwords .vault-ui-plugin=password-manager may not fly if whatever is already working with a secret does not expect this additional field and can potentially break because of it. This metadata need to reside elsewhere, ideally in a Vault-UI specific path. Otherwise sounds good.

[tallpauley]

@andrewsav-datacom ah right, agreed, I think vault-UI specific path is the way to go

[struanb]

I'm considering using Vault-UI as a password manager too. Like @rptxcosmo says, this is a common feature of password managers for when a username or password needs to be copied and pasted in a crowded office or public place, and should not be seen or caught on CCTV.

Although I realise this is not a priority for the developers, I'd like to take the idea further and suggest how secret versioning, which Vault does not natively support, could be provided by Vault-UI through a custom UI that encapsulates the versioned secrets in the object, hiding this from the user in the normal scheme of things.

For example, when a user writes { "myKey1": "myValue1" } to a new secret (for which the custom UI had been enabled) the custom UI would encapsulate this as { "secrets": { "<timestamp1>": { "myKey1": "myValue1" } } }. And when the user updates the secret, the custom UI would again encapsulate this as { "secrets": { "<timestamp1>": { "myKey1": "myValue1" }, "<timestamp2>": { "myKey2": "myValue2" } } }.

This behaviour would be opaque to all users using vault-ui as a password manager.

Does it sound interesting?

[struanb]

@andrewsav-datacom @tallpauley Just want to add, re your remarks, that compatibility with other applications for password hiding (or versioning) doesn't seem to me to be a given. If you want vault-ui to be able to hide passwords generically, that indeed could be useful.

But, independently, it could also be very useful if vault-ui were to incorporate a password manager plugin of its own that stored data in a custom (albeit open) format that is not intended to be compatible with existing apps (although apps could be written to process data in the chosen format).

[tallpauley]

@struanb That is definitely an interesting idea, might be a nice way to get versioning until Vault itself supports it. I think this is exactly why a UI plug-in system would be useful.

This is outside the scope of this issue, but I should add that Vault isn't ideal as a "true" password manager for a number of reasons:

• not currently the ability to have automatic user/group password paths (Dynamic Policies)
• user secrets are always viewable by those with root access tokens: (https://groups.google.com/d/topic/vault-tool/BKej1tGQwU8/discussion)
• until delegation is implemented, vault admins w/ policy & backend capabilities can get a token with root privileges whenever they want

As long as you are OK with those caveats, I think w/ the right UI it could be a pretty decent team password manager.