"You do not have access to the sys/mounts endpoint. The secrets engine was not mounted."

Vault
1

I’ve tried to create a k/v engine in Vault and get this message:

“You do not have access to the sys/mounts endpoint. The secrets engine was not mounted”

Any ideas?

Vault v. 1.15.5 on Debian

2

Which policies are associated with your Vault token?

4

thanks for picking this up - for learning and demonstration purposes in the context of this issue, I have created a policy called “rootpolicy” and assigned it the group I am member of.

Policy:

path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "patch"]
}

In my setup, I have two browsers, one for the root token login, one fo user login.

On user relogin, I don’t get root rights and see just the default engine “cubbyhole”.

How is this possible?

5

update - the baseline of it has been now removing all the experimental policies from the LDAP group and giving it the default “empty” policy called “root”. Same effect - that is, no effect.

6

Annoyingly, this isn’t a complete answer. I know there are quite a few posts in this forum starting with the simple policy you’ve called rootpolicy – others have called it a simple admin policy – but I can’t seem to pull up the one I’m looking for, nor the relevant documentation. :confused:

What I have found is that sys/mounts is not a root-protected API endpoint. (Here’s a link to the full list of those, fyi.)

And, if you ask Vault to print out the policy required to enable a K/V secrets engine, it doesn’t list sudo either:

$> vault secrets enable -output-policy -path=kv-test/ kv
path "sys/mounts/kv-test" {
  capabilities = ["create", "update"]
}

Incidentally, if you want to list what you’ve enabled, you’ll also need:

$> vault secrets list -output-policy
path "sys/mounts" {
  capabilities = ["read"]
}

But what is messing with me is that your broad globbing policy should match all the paths in sys/ as well, and therefore give create, update, and all the others you’ve listed on all of them. This (very handy!) policy guide even implies as much!

So, yes, with the specific policies I’ve listed above, you should be able to enable and list secrets engines, but, sadly, I don’t have an explanation for why your current policy of rootpolicy isn’t working.

7

We could solve the problem by establishing same group naming.