Policy for private engine

Vault
1

Hi,

I would like every user to be able to create a private secret engine without the intervention of the administrator? How to do?

Regards,
AN

2

It’s an interesting use case. Though you may be able to allow your users to perform CRUD operations on sys/mounts/* to mount the secret engine, how do you allow them to use the secret engine they just mounted without giving them policy administration rights?

I would like to hear more about your use case. Have you considered using the Cubbyhole secrets engine for that? It may not be a good fit for you, since it’s better suited for time-limited single-use tokens like the ones used for response wrapping.

3

You would need to explain your use case in a lot more detail, for anyone to provide good advice. You haven’t even mentioned which kinds of secret engine.

4

@macmiranda as you write cubbyhole is time limited by token.
@maxb I would like to use vault as an ordinary password manager such as passbolt, so that each user can create an engine depending on what he wants to store. Why should the administrator create an engine for the user? In my opinion, the user should be able to create private engines without administrator intervention

5

This is not really a target use-case for Vault. Why not use Passbolt instead, since that’s actually intended to be used in that role?

OK, what I’m hearing here is that you probably only care about KV secrets engines. That’s an important piece of information - Vault has many different secrets engines, and your initial message sounded like you wanted a generic solution regardless of secrets engine type.

The Vault architecture prioritizes certain use-cases and does not support others well.

You are free to have whatever opinions you like, but you’re basically saying “In my opinion, Vault should be a different product to what it is.” You’re welcome to hold that opinion, but it doesn’t really lead to a useful conversation.

In an attempt to drag this conversation back in a more useful direction:

  • Vault is not designed to act as a personal password manager
  • Vault can be somewhat pressed into the role of one, by use of the KV secrets engine, paths which include a user’s username, and ACL policy path templating, to grant each user access to a private path within Vault
  • The user experience created by doing so won’t be as good as a dedicated personal password manager - ultimately, you’d still be using the generic KV store web UI
  • When such a setup is usually talked about, the pattern is generally to give users separate sub-paths within a single shared KV secrets engine
  • It is technically possible to adjust this pattern to use a separate KV secrets engine per user
  • If so, it’s probably best that an administrator pre-create these KV secrets engines on the behalf of each user
  • Self-service creation of per-user KV secrets engines is technically possible to write policy to allow, but the initial setup user experience will be poor - the user will need to be carefully guided by some custom documentation, on exactly what to click and type, as they navigate the secret engine creation UI, which is intended for people with Vault administration experience.
6

Hi,

Thanks for the answer and explanation of the functionality as it is not clearly explained in the product description