Capability to enable secret engine

Which path and capability needed to enable secret engine?

  • Expectation is:
    For example,
path "/mysecret/*" {
    ["create", "read", "update", "delete", "list", "sudo"]
}

If I have this policy, then I can enable any secret engine on /mysecret/* path.

But now permission denied.

The API used to create mount points is sys/mounts/:path:

You will need to give create access to sys/mounts/mysecret/* in order to enable mount points under mysecret. The documentation does not indicate that “sudo” is necessary (as it is to add an auth method.)

3 Likes

Thank you @mgritter
It works perfectly.

So after much experimentation and gnashing of teeth, I’ve discovered that for the Vault policy you need to be able to enable secret engines with any name (where you won’t know the name in advance), you actually need only the update permission.
The create permission doesn’t work!

This works:

"sys/mounts/*": {
  "capabilities": ["update"]
}

This doesn’t:

"sys/mounts/*": {
  "capabilities": ["create"]
}

I just wanted to put this here in case anyone else is pulling their hair out over this.

(This works in both Vault 1.2.2 Vault 1.8.0 for Key Value version 1 and 2 secret engines.)

1 Like