Adding GEP 2907: TLS Configuration Placement and Terminology

[robscott]

What type of PR is this?
/kind gep

What this PR does / why we need it:
This adds a new memorandum GEP that attempts to chart a vision for where our TLS configuration will live and what it will be called.

Which issue(s) this PR fixes:
Fixes #2907

Does this PR introduce a user-facing change?:

NONE

/cc @arkodg @candita @youngnick

[robscott]

Deploy Preview: https://deploy-preview-2910--kubernetes-sigs-gateway-api.netlify.app/geps/gep-2907/

[arkodg]

+1 to Gateway.BackendTLS.ClientCertificateRef

[youngnick]

LGTM with one sadly blocking comment about explaining the naming things better.

[candita]

Remembering the discussions around why the content of BackendTLSPolicy wasn't going to be added directly to Gateway, one reason was because BackendTLS should be accessible to the app developer role, and the burden of app or service-level certificate management shouldn't be placed on the cluster operator. How do we reconcile those discussions with this proposal? Add a new role, like application operator or similar?

If we kept both BackendTLSPolicy and Gateway.BackendTLS, then we'd need to define how and when one could override the other.

How about considering a new policy attachment called FrontendTLSPolicy, which would be available to cluster operators, but maybe not app developers. It would be similar to BackendTLSPolicy in many ways, but perhaps targetRefs could be listeners on the gateway? Would it work for @arkodg's use cases ?

[candita]

I see some proposed changes, so this is not really a non-goal.

[robscott]

I guess what I'm trying to say here is that if we translate this into actual API changes, those will be tracked by the GEPs associated with those APIs. This GEP is a memorandum GEP and not meant to track or own any individual API changes, will try to clean this up.

[arkodg]

Looks good, thanks for adding this GEP

[youngnick]

/lgtm

subject to @candita and @Miciah being satisfied with language updates. This is a 1.1 release blocker, since it blocks moving forward with GEP-91, which is also a release blocker for 1.1.

[dprotaso]

Can we settle what to do hostnames/sans?

eg. in the client validation GEP we have

  // SubjectAltNames contains one or more alternate names to verify
  // the subject identity in the certificate presented by the client.
  //
  // Support: Core
  //
  // +optional
  // +kubebuilder:validation:MinItems=1
  SubjectAltNames []string `json:"subjectAltNames,omitempty"`

but in BackendTLSPolicy we have

// Hostname is used for two purposes in the connection between Gateways and
// backends:
//
// 1. Hostname MUST be used as the SNI to connect to the backend (RFC 6066).
// 2. Hostname MUST be used for authentication and MUST match the certificate
//    served by the matching backend.
//
// Support: Core
Hostname v1beta1.PreciseHostname `json:"hostname"`

It'd be great to one name these things the same and potentially settle on supporting alternate names in both frontend and backend use cases.

[dprotaso]

cc @arkodg

[robscott]

For now I believe @arkodg has removed SANs from the client validation GEP. I think we definitely need to consider both if/when there's overlap again, I'm particularly interested in adding SANs to BackendTLSPolicy for example, but I think both are out of scope for v1.1 so we can follow up when they're proposed in the future.

[robscott]

Thanks everyone for the feedback! I think I've addressed everything now, so PTAL. I'm going to remove the hold so the next LGTM merges this. I think we've got pretty good consensus around this GEP at this point and I really want to unblock @arkodg's GEP that depends on this one.

/hold cancel

[candita]

Sorry, I feel like we are rushing this.

/hold

[candita]

I'd like to summarize the proposed segments, only because when I look at them together they don't seem as unified as they could be:

Gateway.Listener.TLS.FrontendValidation
Gateway.Listener.TLS
Gateway.Spec.BackendTLS.ClientCertificateRef
Gateway.Spec.BackendTLS.Validation

To me the problem of dealing with the constraint of Listener is better solved by doing something like this:

Gateway.Listener.TLS.FrontendValidation
Gateway.Listener.TLS
Gateway.Transmitter.TLS.BackendValidation
Gateway.Transmitter.TLS

or even

Gateway.Listener.TLS.Validation
Gateway.Listener.TLS
Gateway.Transmitter.TLS.Validation
Gateway.Transmitter.TLS

We don't have to use the term Transmitter, just something other than BackendTLS, which clashes with BackendTLSPolicy. I feel a move toward this pattern presents an easier learning curve for people with memory challenges (like me).

[robscott]

Good questions, I've added two separate but related sections to address this:

• Why the inconsistency between Frontend and Backend TLS config on Gateways?
• Why Not Listener level to match FrontendValidation?

I've also added a note that we should reconsider these answers before developing any kind of backend TLS config at a Gateway level. Hope that all works for you.

[candita]

/cancel hold

[robscott]

Thanks for all the great feedback @candita, I think I've addressed everything now. Would appreciate an additional round of review and/or LGTM from anyone that has time so we can get this one in and unblock the dependent updates.

/hold cancel

[arkodg]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arkodg, robscott

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]

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