Policy behavior are reflected differently via CLI and web UI

[GonzalezAndrew]

Describe the bug
When using ACL template policies, both the Vault CLI and web UI are showing different behaviors. I am trying to establish a secret shared environment that allows users to create their own secrets but not see any other users secrets or pathing. The Vault CLI correctly illustrates this but the web UI throws a permission denied statement indicating the user does not have the right credentials.

To Reproduce
Steps to reproduce the behavior:

1. a) Provision the template policy with Terraform:

resource "vault_policy" "users" {
  name = "base-user"
  policy = <<EOT
path "secret/data/{{identity.entity.name}}/*" {
  capabilities = ["create", "update", "read", "delete", "sudo"]
}

path "secret/metadata/{{identity.entity.name}}/*" {
  capabilities = ["list", "read", "create", "update", "delete"]
}
EOT
}

1. b) create the Entity with the Alias

resource "vault_identity_entity" "user" {
    name = "user"
    policies = ["base-user"]
}
resource "vault_identity_entity_alias" "user" {
    name = "user"
    mount_accessor = "auth_userpass_XXXXXX"
    canonical_id = vault_identity_entity.user.id
}

1.c) create the user

$ vault auth enable userpass
$ vault write auth/userpass/users/user password=test 

2. CLI test

$ curl --request POST --data '{"password": "test"}' http://0.0.0.0:8200/v1/auth/userpass/login/user | json_pp

$ curl --header "X-Vault-Token: ..." --request LIST http://0.0.0.0:8200/v1/public/metadata/user-name/ | json_pp.

{
   "request_id" : "",
   "warnings" : null,
   "auth" : null,
   "data" : {
      "keys" : [
         "test"
      ]
}

3. Web UI test

permission denied

Expected behavior
Both Vault CLI and web UI should allow users to create their own secrets in the shared environment while not being able to see each others secrets or pathing.

Environment:

• Vault Server Version (retrieve with vault status):

Key                      Value
---                      -----
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    1
Threshold                1
Version                  1.2.3
.....

• Vault CLI Version (retrieve with vault version):

Vault v1.2.3

• Server Operating System/Architecture: Amazon Linux 2

Vault server configuration file(s):

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}
storage "s3" {
  bucket     = "${s3_name}"
  region     = "${aws_region}"
  kms_key_id = "${kms_key}"
}
seal "awskms" {
  region = "${aws_region}"
  kms_key_id = "${kms_key}"
}
ui = true

Additional context
The only work around I have been able to find was to allow all users in the shared environment to list the metadata. Of course this will show everyones name and with a large number of users can become overwhelming.

# web UI
path "secret/metadata" {
  capabilities = ["list"]
}

Documentation & resources I used to create my template policies:

• https://www.vaultproject.io/docs/concepts/policies.html

• https://www.vaultproject.io/docs/secrets/identity/index.html

• https://learn.hashicorp.com/vault/identity-access-management/iam-identity

[dvmonroe]

@catsby This issue appears to still hold true for 1.3.x.

Not only that, but it appears the setup based on the documentation doesn't work at all for UI access.

To reproduce

Follow pattern in documentation WITH OP's fix

path "test-secret/metadata/*" {
  capabilities = ["list"]
}
path "test-secret/data/foobar/*" {
  capabilities = ["read"]
}
path "test-secret/metadata/foobar/*" {
  capabilities = ["list"]
}

• Create v2 kv engine called test-secret
• Create secret with the name of foobar
• Make a request via UI at https://xxxxxx/ui/vault/secrets/test-secret/show/foobar to see 403 unauthorized error

Workaround policy

• Adds OP's fix
• Remove the metadata path list capability (server will return a 403 on the network request but doesn't impact UI)
• Remove the forward slash with the asterik on the secret/data/foobar path

path "test-secret/metadata/*" {
  capabilities = ["list"]
}
path "test-secret/data/foobar" {
  capabilities = ["read"]
}

Maybe I'm misreading the documentation? Thanks

[Monkeychip]

@dvmonroe Thank you for the extra details. We have made quite a few changes to the KV secret engine since the 1.3 release. Most noteable re: metadata is this PR in 1.9 that added a metadata specific tab. This feature solved several permission issues.

A note on the policies you listed: The reason the first policy does not work is because of the /* after foobar. This is essentially saying give read permissions to any nested secret under foobar, but it does not give read permissions to the secret "foobar". Here is what a nested secret path looks like on the UI.

This can be confirmed by looking in the dev console and seeing the permissions error in the network request. Here is the network request to read "foobar".

And here is the network request to read the secret at "foobar/hello"

@GonzalezAndrew let me know if you're still hitting permissions issues on a newer version of Vault. As this PR was made quite a while ago, we will close the ticket in 6 months if there are no new comments or confirmation of this still being an issue.

[GonzalezAndrew]

@Monkeychip Thank you for the update. I no longer work at the company where I was seeing this issue with Vault. This issue can be closed out if need be.