vault-ui
vault-ui copied to clipboard
djenriquez
unable to browse cubbyhole secrets
From the CLI I created some cubbyhole secrets for a given token.
When logging in to vault-ui using that same token, unable to see anything in cubbyhole
Hi @travis-bear,
Vault-UI currently doesn't support showing the cubbyhole backend. We can add this to the list of next features to produce. For now, the only secrets backend we support is Generic. You can see a list of all the available ones here. We hope to support all of them one day.
If you are interested, or even curious, we would love to review some PRs.
Adding support for cubbyhole is pretty trivial as it fully shares the API interface with the generic secret backend.
However I'm perplexed on whether this functionality would bring any practical value to Vault-UI. According to the official documentation:
This backend differs from the generic backend in that the generic backend's values are accessible to any token with read privileges on that path. In cubbyhole, paths are scoped per token; no token can access another token's cubbyhole, whether to read, write, list, or for any other operation. When the token expires, its cubbyhole is destroyed.
At this time, cubbyhole is only used internally by vault to implement wrapping.
What would be a use case for having cubbyhole support in Vault-UI?
This might be a noob question, but wouldn't it be desirable to keep your stuff in cubbyhole instead of secret if you didn't want it to be possible for vault admins to read your secrets? In this scenario they could be compelled to turn your secrets over to third parties.
No ignorance at all. I believe @msessa's point is the fact that cubbyhole is tied to a token: in best-practices, tokens are supposed to be short-lived. So if you stored secrets in your cubbyhole and your token expires or is revoked, your secrets are gone with them.
@msessa the use case is straight forward - to be able to read and to write to the cubbyhole backend.
At this time, cubbyhole is only used internally by vault to implement wrapping.
I do not think that this is entirely correct, anyone one can use cubbyhole for any scenario they can see fit. You might be confused by the fact, that the default wrap/unwrap functionality only produce one-time use tokens, and with those, indeed, adding cubbyhole to Vault-UI would be useless. Fortunately, you are not limited to one-time-use tokens for cubbyhole, and thus being able to browse/write to the cubbyhole corresponding to your token can be quite valuable.
@andrewsav-datacom "to be able to read and to write to the cubbyhole backend" what you're describing is a feature request, not a use case.
I get that cubbyhole backend has its purpose, I just can't see a practical use for a UI around it. If you can elaborate on that we might be able to help you with the implementation, otherwise feel free to submit a PR.
I am thinking about using cubbyhole as a replacement for KeePass/Lastpass to store secrets that I don't want others to have access to.
well, that won't work -- I logged in with ldap, got a token, saved to cubbyhole, and re-auth'd via the CLI and the cubbyhole was different (different token). I guess I'll need to create a secret path with a policy that is scoped just for me -- but I'd really like to be the only one that can see the values (not even root).
Hmmm, yea let me think if theres some clever way to do that. Cubbyhole, as you discovered, is tied to the life of the token. When auth-backends are used, Vault actually assigns new tokens each time with the default TTL of that backend. So, every time you log in, you get a new cubbyhole. Currently, the best solution that I'm aware of is to have user protected namespaces, but you're right in that root would still have access to them.
I'll spend some time thinking about it, but open for ideas from others.
Thinking out loud: I'm wondering if maybe there's some place for the transit backend to be used here. Right now, if I wanted to replicate the functionality of KeePass/Lastpass, I might be able to make a transit key, encrypt my secrets and then store the ciphertext on my local machine (or s3 or wherever I can access), just like I store my KeePass database. That use case seems out of scope for Vault-UI, but if I stored the ciphertext in a Vault path, it might be able to become a feature of Vault-UI, but there's the same issue of the cipertext being decrypted by the root token or another user potentially.
Ah, the transit backend. Yes, this functionality has been on my mind for a while.
As far as storing the ciphertext, this does sound like an interesting way of handling the problem, however, our primary goal is to represent the CLI's functionality. I can't say that we would implement this particular solution, but the transit backend, yes, that will happen.