Remove GatewayConditionInsecureFrontendValidationMode

[howardjohn]

This condition does not seem useful to users nor consistent with API conventions https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md.

We are just mirroring a field in the spec into the status. There is no value to the user. Its just complexity and API bloat for no benefits.

The user already knows they are using an insecure mode, its literally called AllowInsecureFallback. There is no chance someone is going to type AllowInsecureFallback and then look at the status and realize "oh maybe this is insecure" (I don't dispute someone will type AllowInsecureFallback and not realize its insecure; just that a status message won't help them 🙂 )

I would propose removing this condition.

[robscott]

cc @snorwin @kl52752

[kl52752]

This status was a proposal from @shaneutt #3960 (comment).
I personally agree that it is not adding more security to Gateway and might be confusing.

[snorwin]

The idea behind the condition was to emit a warning about the security implications of the configuration. Exposing this as a condition also enables use cases such as creating alerts via kube-state-metrics. More generally, it improves visibility since the condition is represented at the top level rather than being just another setting buried in the spec.

In my opinion, requiring implementations to emit an Event might align better with Kubernetes best practices. However, we have not used Events so far, which is why I see the condition as a reasonable alternative.
It is certainly reasonable to question whether introducing the condition is the right approach. That said, I would greatly appreciate receiving this kind of feedback during the refinement phase of the GEP, rather than immediately before graduation to standard.

[howardjohn]

The idea behind the condition was to emit a warning about the security implications of the configuration.

The field is called insecure. What more could you need?

Do other projects have status messages for insecure? Not that I am aware of -- there are plenty on Pod.

If users want to see a field that is in the spec, they can look at the spec. Status should be used for things that cannot be derived from the spec directly like "this IP was not provisioned" or "this combination of fields is invalid", not just copy+paste the spec.

That said, I would greatly appreciate receiving this kind of feedback during the refinement phase of the GEP, rather than immediately before graduation to standard.

This feedback was received immediately after conformance tests requiring it were released. Had those been released sooner this feedback would have been given sooner. Sorry that means its given immediately before graduation, but there is a lot going on in the API -- the only way to make something really known IMO is a test. Shifting conformance tests up (maybe along with the monthly releases) may help here.

[youngnick]

I'm okay with removing the Condition, but if we're going to do it, it needs to be now. This is not a release blocker, so we have until the final freeze to get it removed.