Limit user to a specific type of Secrets Engine

Vault
1

How can I set up Vault so that users are only able to create a KV type secrets engine?
I plan on using this type of policy that lets users create a secrets engine matching to their login name and create secrets under it.

path “{{identity.entity.aliases.auth_oidc_748976a3.name}}/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}

path “sys/mounts/{{identity.entity.aliases.auth_oidc_748976a3.name}}” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}

2

I’d be cautious about allowing arbitrary creation of KV mounts as there are upper limits to the number that can be created as detailed in the Limits and Maximum Values guide.

I’d suggest using a single KV mount and applying permissions such that each user has their own folder.

However, if you’re dead set on the mount per user approach, then a policy that leverages Fine Grained Controls may work. Something like this, perhaps:

path “sys/mounts/” {
  capabilities = [“read”]
}

path “sys/mounts/{{identity.entity.aliases.auth_oidc_748976a3.name}}/*” {
  capabilities = [“create”, “read”, “update”, “delete”]
  allowed_parameters = {
    "type" = ["kv"]
    "*"      = []
  }
}

Note that the Fine Grained Controls only work on root keys that are of type string, bool, or number (i.e., lists and maps are not supported). You won’t be able to enforce anything in the config parameter of the sys/mounts endpoints with this method.

I hope this helps.

3

As mentioned elsewhere, you cannot do that. Though you may be able to in Sentinel but that needs the Enterprise edition.

What you can do though, is have a provisioning step. I do the same for LDAP users and require them to provision. The provisioning process will create the KV store and push a “test” secret, that they can then read to validate all went well. It’s 2-3 API calls - so adapt to your internal process. By provisioning you can also keep some control over how many KV’s there are ( There is a 7K max !! ).

If you do go this route, also look into creating identities and linking them to the OIDC identity aliases prior. It gives you a “central” identity point that you may be able to leverage across other authentication methods. If you are using Enterprise or HCP - it also aggregates the client to the Identitiy, reducing your client count (YMMV)

The main reason I did this, we have users that flip from Contractor to permanent and it changes their LDAP identity. By giving users their own secrets store, it more secure to give an admin “Move mount” policy than have to read-write secrets in subdirectories. But it did force us to provision spaces.