Move BackendTLS configuration to GatewayTLSConfig

[kl52752]

What type of PR is this?

/kind gep
What this PR does / why we need it:
Merge Gateway TLS configuration for frontend and backend validation into top level GatewayTLSConfig.
Which issue(s) this PR fixes:

Related to: GEP-3155
Related to: #3979

Does this PR introduce a user-facing change?:

NONE

[kl52752]

/assign @robscott @youngnick @shaneutt
/cc @snorwin @candita

[snorwin]

I’m not sure if BackendValidation is the best name for this field, since validation is actually part of the BackendTLSPolicy.

A structure like the following might be clearer:

tls:
  frontend:
    validation: {}
  backend:
    clientCertificateRef: {}

Alternatively, we could use the terms origination (for backend) and termination (for frontend), which are common in TLS contexts.

[kl52752]

yeah it makes sense. I updated PR PTAL.
I will update index.md and CRDs fields once we agree on final form.

[snorwin]

Thanks! I would also love to hear some other opinions on this.

\cc @shaneutt, @robscott, @youngnick

[candita]

We have a GEP that establishes some naming guidelines here: https://gateway-api.sigs.k8s.io/geps/gep-2907. I think an update to that GEP is the first thing to do here.

[youngnick]

I'm not sure what you mean - @snorwin suggested the change above, which @kl52752 implemented, which uses frontend and backend. Is that not in line with what we have in GEP-2907?

In another comment thread here, I suggested termination and origination, but @robscott also reminded me about GEP2907 and the agreed names there, and I agreed that it's better to stick with them.

[robscott]

This is great, thanks @kl52752!

[kl52752]

Thanks @robscott for the review. I updated API with your suggestion. I will update index.md files and examples once we have all review.
@youngnick @shaneutt PTAL

[robscott]

Thanks @kl52752! This helps make our top level Gateway configuration far more consistent.

[kl52752]

@shaneutt I would like to request the extension for this GEP and include it in v1.4.0 release in experimental channel. We need to reach out agreement for naming convention and I think that we are very close and need 24h to finalize this.

[kl52752]

/retest

[shaneutt]

@shaneutt I would like to request the extension for this GEP and include it in v1.4.0 release in experimental channel. We need to reach out agreement for naming convention and I think that we are very close and need 24h to finalize this.

Granted via the parent here for all things under the parent.

[shaneutt]

As per our conversation about this on the community call today:

This is not about changing behavior, but about changing wording and API spec prior to lock-in which would make it harder. There was a lot of support on the call that we should move forward. Since this seems like an overall improvement:

/lgtm

However it was also mentioned that the GEP and documentation is unclear about some of the details. @kl52752 are you open to providing more context in the GEP as per our discussion today, as part of the 1 week extension we're doing here?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kl52752, robscott, shaneutt, snorwin

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott,shaneutt]

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

[kl52752]

Related to: #3979

I created a PR with updates to GEP-2907. Should I updated also https://gateway-api.sigs.k8s.io/guides/tls/?

[shaneutt]

Related to: #3979

I created a PR with updates to GEP-2907. Should I updated also https://gateway-api.sigs.k8s.io/guides/tls/?

On our call yesterday, we pointed out that it's common that experimental stuff lags in documentation, so we don't want to hold you to some standard we've not held for others. At your option, if you feel inclined and can spare the time, that would be great, however it doesn't preclude the notion of us merging this.

[robscott]

Thanks @kl52752! It looks like everything's been resolved here and we have multiple approvals now, removing the hold and we can cover docs + GEP update in the follow up PRs.

/hold cancel