Sudo Policies for secret engines

Vault
1

Hello! I am just beginning to work with the Vault and I want to create a policy for two admins, so that we do not use the root token, but can all the necessary access and permissions. We have already created several secret engines. But I am stuck with the following:
I create a test-admin policy with following permissions:

Manage secrets engines

path “sys/mounts”
{
capabilities = [“read”, “list”, “write”, “update”,“sudo”]
}

Then a I generate a token for this policy and if I list the capabilities everything looks good. But if an logging it using the generated token, I can only see the cubbyhole. What an I doing wrong?
If I use the recommended configuration from Vault Policies | Vault - HashiCorp Learn the problem persists. Is it because we created the secret engines as the root? And is there a way to make the secret engines created under root to be seen by others?

2

There is a lot of jump around in your post so these answers will be out of your order:

  • There is no ownership in vault, only permission. Everything is also deny-first. So for anything on the system to be visible the token requesting that object must have permission to do so, doesn’t matter what other token created it.
  • sys/mounts is a read-only end point, there is no point in write, update, sudo, etc. See: /sys/mounts - HTTP API | Vault by HashiCorp, it only has 1 GET method.
  • sys/mounts/* is a different path and I think that’s what’s your looking for. (Note: * is not a regex wild card in Vault, here it means any object at this location).
  • Mounting the same engine multiple times (specially the KV engine) is almost NEVER the answer. You can do what you want with paths and policies rather than remounting the engine. There are cases for it, but they are far and few in-between.
  • Yes, you need to setup and use local admin users and revoke the root user.
  • To help you better understand policies and what is needed, turn on the audit log. Here you’ll see the requests and paths and it makes writing policies a lot easier.

Here is a simple example, but with more complex requirements multiple requests go out and each need to be parsed to create a policy:

$ vault secrets enable -path=ssh-prod ssh
Error ...
        * permission denied

Look at the audit output – recognize the different types of polices that applies to your token and where each policy starts and ends.

{
  "type": "response",
    "policies": [
      "default",
      "vault-admin",
      "pki-rw-access"
    ],
    "token_policies": [
      "default"
    ],
    "identity_policies": [
      "vault-admin",
      "pki-rw-access"
    ],
...
  "request": {
    "operation": "update",
...
    "path": "sys/mounts/ssh-prod",
...
  "error": "1 error occurred:\n\t* permission denied\n\n"
}

What the audit log is showing is that the current token lacks “update” access to: “sys/mounts/ssh-prod”.

To allow this specifically:

path "sys/mounts/ssh-prod" { capabilities = ["update"] }

To allow this generally to mount any engine:

path "sys/mounts/*" { capabilities = ["update"] }

In reality you should add the following to your admin policies:

path "sys/mounts/*"{  capabilities = ["create", "read", "update", "delete", "list", "sudo"]}

While learning, this is going to be an iterative process, add one permission try the command again, add more permissions, try again. (The good news is the policy of the token is not cached, each request re-reads the policy so just updating the policy applies the changes to the system.

1 Like
3

Hi Aram!

Thank you so much for your detailed answer.
I am going to check the audit logs right away. In the meanwhile I would like to add that I updated my policy the way you specified it
path “sys/mounts/*”
{
capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”]
}

But I get the same result. Logging in with a different token to which this policy applied
shows only the engine that were created when logged in with this token, while when I login with a root token I can see the engine a created with a new token.
I am feeling confused :confused:

I also just checked that I can see all the mounts in the Terminal uf the Web UI through vault read sys/mounts when logged in with a new token
But they are not shown in the Web UI itself. Probably there should be a different policy for that?

4

Now I got it! :slight_smile:

I had to specify the path with the exact path to the already created engines in the policy. Now everything looks fine.
Thank you very much for your help!