GEP-851: Allow Multiple Certificate Refs per Gateway Listener

  • Issue: #851
  • Status: Standard

TLDR

Replace CertificateRef field with a CertificateRefs field in Gateway Listeners.

Goals

Provide a path for implementations to support:

  • RSA and ECDSA certs on the same Listener.
  • Referencing certificates for different hostnames from the same Listener (maybe as part of a self-service TLS approach).
  • Including new and old certificates as part of renewal process.
  • Certificate pinning: enable implementations that require certain certificates for legacy clients while exposing a “normal” certificate to non-legacy clients.

Non-Goals

  • Define how implementations should support these features. Many implementations have limited control as far as how certs are handled. Some implementations just pass certs directly to the dataplane and rely on that implementation specific behavior to determine which certs are used for a given request. That makes it difficult to define any truly portable handling of multiple certificates.

Introduction

As described above, there are a number of potential use cases for attaching multiple certificates to a Gateway Listener. The most straightforward reason for that involves attaching RSA and ECDSA certs. Although this is not a very common use case, it is a clearly understood and broadly supported example of why this change would be helpful. This change will enable implementations to support these more advanced use cases while still providing a portable core.

API

The CertificateRef field in GatewayTLSConfig would be replaced with the following CertificateRefs field:

  1.     // CertificateRefs contains a series of references to Kubernetes objects that
  2.     // contains TLS certificates and private keys. These certificates are used to
  3.     // establish a TLS handshake for requests that match the hostname of the
  4.     // associated listener.
  5.     //
  6.     // A single CertificateRef to a Kubernetes Secret has "Core" support.
  7.     // Implementations MAY choose to support attaching multiple certificates to
  8.     // a Listener, but this behavior is implementation-specific.
  9.     //
  10.     // References to a resource in different namespace are invalid UNLESS there
  11.     // is a ReferenceGrant in the target namespace that allows the certificate
  12.     // to be attached. If a ReferenceGrant does not allow this reference, the
  13.     // "ResolvedRefs" condition MUST be set to False for this listener with the
  14.     // "InvalidCertificateRef" reason.
  15.     //
  16.     // This field is required to have at least one element when the mode is set
  17.     // to "Terminate" (default) and is optional otherwise.
  18.     //
  19.     // CertificateRefs can reference to standard Kubernetes resources, i.e.
  20.     // Secret, or implementation-specific custom resources.
  21.     //
  22.     // Support: Core - A single reference to a Kubernetes Secret
  23.     //
  24.     // Support: Implementation-specific (More than one reference or other resource types)
  25.     //
  26.     // +optional
  27.     // +kubebuilder:validation:MaxItems=64
  28.     CertificateRefs []*SecretObjectReference `json:"certificateRefs,omitempty"`

Alternatives

N/A