Skip to content

Kubernetes Style Validation Policy #1213

@gree2313

Description

@gree2313

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"

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions