// , Degrade UI gracefully for KV version 2 secret backends without secret/metadata/... authorization

[v6]

Is your feature request related to a problem? Please describe.
Internal clients are sometimes frustrated when if they end up with a secret that they can read or create in the API, but not in the UI.

Let's say I have a Vault Secrets Engine with KV version 2, and I've creatively named it kv2.

If I grant a user full access to the path kv2/data/mysecrets/*, they can do the following:

~/proj/pubvault/duper/demonstrations/broken_kv2_ui |  (develop-broken-kv2-ui) 👾 curl --silent --header "X-Vault-Token: s.11gAdHULHUd0cJNppKCSLmNp" --request POST --data '{"data":{"floo": "blar", "zilp": "zalp"}}' "${VAULT_ADDR}/v1/kv2/data/mysecrets/mykv2secret" | jq
{
  "request_id": "740d75e6-bbec-9b95-f27e-f2b3c75d7604",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "created_time": "2018-11-22T01:16:11.374173288Z",
    "deletion_time": "",
    "destroyed": false,
    "version": 2
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}
~/proj/pubvault/duper/demonstrations/broken_kv2_ui |  (develop-broken-kv2-ui) 👾 curl --silent --header "X-Vault-Token: s.11gAdHULHUd0cJNppKCSLmNp" --request GET "${VAULT_ADDR}/v1/kv2/data/mysecrets/mykv2secret" | jq
{
  "request_id": "72f70134-ca97-4259-0f11-dbdb9e1f5ac3",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "data": {
      "floo": "blar",
      "zilp": "zalp"
    },
    "metadata": {
      "created_time": "2018-11-22T01:16:11.374173288Z",
      "deletion_time": "",
      "destroyed": false,
      "version": 2
    }
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

But they can't access this secret at all in the UI.

Sometimes this happens because kv2/metadata/mysecrets/... authorization isn't there, whether by mistake or intentionally.

Also, because lacking a policy with "list" capability on both a secret/metadata/ and secret/data/ means that the "Create Secret" dialog is not "findable", they can't create a secret with the UI as easily.

To allow a user to navigate to the Create Secret dialog from the Vault UI's "Home Page" I need to give that user a token whose Vault Policy has at least both of the following:

`path "kv2/data/" {
capabilities = ["list"]
}

path "kv2/metadata/" {
capabilities = ["list"]
}`

Describe the solution you'd like
If I grant a Vault Policy like the following, a user logging in to Vault with that policy can create, read, and delete secrets using the UI:

  ##  Currently doesn't quite work in the Vault UI
  ##  Not only can the user not navigate to that 
  ##  location from the Vault UI's "Home Page", 
  ##  but they also can't even use this secret in its
  ##  metadata-free form at 
  ##  http://192.168.13.37:8200/ui/vault/secrets/kv2/show/mykv2secret
path "kv2/data/mykv2secret*" {
    capabilities = ["create", "read", "update", "delete", "list"]
}

Describe alternatives you've considered
It's a pretty small problem, since I can always just authorize secret/metadata/mysecrets/... in the appropriate Vault Policy.

And, to make the Create Secret dialog show up in a way that can be navigated to from the Vault UI "Home Page", I can always modify the policy to add lines like the following:

`path "kv2/data/" {
capabilities = ["list"]
}

path "kv2/metadata/" {
capabilities = ["list"]
}`

Failing the above I could always just use KV version 1.

Explain any additional use-cases

Some of this is a matter of convenience. But if translating many Vault Policies from kv1 to kv2, it might be nice to be able to find and replace "secret/ with "secret/data in the Vault Policy Paths to make them work with KV2.

As far as creating a secret in KV2, and graceful degradation, if I assign a policy to a DBA which I have told can use the UI, I won't have to deal with an error with the policy getting reported in the event that I forget to add metadata authorization, or intentionally deny access to it for some paths.

Additional context
I've included more details here:

https://groups.google.com/forum/#!topic/vault-tool/lpaoopCzOQc

#5547

In case it helps with reproducing this situation, the exact development environment I used for this is at the following URL:

https://github.com/v6/super-duper-vault-train at 91c33c11b343140b8ee09b3117149ae691210e28

[v6]

// , Thanks @meirish !