KV version 2 seems to deny request with allowed_parameter policies

[HT43-bqxFqB]

Environment:

• Vault Version: 0.10.0
• Operating System/Architecture: CentOS 7

Vault Config File:

{
  "backend": {
    "file": {
      "path": "/var/lib/vault"
    }
  },
  "default_lease_ttl": "24h",
  "listener": {
    "tcp": {
      "address": "0.0.0.0:8200",
      "tls_cert_file": "/etc/vault/cert.pem",
      "tls_cipher_suites": "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
      "tls_key_file": "/var/lib/vault/tls/certificate.key",
      "tls_min_version": "tls12",
      "tls_prefer_server_cipher_suites": "true"
    }
  },
  "max_lease_ttl": "817600h",
  "ui": "true"
}

Expected Behavior: ACL with allow_parameters should allow kv creation:

# kv version 2
path "sec/data/*" {
    capabilities = [ "create", "list", "update", "read", "delete" ]
    allowed_parameters = {
        "password" = []
        "url" = []
    },
}

Actual Behavior:

vault kv put se/server/xyz.domain.com/user/root password=PA55W00RD
Error writing data to se/server/xyz.domain.com/user/root: Error making API request.

URL: PUT https://vault:8200/v1/sec/data/server/xyz.domain.com/user/root
Code: 403. Errors:

* permission denied

The put request only works when the allowed_parameter part in the hcl is removed and the policy is updated.

Steps to Reproduce:

• Create kv vault secrets enable -path=sec -version=2 kv
• Create policy with allowed_parameters
• Create kv pair -> permission denied
• Overwrite policy without allowed_parameters
• Create kv pair -> success

[jefferai]

The problem is that values for KVv2 live in a data map, not at a top-level. This is necessary for it to be able to provide extra functionality, as we have to be able to separate out what should be stored from things like metadata. Additionally, since technically it's a JSON store the values can be arbitrarily complex.

allowed_parameters can't really express digging down to arbitrary levels of a map...neither HCL nor the JSON it is compatible with is good at doing that. You can do this kind of thing with Sentinel policies since it's a real language. I'll keep this open for some future consideration but as of right now my guess is that this won't ever be able to be supported for KVv2.

[HT43-bqxFqB]

Thanks for the info! Maybe it should be mentioned in the policy documentation when the allowed_parameters parameter is explained.

Kind regards, Martin.

[arusso]

This also seems to apply to required_parameters as well.

[bigman3]

@jefferai just to confirm, required_parameters, allowed_parameters and denied_parameters are not supported on kv-v2, correct?

[saites]

I propose the documentation for Policies call this out explicitly, as I misunderstood the information there to imply that I could do such a thing. I wasted a bunch of time trying to get it to work, searching for information on what I was doing wrong, only to finally land here and see that it's not actually supported. It seems I'm not the only one, so I think it'd be pretty helpful for future readers to see a quick note on it (assuming it's not already there, and I just missed it!).

[vishalnayak]

Issues that are not reproducible and/or not had any interaction for a long time are stale issues. Sometimes even the valid issues remain stale lacking traction either by the maintainers or the community. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant but is wrongly closed, we encourage reopening them.

Please refer to our contributing guidelines for details on issue lifecycle.

[rakshitzen]

Any updates on this issue?