Permissions for "/v1/sys/mounts"

[Thomas....@gmx.de]

What permissions in the ACL do I have to set to list the mounts via API:

curl -k -sS -q --header "X-Vault-Token: $VAULT_TOKEN" "$VAULT/v1/sys/mounts"

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

This does not work.

This is our "admin-acl" which works fine with the curl above.

But I'm looking only for the parts which allows the sys/mounts part.

# Manage auth methods broadly across Vault
path "auth/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}


# Create, update, and delete auth methods
path "sys/auth/*"
{
  capabilities = ["create", "update", "delete", "sudo"]
}


# List auth methods
path "sys/auth"
{
  capabilities = ["read"]
}


# To list policies - Step 3
path "sys/policy"
{
  capabilities = ["read"]
}


# Create and manage ACL policies via CLI
path "sys/policy/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}


# Create and manage ACL policies via API & UI
path "sys/policies/acl/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}




# List, create, update, and delete key/value secrets
path "*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}


# Manage and manage secret engines broadly across Vault.
path "sys/mounts/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}


# Read health checks
path "sys/health"
{
  capabilities = ["read", "sudo"]
}


# To perform Step 4
path "sys/capabilities"
{
  capabilities = ["create", "update"]
}


# To perform Step 4
path "sys/capabilities-self"
{
  capabilities = ["create", "update"]
}

[Brian Kassouf]

Hi,

Try adding the following policy which will allow read access to the mounts

path "sys/mounts"
{
  capabilities = ["read"]
}

Best,

Brian

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/f29aaa9b-242a-4a65-a8bb-a4c75ae4efc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas....@gmx.de]

okay that worked so far, but now I can see every mount.

what if I want to just to see 2 out of 4, do i have to define every mount in a single path?

path "sys/mounts/test"

{

  capabilities = ["read"]

}

path "sys/mounts/test1"

{

  capabilities = ["read"]

}

or can I shrink this more?

[Thomas....@gmx.de]

What I wrote before doesnt work btw... any idea?

[Brian Kassouf]

That "sys/mounts/test" API doesn't exist. Check out
https://www.vaultproject.io/api/system/mounts.html#read-mount-configuration
for reading the mount configuration. This however doesn't return as
much info as the "sys/mounts" endpoint and there isn't a standalone
equivalent to it.

Best,
Brian

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/794bd4ba-11e5-4d4b-846d-0370e5a36d5e%40googlegroups.com.

[Thomas....@gmx.de]

But shouldn't return sys/mounts only what I can see via the webinterface?

path "test/*" {
  capabilities = ["read", "list"]
}

-> this gives me read/list access to test 

so for example if I have a second secret called "test1" which exists but is not defined in the acl:

path "sys/mounts"
{
  capabilities = ["read"]
}

path "test/*" {
  capabilities = ["read", "list"]
}

then the above acl with this api call:

curl -k -sS -q --header 'X-Vault-Token: TOKEN' https://bor-vault.boreus.de/v1/sys/mounts

will return "test & test1", but I expect just to get "test" .. or not?

[Calvin Leung Huang]

Thomas,

The ACL system performs permissions checking at the path level provided in the policy, and does not process responses to alter results such as returning a filtered response from a sys/mounts request. Having read permission on sys/mounts simply means that the token will have permission to perform a GET API request against that endpoint, which essentially means the token is allowed to hit that endpoint. In this particular case, even though the enabled mounts are returned, accessing those mounts would require specific ACL policies for them.

- Calvin