Using engines as fallback mechanism

[JaydipGabani]

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Right now there Gatekeeper evaluates only one engine in priorities with K8sNativeValidation engine being the highest priority. Is it worth implementing a mechanism to parallelize evaluation through multiple engine?

Proposal 1

All engines are evaluated, even if one denies we deny.

Pros:

• Assuming one engine has syntactical error, other one can provide accurate decision
• Avoid false negative (admission of non-complaint resource), when using FailurePolicy: ignore. This being a conservative approach, we also avoid admission of non-complaint resources when there is a logical error in one engine and not in the other. This also means that an engine might deny admission of complaint resource because of logical error in one and not in the other engine.

Proposal 2

Fastest engine wins.

Pros:

• Fastest possible latency at admission.

Use cases

I am an organization looking to migrate to K8sNativeValidation engine and eventually move to VAP.

• I have Templates with Rego that are stable. Management of duplicate CT/C containing CEL during migration from Rego to CEL is cumbersome. I would like to update the Templates I have and add k8sNativeValidation engine but I am skeptical because of moving stable Templates to unstable state by adding CEL is not desirable. I would like to have fallbacks within engines to avoid as much errors as I can.

@ritazh @maxsmythe @sozercan Any thoughts on this^^? Is this something that users can benefit from? Lmk your thoughts. We can discuss this in community meeting as well.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Gatekeeper version:
• Kubernetes version: (use kubectl version):