-
Notifications
You must be signed in to change notification settings - Fork 257
Description
Feature request checklist
- There are no issues that match the desired change
- The change is large enough it can't be addressed with a simple Pull Request
- If this is a bug, please file a Bug Report.
Change
I have a use case that is very similar to the Kubernetes Admission Policy Validations. I want to go through a set of CEL expressions and verify that my proto object ‘passes’ (evaluates to true) for each expression. If it fails a particular expression, I want to output an informative message.
Looking through the cel-go/policy testcases, it seems cel-go/policy can currently handle this particular case, but it requires the implementation of a custom TagVisitor and negating each expression within TagVisitor.MatchTag before it sets the condition for the map.
This use case seems relatively common, in which case it should be directly supported by cel-go/policy. I propose that cel-go/policy have a native implementation of this behavior to prevent the need for a custom TagVisitor. The YAML could have a validations node under rule that would signal to the policy parser to use validation behavior instead of match behavior. The validation node would contain a list of conditions and outputs, similar to match. Each condition would evaluate to true or false, if false the output is returned, if true, the next condition is executed. When it reaches the end and all the conditions have passed, the policy will have passed.
I am not sure how match and validations could work in the same policy file. It’s possible that a user should be limited to using either one or the other in the policy file.
This proposal doesn’t handle the Kubernetes case, given that Kubernetes has different YAML tags. However, it does cover the case for anyone like me who expects this behavior in a package that is ‘inspired’ by the Kubernetes Admission Policy Validation.
It might also be helpful to provide an example in the documentation on how to implement this behavior.
Example
An example using the new YAML would be
rule:
validations:
- condition: "something == 'condition_a'"
output: "condition a failed"
- condition: "something == 'condition_b'"
output: "condition b failed"