feat(kgo): added ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding for validating DataPlane ports

[pmalek]

What this PR does / why we need it:

Move DataPlane ports validation to ValidatingAdmissionPolicy.

Testing of these rules remains an aspect to tackle.

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• PR is based off the current tip of the main branch.
• Changes are documented under the "Unreleased" header in CHANGELOG.md
• New or modified sections of values.yaml are documented in the README.md
• Commits follow the Kong commit message guidelines

[pmalek]

Wait for #1216 to add chartsnap validation.

[czeslavo]

One thing I'm worried about is that we end up with the logic responsible for validating objects (we have CEL rules defined on CRDs in KCFG and now ValidatingAdmissionPolicy/Binding here) scattered over different places.

What do you think about defining these in KCFG, e.g. in a separate directory under config/validation/gateway-operator? That would allow testing them using the same test machinery we use for CRDs there and we would have a single place to live for the validation logic. We could "import" them in charts the same way we do with CRDs - copy them over to charts/gateway-operator/charts/gateway-operator-validation. One thing that is not clear to me is whether we could make the installation of a subchart depend on the capabilities like you did. Edit: We could have a dedicated script in charts/gateway-operator/scripts that would do the copying and adding conditional on capabilities to every file.

[pmalek]

One thing I'm worried about is that we end up with the logic responsible for validating objects (we have CEL rules defined on CRDs in KCFG and now ValidatingAdmissionPolicy/Binding here) scattered over different places.

I share this concern.

What do you think about defining these in KCFG, e.g. in a separate directory under config/validation/gateway-operator? That would allow testing them using the same test machinery we use for CRDs there and we would have a single place to live for the validation logic. We could "import" them in charts the same way we do with CRDs - copy them over to charts/gateway-operator/charts/gateway-operator-validation. One thing that is not clear to me is whether we could make the installation of a subchart depend on the capabilities like you did. Edit: We could have a dedicated script in charts/gateway-operator/scripts that would do the copying and adding conditional on capabilities to every file.

That would be nice to put in kcfg which is a dedicated repo ATM for these things. I'm worried this will make the workflow here unnecessarily complicated and error prone 🤔 The subcharts approach seems to me quite problematic to update and maintain but perhaps the reason for this is not enough automation on our side.

The problem I see with using kcfg is that we might not want to create numerous releases in that repo which then would create unnecessary dependency updates in other repositories (and also be user facing)

I'm happy to discuss this further as I believe the approach you proposed has advantages.

whether we could make the installation of a subchart depend on the capabilities

That I believe would not be possible as according to https://helm.sh/docs/topics/charts/#the-chartyaml-file the condition is A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )

[pmalek]

As agreed on slack: we keep the definition of policies for now both in charts and in KGO repositories. When we decide to move the charts internals (the releases would remain in charts) to KGO then we use the policies from KGO's repo.

Waiting on this one to get a final review in Kong/gateway-operator#1007.