feat(translator): add support for different hostnames for the listener and an attached TLS certificate

[jacobneiltaylor]

What type of PR is this?
Feature enhancement

What this PR does / why we need it:
This PR adds the ability to specify an alternative hostname for validation against provided TLS certificates.
This allows Envoy Gateway to support alternative validation schemes supported by CDNs.

More information on this use case is expressed in the corresponding issue.

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

Release Notes: Yes

[arkodg]

hey @jacobneiltaylor thanks for proactively working on this

@guydc was also looking at implementing a fix for this issue, and what we had aligned on was loosing

gateway/internal/gatewayapi/tls.go

Line 109 in ddf1009

func validateCertificate(data []byte) error {

and

gateway/internal/gatewayapi/tls.go

Line 90 in ddf1009

func verifyHostname(cert *x509.Certificate, host *gwapiv1.Hostname) ([]string, error) {

by default, and representing those inconsistencies using a new Status Condition that doesnt block programming the Listener

tldr - there are many cases in prod when there may be multiple certRefs and 1 invalid one (thats expired) should not block other certs from being configured

[jacobneiltaylor]

@arkodg thanks for the context!

I did go through that thread prior to opening this PR, and I think the hostname issue and the expiry issue are subtly different.

there are many cases in prod when there may be multiple certRefs and 1 invalid one (thats expired) should not block other certs from being configured

My reading of that thread (and your TLDR) is that if I have 5 certRefs and 2 are "invalid" then only 3 certificates will be programmed into the listener. In short, you will not program any certificate deemed to be invalid.

I (and, I believe, @yaelSchechter) want to be able to add a certRef to a listener that is currently considered "invalid" (specifically, in our case we want bind a cert that doesn't match the hostname value of the relevant Gateway listener) and have it be programmed anyway. Does the proposed solution above cover this case as well?

In my PR, I went the route of being able to configure the validation logic of the translator as I consider this the least obtrusive method - someone has to go out of their way to specifically use this behaviour rather than changing the default behaviour of Envoy Gateway.

[arkodg]

sure the approach sgtm, but we cannot support the configuration via an annotation, it would need to be a strongly typed field like skipSANValidation in the API,

gateway/api/v1alpha1/clienttrafficpolicy_types.go

Line 77 in c653290

TLS *ClientTLSSettings `json:"tls,omitempty"`

seems like the right home

[jacobneiltaylor]

I'll look into that alternative implementation path.

As a matter of policy, is Envoy Gateway avoiding the use of GatewayTLSConfig.options (link) and other weakly typed extension structs in the base Gateway API spec?

[guydc]

As a matter of policy, is Envoy Gateway avoiding the use of GatewayTLSConfig.options (link) and other weakly typed extension structs in the base Gateway API spec?

So far, we did not use it, seeing as it's not strongly typed. Same goes for annotations.

I'm +1 to Arko's suggestion.

[arkodg]

reg home for this new field, a better home would be in EnvoyProxy

gateway/api/v1alpha1/envoyproxy_types.go

Line 137 in c653290

// BackendTLS is the TLS configuration for the Envoy proxy to use when connecting to backends.

under frontendTLS / serverTLS since ClientTrafficPolicy holds client specific settings

[jacobneiltaylor]

I've implemented the feature as you suggested, I went with Hostname rather than SAN to maintain consistency with the nomenclature in Gateway API.

[codecov]

Codecov Report

❌ Patch coverage is 91.17647% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.03%. Comparing base (af990e7) to head (58ca98a).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/gatewayapi/validate.go	84.21%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6582      +/-   ##
==========================================
+ Coverage   70.86%   71.03%   +0.17%     
==========================================
  Files         224      225       +1     
  Lines       38769    39179     +410     
==========================================
+ Hits        27472    27832     +360     
- Misses       9708     9737      +29     
- Partials     1589     1610      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.