New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The required_parameters Constraint is Applied on Operations that don't Take Parameters #5856
Comments
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. |
Agreed. Thanks for considering this issue. |
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. |
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 |
With the described situation
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? |
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. |
Hi folks! Is this still an issue in newer versions of Vault? Please let me know so I can bubble it up accordingly. Thanks! |
Describe the bug
When a policy which grants the
create
,read
,update
, anddelete
capabilities, but also includes a required_parameters constraint is applied for a path. All requests, includingread
anddelete
must include the required parameters.To Reproduce
Steps to reproduce the behavior:
ssh
ssh/roles/any
, which is covered by the policy in placemax_ttl
parameter, the request is allowed.Expected behavior
I expected the result of step 6 (above) to be exactly the same as step 7.
Environment:
vault status
):vault version
):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 than60m0s
.I tried creating two separate rules in the policy, with the same path. One that grants
read
anddelete
capabilities; and the other that grantscreate
andupdate
and has the same constraints as described in the above test case. But that doesn't work because one rule simply supersedes the other.The text was updated successfully, but these errors were encountered: