The required_parameters Constraint is Applied on Operations that don't Take Parameters

[marcboudreau]

Describe the bug When a policy which grants the create, read, update, and delete capabilities, but also includes a required_parameters constraint is applied for a path. All requests, including read and delete must include the required parameters.

To Reproduce Steps to reproduce the behavior:

1. Set up the policy file

   $ echo 'path "ssh/roles/*" {
   capabilities = [ "create", "read", "update", "delete" ]
   required_parameters = [ "max_ttl" ]
   allowed_parameters = {
   "max_ttl" = [ "60m0s" ]
   }
   }' > my-policy.hcl

2. Launch Vault

   $ docker run -d --name vault -v $PWD/my-policy.hcl:/my-policy.hcl -e VAULT_TOKEN=root -e VAULT_ADDR=http://127.0.0.1:8200 vault:latest vault server -dev -dev-root-token-id=root
   b4e70524e7485bc10be2a611581e9c2f1469532eea63f72a957b6a90530dd7ba

3. Mount a KV secrets engine at the path ssh

   $ docker exec vault vault secrets enable -path=ssh kv
   Success! Enabled the kv secrets engine at: ssh/

4. Write the policy

   $ docker exec vault vault policy write my-policy /my-policy.hcl
   Success! Uploaded policy: my-policy

5. Create a token that has the policy assigned

   docker exec vault vault token create -id=token -policy=my-policy
   Key                  Value
   ---                  -----
   token                token
   token_accessor       1CKMLi0nFBJUqioWc9HUaeLj
   token_duration       768h
   token_renewable      true
   token_policies       ["default" "my-policy"]
   identity_policies    []
   policies             ["default" "my-policy"]

6. Attempt to read the path ssh/roles/any, which is covered by the policy in place

   
   $ docker exec -e VAULT_TOKEN=token vault vault read ssh/roles/any
   Error reading ssh/roles/any: Error making API request.

URL: GET http://127.0.0.1:8200/v1/ssh/roles/any Code: 403. Errors:

• 1 error occurred:

• permission denied

  7. By including the required parameter `max_ttl` parameter, the request is allowed.

  $ docker exec -e VAULT_TOKEN=token vault vault read ssh/roles/any max_ttl=60m0s No value found at ssh/roles/any

Expected behavior I expected the result of step 6 (above) to be exactly the same as step 7.

Environment:

• Vault Server Version (retrieve with vault status):

  $ docker exec vault vault status
  Key             Value
  ---             -----
  Seal Type       shamir
  Initialized     true
  Sealed          false
  Total Shares    1
  Threshold       1
  Version         0.11.3
  Cluster Name    vault-cluster-d3a57a56
  Cluster ID      e1de44ab-ce64-05d0-4c29-761a4303a45a
  HA Enabled      false

• Vault CLI Version (retrieve with vault version):

  $ docker exec vault vault version
  Vault v0.11.3 ('fb601237bfbe4bc16ff679f642248ee8a86e627b')

• Server Operating System/Architecture:

  
  $ docker exec vault uname -a
  Linux b4e70524e748 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 Linux
  $ docker version
  Client: Docker Engine - Community
  Version:           18.09.0
  API version:       1.39
  Go version:        go1.10.4
  Git commit:        4d60db4
  Built:             Wed Nov  7 00:47:43 2018
  OS/Arch:           darwin/amd64
  Experimental:      false

Server: Docker Engine - Community Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.12) Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:55:00 2018 OS/Arch: linux/amd64 Experimental: true $ uname -a Darwin [hostname] 18.2.0 Darwin Kernel Version 18.2.0: Fri Oct 5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64 x86_64

Vault server configuration file(s):
*Used default configuration for Server in **dev** mode.*

**Additional context**
I understand why the request results in a permission denied error.  But it seems counter-intuitive that a parameter constraint would be applied to requests that do not take parameters.

I discovered this behaviour when trying to put together a policy that allows operators in charge of administering the instance of the **ssh** secrets backend.  I wanted to have a policy that allows them to create, review, and remove roles, hence the `ssh/roles/*`, all the while being assured that no roles are created with a max_ttl other than `60m0s`.

I tried creating two separate rules in the policy, with the same path.  One that grants `read` and `delete` capabilities; and the other that grants `create` and `update` and has the same constraints as described in the above test case.  But that doesn't work because one rule simply supersedes the other.

[jefferai]

They're not commonly used, but read and delete can take parameters, so this behavior is correct per se. We might be able to enhance it to allow different capabilities provided in different path statements to have different params by capability type.

[marcboudreau]

Agreed. Thanks for considering this issue.

[lxop]

I've just run into this myself. Is there any suggested workaround?

I would assume that this must be a reasonably common situation - almost any time that parameters are required for a create/update, they would not be required for read/delete, and having read access on a path that one has write access to must be pretty common.

Also, I notice that delete works without supplying the required parameters - I haven't checked the source to see if it is being special-cased.

[LuckyStiff]

I've tried two separate policies on the same path. Nevertheless, when I add them to one user I had the same issue. I more or less could understand when the system combines two rules from one policy, but why the system merges two policies in one is a complete secret for me. I think the next solution will work - create 2 different users with 2 different policies one will only read another write, but as you understand it is extremely uncomfortable. It needs to be fixed. Vault v.1.4.1

[LuckyStiff]

They're not commonly used, but read and delete can take parameters, so this behavior is correct per se. We might be able to enhance it to allow different capabilities provided in different path statements to have different params by capability type.

With the described situation

vault read -field=parameter engine/secret

fails also. Maybe there are some other ways to read with a parameter, but I hadn't found them. Could you please give an alternative command?

[vishalnayak]

Issues that are not reproducible and/or have 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. If a feature request is being closed, it means that it is not on the product roadmap. 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.

[heatherezell]

Hi folks! Is this still an issue in newer versions of Vault? Please let me know so I can bubble it up accordingly. Thanks!

[n2ux]

Hi folks! Is this still an issue in newer versions of Vault? Please let me know so I can bubble it up accordingly. Thanks!

Yes, this is still an issue at least in Vault 1.15.5