WIP: Constraints #233
WIP: Constraints #233
Conversation
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ |
There was a problem hiding this comment.
@Cerfoglg great start thanks so much for this. I've commented on some bits of the code where I think the current approach could be hard to extend. Not that we need to do anything fancy at the moment, this PR was meant to explore the solution space which IMO it accomplishes pretty well. So my comments are only meant to highlight that it could be hard for us to implement generic constraints with the current architecture.
In general, I think it'd be hard to support anything else than plain constraints. E.g. think recursion, needed to support arbitrary nested constraints. Also in general, I think it'd be hard to implement (a useful enough subset of) ODRL
Thoughts?
| current_path[2] == "entities" | ||
| current_path[3] == entry.resource | ||
| constraints := split(entry.constraint, " ") | ||
| constraints[0] == "acl-oc:ResourceName" |
There was a problem hiding this comment.
how would we use this in teadal? every API would need to have its own rego file w/ a path_matches_policy definition I suppose. That's fair enough, but then we'd have to duplicate the constraints logic in each and every file? also, what if I want to check request fields (e.g. method) or data fields in the JSON payload in the case of a POST?
| current_path[1] == "v2" | ||
| current_path[2] == "entities" | ||
| current_path[3] == entry.resource | ||
| constraints := split(entry.constraint, " ") |
There was a problem hiding this comment.
what if there's extra whitespace in the constraint? e.g. " > 5 "
| @@ -0,0 +1,31 @@ | |||
| package envoy.authz | |||
There was a problem hiding this comment.
cool, but what about e.g. boolean operators? e.g. what would I do if I wanted to express a constraint like (x < 5 && x > 10) || x > 20...
Proposed changes
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to
that issue.
Types of changes
What types of changes does your code introduce to the project: Put
an
xin the boxes that applyfunctionality to not work as expected)
Checklist
Put an
xin the boxes that apply. You can also fill these out aftercreating the PR. If you're unsure about any of them, don't hesitate to
ask. We're here to help! This is simply a reminder of what we are going
to look for before merging your code.
feature works
downstream modules
Further comments
If this is a relatively large or complex change, kick off the discussion
by explaining why you chose the solution you did and what alternatives
you considered, etc...