GEP 91: Update API

[arkodg]

trafficstars

Relates to https://github.com/kubernetes-sigs/gateway-api/discussions/3760#discussioncomment-12997389

What type of PR is this?

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: arkodg Once this PR has been reviewed and has the lgtm label, please assign thockin for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

@arkodg: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-gateway-api-crds-validation-3	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-crds-validation-3
pull-gateway-api-test	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-test
pull-gateway-api-crds-validation-2	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-crds-validation-2
pull-gateway-api-crds-validation-5	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-crds-validation-5
pull-gateway-api-crds-validation-1	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-crds-validation-1
pull-gateway-api-crds-validation-4	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-crds-validation-4
pull-gateway-api-verify	64b4751ea5dddfe9ae70b0b1d4c9995db0d4aea8	link	true	/test pull-gateway-api-verify

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[arkodg]

hey @candita @shaneutt here's a summary of the discussion from today's meeting

I'm referring to the proposal in this PR as Proposal 1 and @kl52752's proposal as Proposal 2

TLDR

Aspect	Proposal 1	Proposal 2
Summary	Adds FrontendValidation at Gateway and Listener levels.	Adds FrontendValidation at Gateway level with an additional optional port field to specify per port configuration.
Security	Implementation should correctly detect listeners with overlapping TLS Config as recommended by GEP-3567 and reject overlapping listeners.	Connection reuse issues are fully addressed.
UX	- Per Listener Configuration is consistent with current Server TLS configuration. - Additional top level Gateway configuration that's common for all listeners. - Also supports Listener-level field overrides, useful in cases where mode is different across listeners but the CA trust bundle is the same.	TLS configuration might be confusing to customers because it is detached from the Listeners. However, for HTTPS, TLS configuration is tied to the connection, and the connection can extend beyond the Listener's boundaries which is reflected with the proposal.
Impact on other listeners	Validating new listeners against existing ones to reject listeners with overlapping TLS config could disrupt the current system for customers if changes are not tested in a pre-prod environment.	Adding new listeners will not break existing setup. Changes in the TLS configuration might break current listeners.
Hostname configuration	Permits configuration per hostname which some implementations support (highlighted in the Prior Art section).	Does not allow per hostname validation.

cc @robscott @youngnick

[robscott]

Thanks to @arkodg and @kl52752 for the great summary of the options we have here!

IMO, this is one of the highest risk areas of Gateway API. If we're not very careful, implementations will expose vulnerabilities when trying to implement this part of the API. With that in mind, my strong preference is for "Proposal 2" as described above.

Essentially, the only way to safely implement proposal 1 is to require implementations to inspect each cert, keep track of the SANs, and ensure that client cert validation is always consistent across listeners that have certs with overlapping SANs.

I'd strongly prefer avoiding requiring implementations to inspect individual certs like this, and I'm very nervous about the wide number of ways an implementation could get proposal 1 wrong and lead to some painful CVEs.

Although proposal 2 offers a less powerful API, it is far safer, and does not prevent us from adding further granularity in the future if needed. So my vote here would be strongly in favor of proposal 2.

Open to what others think here.

/cc @howardjohn @mlavacca @mikemorris @shaneutt

[youngnick]

I also vote for proposal 2 here, and am happy to LGTM something that adds that (I suspect this will all happen overnight while I am asleep).

[arkodg]

closng in favor of https://github.com/kubernetes-sigs/gateway-api/pull/3942 which updated the GEP with proposal 2