Feature request: Hide key values by default and add copy-to-clipboard option
Justin-DynamicD opened this issue · comments
This is actually a response to a feature available in T-Vault: T-Mobile's recently released GUI for Vault:
https://youtu.be/fv3GOiFYAt8?t=2m10s
(skip to 2:10 if it doesn't link there automatically).
It would be nice for static secrets to be hidden by default unless specifically revealed as well as offer a copy-to-clipboard option. This makes it less risky for "casual monitor browsing" to see something unintended, especially as the secrets mount tends to be static info.
Not a high priority, but definitely a "nice to have".
Please consider.
This has been suggested before but I decided that it is not within the scope of a UI to attempt to block physical access. Preventing shoulder-surfing may be easy in the secrets page, but sets a horrible precedent that I cannot hope to follow through - there is no way I can consider shoulder-surfing in every frontend page, component, and feature.
Alternatively, HashiCorp's enterprise UI is moving to OSS according to hashicorp/vault#4248. Perhaps they would be more open to the idea?
Yes, 0.10.0 launched yesterday and I've already got it running in test atm.
I would disagree about your concern, mainly as only the kv secrets engine and thus page contains static secrets (unless you want to argue polices but that's a different beast all together), there's no president to set: it would be a kv-secrets specific feature.
There's also the social engineering aspect being disregarded: i find it interesting that you adamantly adhere to using a wrapped token to init goldfish (so that actual key remains unknown to human interaction) but once it's up it's all plain text?
Honestly I'm chalking up this rejection to lack of time/deep backlog than anything else. Would you be open to a fork/merge if I were to mock this in? Or is this honestly a hard no?
The init token should be wrapped because it might be passed between multiple people or recorded in bash (or other tools) history.
This is not a rejection based on lack of time or backlog. As you may see, there are many feature requests that remain open even if I have said I don't have time to get to it. This is indeed a hard no unless I change my mind in the future.
Forks are always welcomed, of course, since this is an open source project. But such a feature will not be merged for the foreseeable future.