Vault: Enable Token based ACL Policy Path Templating

[nico-rogasch]

Hi there,

I currently want to implement a One-Time-Token functionality to supply users with a Token that's usable only one time to read a specific secret. (e.g. to supply a User with VM credentials via Email, sending the One-Time-Token, making sure that only he can retrieve the secret one time and realizing if someone else has already retrieved it)

I found a good solution on how to implement the functionality by:
1) Creating a One-Time-Token Policy that allows Read on a specific secret's path
2) Creating a Token assigned to the Policy with a use limit
3) Send the User the created Token and ask him to retrieve his Secret by logging in with the Token and request his Secret via Vault UI

All works pretty well here, my problem comes with the administration of this functionality by a DevOps Team with no Vault Admin rights. Vault Provisioners are not allowed to create policies and I can't seem to restrict the policy creation rights to this specific use case, so it always takes an Admin to perform the first step of creating the Policy.

A nice solution would be if the ACL Policy Path Templating would extend the available Templating parameters from identity to token attributes (e.g. Token ID), so I can just create a generic One-Time-Token Policy that allows for read of a certain secret path, that includes the Token's ID.

Do you think something like this could/should be implemented?
Or can you suggest a different approach to supplying user's with One-Time-Tokens or similar to request a secret one time only from Vault?

Thanks for your awesome project btw! :)

[jefferai]

There is already a much better way to do this :-D

https://www.vaultproject.io/docs/concepts/response-wrapping.html

[nico-rogasch]

Yeah I read about response wrapping and cubbyholes, but it seemed not to be the right solution for my use case as I read the documentation, since it seems to be designed for app usage rather then end user usage?

After reading the docs again in detail, my problem or questions with using cubbyholes for my scenario is:
How can the provisioner put a secret in the cubbyhole of the One-Time-Token?
It seems to me that only the logged in token itself can put and read secrets in it's cubbyhole, or is there a way to fill the cubbyhole of a token during creation?

[jefferai]

See https://www.vaultproject.io/api/system/wrapping-wrap.html

[nico-rogasch]

Hi,
okay I figured out now how to use the Response Wrapping Feature for my use case and it's awesome!

Thanks for your pointers in the right direction, but as I don't consider myself a dummy Tekki who doesn't understand Documentation, I'd like to state that the Documentation considering the Response Wrapping Feature is quiet hard to grasp imho.
It doesn't clearly show the possibility to implement an easy to use, end user ready possibility to implement the One-Time-Token based transfer of secrets, so let me suggest an extension to the documentation showing a simple to implement option on how to use the Response Wrapping Feature for my use case:

Scenario / Desired use case:
-we want to send secrets to users that do not own a Vault account and are not willing/able to register themselves with Vault via an Authentication Method
-we want to send the secret via a insecure communication channel (e.g. Email) but still make sure that only the intended user is capable of reading the secret and realize if the secret was read by an unintended user
-we want to achieve a high end user usability with no involvement of CLIs or command lines

Use Case Implementation:
-enable the userpass Auth method (if not enabled already)
-enable Vault UI (if not enabled already)
-create a new user with no specific rights, inheriting only the "default" policy
-e.g. "vault write auth/userpass/users/otp password=otp"
-Wrap the secret to supply using the "Wrap" Tool within Vault UI or using the CLI
-Send out the created Wrapping Token to the end user, directing him to Vault UI and supplying him with the default OTP user (Login with method Username) and the Wrapping Token
-The end user now is capable of using the "Unwrapping" Tool in order to retrieve the desired secret in a secure way

This is just a well meant suggestion to make the powerful capabilities of Response Wrapping connected with Vault UI more clear, since I guess not every new Vault Admin will understand these capabilities right away reading the current Docs, but I think this is a very interesting and often required feature.

Thanks again!

[v6]

// , @nico-rogasch , it looks like you're setting up the equivalent of an internal https://0bin.net or https://onetimesecret.com, but using Vault, correct?

Because of what you've written, I'm considering whether to do something similar, now.

This use case would be useful to document somewhere for the rest of us, especially if you have a blog.

Have you written about it elsewhere?

[yhyakuna]

@nico-rogasch Thank you for your feedback. I added Web UI discussion in the Cubbyhole Response Wrapping guide. Hope this adds little more context to what you are trying to do.

[nico-rogasch]

Gosh sorry @v6 , I'm kinda slow in responding...to much work. But after I saw @yhyakuna adding the section to the documentation, I didn't feel the pressure any more ;)
I only have one thing to add here: the use case documentation concentrates on supplying secrets from the secrets engine from privileged users to non-privileged users.
Within our project we went even one step farther and are using Vault for all transfer use cases of sensitiv text information between all parties of the project.
That's because you don't need a privileged user to use the wrapping tool, the same non-privileged user can be used for both, wrapping and unwrapping.
This way we are enabling all of our project members to share secrets between teams & parties without requiring a Vault, or in our case GitHub Account, so even externals and business people can make use of this secure way of sharing secrets.