ATM we are binding request and namespaceObject as DynType.
This is a workaround since recursively add sub-types to NativeTypes is not possible yet.
Instead, we need to bind our k8s-objects to the cel environment.
This allows the CEL compiler to type-check the expressions.
Once the PR above is merged, we need to create a custom type provider based on the CEL NativeType.
This type will have the same behaviour of the vanilla NativeType, but it will convert downcase fields to uppercase. This is needed to be as close as possible to Kubernetes ValidatingAdmissionPolicy (which binds proto-generated objects instead).
namespaceObject and request must be type-checked during the compilation. Unknwon fields and invalid types operations must raise an error at compile time.
Alternatives you've considered
Using proto-generated objects.
This alternative has been discarded because it's simpler to bind a NativeType based on kw k8s-objects.
Is your feature request related to a problem?
ATM we are binding
requestandnamespaceObjectasDynType. This is a workaround since recursively add sub-types toNativeTypesis not possible yet. Instead, we need to bind our k8s-objects to the cel environment. This allows the CEL compiler to type-check the expressions.This WIP PR introduces the recursive
NativeType: https://github.com/google/cel-go/pull/892Once the PR above is merged, we need to create a custom type provider based on the CEL
NativeType. This type will have the same behaviour of the vanillaNativeType, but it will convert downcase fields to uppercase. This is needed to be as close as possible to KubernetesValidatingAdmissionPolicy(which binds proto-generated objects instead).Example:
Acceptance criteria
namespaceObjectandrequestmust be type-checked during the compilation. Unknwon fields and invalid types operations must raise an error at compile time.Alternatives you've considered
Using proto-generated objects. This alternative has been discarded because it's simpler to bind a NativeType based on kw k8s-objects.