Unwrap tokens from the UI login page

[khicks]

I really enjoy how easy it is to wrap existing secrets now in 1.0.0. Retrieval however, seems to be the same tedious process for users who only use the UI: log in, go to Tools -> Unwrap, and paste in the response-wrapping token. This method of retrieval is, of course, only for users who already have a way to otherwise access Vault. Users without any other Vault credentials must retrieve the response-wrapped secret via the CLI or API.

I think it would be helpful to be able to use response-wrapping tokens directly from the UI login screen. A possible use case would be when sharing a one-time secret with a colleague who may not have Vault credentials of their own or the CLI tool installed.

For example, it could look like this:

Or perhaps it could be an extra checkbox option underneath the normal Token login field.

Thanks for reading and for all the hard work!

[avoidik]

you may try with

http://<hostname>:8200/ui/vault/auth?with=token&wrapped_token=<wrapped_token>

[meirish]

@avoidik that will log you in if he wrapped secret is an auth block, but if it's arbitrary data, it will just use the unwrap, but then fail to properly log you in. I think @rotorcowboy is more looking for a generic way to unwrap secrets when you're not authenticated to Vault.

[Garath620]

@rotorcowboy It would be a very good feature! +1

[Garath620]

An alternative could be to access directly without authentication to : /ui/vault/tools/unwrap and pass wrapped_token in url param. http://<hostname>:8200/ui/vault/tools/unwrap?wrapped_token=<wrapped_token>

[meirish]

@Garath620 those routes are gated on authenticated currently, so the suggestion of using wrapped_token will work the same way I described above here: https://github.com/hashicorp/vault/issues/5893#issuecomment-445286965 - you'll likely just lose whatever data was wrapped as the UI would not display it.

[Garath620]

I wanted to say wrapping_token, not wrapped_token. http://<hostname>:8200/ui/vault/tools/unwrap?wrapping_token=<wrapping_token> It would be helpful to share a secret with someone who does not have access to the vault.

[SimonGurney]

Has there been any progress on this, it would be a very useful feature

[khicks]

To respond to the notification from @aphorise: no, this feature has not yet been implemented. The UI method in the Learn guide mentions having to log in. Since logging in isn't strictly necessary for unwrapping to work, the capability should be implemented in front of the login screen.

I'm guessing they (aphorise) quickly discovered that and deleted their comment, but since it mentioned closing the issue, I figured I would respond by saying this issue/request should not be closed.

[aphorise]

Wrapping is a bound operation as described earlier - how would it be done unauthorised or unauthenticated from the UI login? How would it even know if it has the rights to look that up and whose would it look up? (not to mention other namespace considerations)... there's probably yet more.

In any case I'm wondering can a sort of wildcard / anonymous sort of auth not be put in place which automatically logs you in using a federated sso redirected to the right section in the Vault-UI as callback - all just for the sake of convenience to copy-paste & click unwrap 🤣 😆 😃

... on a more serious note I bet a similar sort of auth + unwrap could be achieved using successive API calls? - I'd bet that using an in browser tools (postman?) to achieve this would still be faster than any human / mouse interaction via the UI (IMO). I also suspect that at core this request will not be possible.

PS - my posting earlier was a miss-understanding on my part - thus the deletion

[akdor1154]

@aphorise: auth is not needed for the unwrap operation. or in another sense, the token you provide to unwrap provides the auth to unwrap it.

This issue is because the Vault UI ignores this fact and makes you log in anyway, which is a pain to e.g. send secrets to random people in your company who "don't know what a vault is, how do i open it?"

[aphorise]

auth is not needed for the unwrap operation.

This is not true - both the CLI & API docs on the subject state otherwise - and what's more the UI makes use of the core by exactly the same methods.

To state bluntly - I think that either I've not understood key concepts in Vault related to its routes and permissions (internally) or its lacking in this request.

In the realm of security and secrets - one can not allow for bound operations willy-nilly on any page. Issues with scope are applicable here and even if it were possible to somehow check everywhere for the membership of the wrapped token to unwrap - how would you determine the rights to perform that operation (over-looking rights of access) and not a randomly guessed token or one that was found by brute? - anyway my two pence is that it's not possible - if there's a more substantive way you can convince me otherwise then I'd be grateful.

[akdor1154]

This is not true

I am 100% sure that it is true, because I just did it. you must be misreading the docs.

[aphorise]

@akdor1154 easy to state - how? - detail steps. - If you were already vault login... then yes may you didnt need to re-provide token - otherwise I dont understand how I am misreading that a token is always required?

[akdor1154]

Ah - a wrapped secret is a token.

[aphorise]

Comes full circle to what I'm strived to communicate earlier with bounds and I think the docs are rather clear:

This endpoint can be used by using a wrapping token as the client token in the API call, in which case the token parameter is not required; or, a different token with permissions to access this endpoint can make the call and pass in the wrapping token in the token parameter.

curl -H "X-Vault-Token: ..." ... http://127.0.0.1:8200/v1/sys/wrapping/unwrap
# // OR 
VAULT_TOKEN='' vault unwrap # unwraps 848f9ccf... ;

@akdor1154 perhaps you can show me how I can unwrap something from where I am here without a token from your Vault instance?

[akdor1154]

[aphorise]

Provided in the above PR - not sure how complaint it is with the Hashicorp way & also relatively new to Ember.js.

[Merenon]

Is there any plan to implement/merge this? We also have a use case, where we'd like to use Vault wrapping for securely sharing secrets/credentials - also with "non-technical" people, for which this UI option would be great.

[heatherezell]

Hi folks. We're looking at this request internally again to see if it's something we want to put on the roadmap. Thanks for your interest!

[McLan]

Hi guys, Any news about this UI unwrapping functionnality ?

[McLan]

I developped a node js web app to communicate with vault unwrapping API endpoint. Here is the github link : https://github.com/McLan/secrets-unwrapping-webapp. Can be dockerised too. Hope it will help some of you.

[Zetanova]

The optimal why to do this feature would be over the url fragment parameter. Else near all instant messanger apps would destroy the url on sharing

Example: http://<hostname>:8200/ui/vault/tools/unwrap#wrapping_token=<wrapping_token>

The the UI need to provide an action-button to unwrap the provided token, including a short message that it is only once possible

The last issue is that the vault wrap tools require a valid JSON message. This is an issue by itself. Escaped JSON or base64 encoded values are still a problem for end-users.