conformance: add TLSRoute hostname intersection conformance tests by rostislavbobo · Pull Request #4437 · kubernetes-sigs/gateway-api

rostislavbobo · 2026-01-19T14:16:42Z

What type of PR is this?

/kind test
/area conformance-test

What this PR does / why we need it:

This PR adds a conformance test for Gateway and TLSRoute hostnames intersection using wildcards (GEP-2643).

Gateway #	Listener Hostname	Attached TLSRoute Hostname
1	`abc.example.com`	`*.example.com`
2	`*.example.com`	`abc.example.com`
		`*.com`
3	`*.com`	`abc.example.com`
		`*.example.com`
4	(Enpty)	`abc.example.com`
		`*.com`

Note: TLSRoute rejection based on hostname mismatch is covered by #4433

Which issue(s) this PR fixes:

Fixes #

Part of #1579

Does this PR introduce a user-facing change?:

NONE

k8s-ci-robot · 2026-01-19T14:16:45Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

rostislavbobo · 2026-01-19T14:40:02Z

/cc @rikatz @Thealisyed

k8s-ci-robot · 2026-01-19T14:40:06Z

@rostislavbobo: GitHub didn't allow me to request PR reviews from the following users: Thealisyed.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

Details

In response to this:

/cc @rikatz @Thealisyed

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.

rikatz · 2026-01-20T13:18:37Z

/assign

rikatz · 2026-01-20T13:23:22Z

conformance/tests/tlsroute-hostname-intersection.yaml

+apiVersion: gateway.networking.k8s.io/v1
+kind: Gateway
+metadata:
+  name: gateway-exact-hostname


given this is a tlsroute test, can we have the name of the gateway containing it to differentiate from other tests?

also question: what would be the impact of having all listeners on the same gateway, and attaching to the listener using sectionName?

given this is a tlsroute test, can we have the name of the gateway containing it to differentiate from other tests?

Added "-tlsroute and "-intersection" to the Gateway names.

what would be the impact of having all listeners on the same gateway, and attaching to the listener using sectionName?

This is possible, but it requires adding more TLS-terminating backends to be able to trace the request till it hits a distinct backend. Currently, the "gateway-conformance-infra" namespace has only one "tls_backend" Service and Deployment (see source).

We need to decide between
a) Multiple Gateways – create more Gateways in conformance/tests/*.yaml that use the single "tls_backend", or
b) Multiple Backends – add more "tls_backend_{N}" Services and Deployments to conformance/base/manifests.yaml and use a single Gateway with multiple listeners in conformance/tests/*.yaml

ok I see your point, yes. We won't be able to assert which listener was used.

I think we can consider multiple backends as some part of the evolution, but looks good to me for now. I will approve and let the lgtm for someone else

rikatz · 2026-01-20T13:28:58Z

@rostislavbobo two asks/questions, otherwise lgtm!

Thealisyed

lgtm :)

rikatz · 2026-01-21T19:38:55Z

/approve
/retest
thanks @rostislavbobo

I will check with someone else for a 2nd pass

k8s-ci-robot · 2026-01-21T19:39:04Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rikatz, rostislavbobo

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~conformance/OWNERS~~ [rikatz]

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

rikatz · 2026-01-21T19:39:22Z

/cc @snorwin @kl52752 @kflynn

rikatz · 2026-01-28T15:53:53Z

I have tested with envoy gateway and cilium and it works fine.
Istio and kgateway are broken because of the size of the gateway name, but IMO this should be fixed on the implementation and not on the test.

/lgtm
/hold
@kl52752 I think we can fix any of these t.Runs on a followup, but will leave it for you to decide

Thanks!

howardjohn · 2026-01-28T16:13:35Z

Istio and kgateway are broken because of the size of the gateway name, but IMO this should be fixed on the implementation and not on the test.

IMO if we have a test for TLS it should not be testing "too long hostname".

The spec even says to copy the name: https://gateway-api.sigs.k8s.io/geps/gep-1762/?h=cl#automated-deployments

rikatz · 2026-01-28T16:50:43Z

IMO if we have a test for TLS it should not be testing "too long hostname".

It is not, it is testing within the boundaries of 62 characters for the Gateway name (not about hostname). But once Istio copies the labels to the deployment spec, it adds an "istio" suffix and this violates the size.

howardjohn · 2026-01-28T17:03:47Z

IMO if we have a test for TLS it should not be testing "too long hostname".

It is not, it is testing within the boundaries of 62 characters for the Gateway name (not about hostname). But once Istio copies the labels to the deployment spec, it adds an "istio" suffix and this violates the size.

The spec says an implementation should do this. A TLS test does not require 62 character Gateway name. If we want to enforce this for conformance, we should change the spec. We cannot have a conformance test that requires you to violate the spec...

rikatz · 2026-01-28T17:11:22Z

The spec says an implementation should do this. A TLS test does not require 62 character Gateway name. If we want to enforce this for conformance, we should change the spec. We cannot have a conformance test that requires you to violate the spec...

OK, I see your point, the issue here is that we enforce that the generated label is - and this test "enforces" the worst case.

I have missed that.

@rostislavbobo can you reduce the size name for now?

@howardjohn while we do not explicitly define a limit for a Gateway name, I think we may need to make it clear that a user creating a gateway with a big name will cause problems once those names are concatenated. We should probably enforce that in this case a better condition is exposed on Gateway status to let users now that the name is too big (a new conformance, a new specification, etc).

howardjohn · 2026-01-28T17:15:51Z

Yeah I definitely agree some tweaks are needed around how to handle large names - just that we should do that in a dedicated manner instead of tying it to TLSRoute 🙂 . Thanks!

rostislavbobo · 2026-01-28T17:19:23Z

makes sense @howardjohn , will reduce the name sizes, we can address it separately, no need to be part of TLSRoutes

rikatz · 2026-01-28T17:24:10Z

Created the issue #4464 for a followup on gateway name size.

Thanks folks

kl52752 · 2026-01-29T08:35:58Z

/lgtm

rostislavbobo · 2026-01-29T12:37:30Z

non-matching specific hostnames do not intersect

non-matching wildcard hostnames do not intersect (so, *.example.com and *.com, for example).

what happens when both are wildcard hostnames? I don't know if we've specified this.

@youngnick , I've added more test cases to cover, here's a quick summary:

Gateway #	Listener Hostname	Attached TLSRoute Hostname
1	`abc.example.com`	`*.example.com`
2	`*.example.com`	`abc.example.com`
		`*.com`
3	`*.com`	`abc.example.com`
		`*.example.com`
4	(Enpty)	`abc.example.com`
		`*.com`

Here you can see we do support when both are wildcard hostnames (even for *.example.com and *.com).

No matching hostnames are covered by #4433

rikatz · 2026-01-29T12:45:56Z

/retest
This error on ci wasn't happening yesterday, and in theory we do not run retroactive linters...

rikatz · 2026-01-29T13:03:14Z

conformance/tests/tlsroute-hostname-intersection.yaml

+  - name: gw-tlsroute-more-specific-wc-hostname-x-2
+    namespace: gateway-conformance-infra
+  hostnames:
+  - "*.com"


@rostislavbobo I think this should not pass? the spec of gw-tlsroute-more-specific-wc-hostname-x-2 says: hostname: "*.example.com" so should trying to attach a *.com work?

it passes for istio, fails for eg

I have some split feelings. Let me think loud here

the hostname on listener is used for infrastructure configuration and routing. It means "what listener hostname can attach here"

the hostname on route is used for proper routing, like "anything that is *.com should route here" and it may rely on the parentRef for the right routing

I think the test makes sense given the parentRef case, let's see how this goes during implementations running their conformance

Same with HTTPRoutes: A Gateway { hostname: "*.example.com" } <-- HTTPRoute { hostnames: ["*.com"] } is supported by istio and gke-l7-*, but is not supported by eg.

@robscott , @youngnick , the GW spec doesn't clearly state how to handle wildcard-to-wildcard attachments. I can
a) add this test for HTTPRoute, or
b) remove this test from TLSRoute
so that it's consistent across both.

WDYT?

The thing you're missing here @rikatz is that * only means a single label. So *.com will only match example.com, not www.example.com.

I do not recall when we added the stuff about the suffix match, but I do recall us agreeing that * only matched a single label. Let me look at the blame for those files and see if I can find some context, as that's not how I remember things working.

Okay, turns out I am wrong, I guess, sigh, as of #1173, years ago. So yes, @rostislavbobo, you're right here. That is how the wildcard matching works, so it makes sense to test it.

I suspect I've written Cilium's implementation incorrectly and I'll fail this test, but that's on me.

Oh, one thing that is not the same as RFC-2818 is that * only matches on a full label (or multiple full labels). No partial matches, so f*.example.com is not valid and does not match anything. This is recorded on the Hostname type:

gateway-api/apis/v1/shared_types.go

Lines 601 to 610 in 716f2c5

// Hostname is the fully qualified domain name of a network host. This matches

// the RFC 1123 definition of a hostname with 2 notable exceptions:

//

// 1. IPs are not allowed.

// 2. A hostname may be prefixed with a wildcard label (`*.`). The wildcard

// label must appear by itself as the first label.

//

// Hostname can be "precise" which is a domain name without the terminating

// dot of a network host (e.g. "foo.example.com") or "wildcard", which is a

// domain name prefixed with a single wildcard label (e.g. `*.example.com`).

But the "must match a full label or multiple labels" is implied rather than fully specified. I'll make a note to fix this.

yes, * matches full label(s) only. I don't recall any implementation supporting partial domain matches with * (e.g. f*.example.com) for SNI hostname or L7 Host.

I’ll also create a similar test for HTTPRoute (*.example.com and *.com intersection) since we keep that test for TLSRoute, and invite you all to the review.

rikatz · 2026-01-29T13:39:01Z

/lgtm
/hold cancel

…bernetes-sigs#4437) * conformance: add TLSRoute hostname intersection conformance tests * TLSRoute: Indicate tlsroute in Gateway names * TLSRoute: Add test for wildcard hostname intersects with wildcard listener hostname * TLSRoute: Fetch the Secret once and reuse it * TLSRoute: Add more conformance tests to cover more intersection cases * TLSRoute: Make TLS request tests run in parallel

Gateway API uses distinct wildcard hostname match on HTTP and TLS: * Host header and HTTPRoute hostnames matching understand a wildcard as one or more DNS labels, so the wildcard hostname is used as a suffix; * TLS SNI extension and TLSRoute hostnames matching understand a wildcard as a single DNS label, following RFC-2818. Context: https://github.com/kubernetes-sigs/gateway-api/blob/8f9b904306371cbfed9f9d542e9af667de804286/site-src/concepts/hostnames.md?plain=1#L142-L145 kubernetes-sigs/gateway-api#4437 (comment) TLSRoute was not following this configuration, but instead the suffix approach of the HTTPRoute, making one of the conformance tests to fail. This update configures ExtendedWildcard to false, so HAProxy configures the TLS/SNI match using single DNS label instead.

k8s-ci-robot requested review from candita and sunjayBhatia January 19, 2026 14:16

k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 19, 2026

rostislavbobo force-pushed the tlsroute-conformance-hostname-intersection branch from 98f0b01 to 430dfa9 Compare January 19, 2026 14:34

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 19, 2026

conformance: add TLSRoute hostname intersection conformance tests

5410755

rostislavbobo force-pushed the tlsroute-conformance-hostname-intersection branch from 430dfa9 to 5410755 Compare January 19, 2026 14:35

rostislavbobo marked this pull request as ready for review January 19, 2026 14:39

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 19, 2026

k8s-ci-robot requested a review from LiorLieberman January 19, 2026 14:39

k8s-ci-robot requested a review from rikatz January 19, 2026 14:40

k8s-ci-robot assigned rikatz Jan 20, 2026

rikatz reviewed Jan 20, 2026

View reviewed changes

Thealisyed reviewed Jan 20, 2026

View reviewed changes

TLSRoute: Indicate tlsroute in Gateway names

36ffe92

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 21, 2026

k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Jan 28, 2026

k8s-ci-robot assigned kl52752 Jan 29, 2026

rostislavbobo added 2 commits January 29, 2026 12:17

TLSRoute: Add more conformance tests to cover more intersection cases

405f2e3

TLSRoute: Make TLS request tests run in parallel

48da635

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 29, 2026

rikatz reviewed Jan 29, 2026

View reviewed changes

k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. and removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Jan 29, 2026

k8s-ci-robot merged commit a4bd92b into kubernetes-sigs:main Jan 29, 2026
20 checks passed

rikatz mentioned this pull request Jan 29, 2026

STD: TLSRoute (GEP-2643) #4254

Open

This was referenced Feb 5, 2026

TLSRoute: Require hostnames and bump version to v1alpha3 #3872

Merged

fix: computeHosts doesn't work when listener and route both wildcard envoyproxy/gateway#8186

Merged

rikatz mentioned this pull request Feb 24, 2026

Add Hostname concept and explanation document #4516

Merged

jcmoraisjr mentioned this pull request Mar 22, 2026

match sni using single dns label jcmoraisjr/haproxy-ingress#1436

Merged

	// Hostname is the fully qualified domain name of a network host. This matches
	// the RFC 1123 definition of a hostname with 2 notable exceptions:
	//
	// 1. IPs are not allowed.
	// 2. A hostname may be prefixed with a wildcard label (`*.`). The wildcard
	// label must appear by itself as the first label.
	//
	// Hostname can be "precise" which is a domain name without the terminating
	// dot of a network host (e.g. "foo.example.com") or "wildcard", which is a
	// domain name prefixed with a single wildcard label (e.g. `*.example.com`).

Conversation

rostislavbobo commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Jan 19, 2026

Uh oh!

rostislavbobo commented Jan 19, 2026

Uh oh!

k8s-ci-robot commented Jan 19, 2026

Uh oh!

rikatz commented Jan 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rikatz commented Jan 20, 2026

Uh oh!

Thealisyed left a comment

Choose a reason for hiding this comment

Uh oh!

rikatz commented Jan 21, 2026

Uh oh!

k8s-ci-robot commented Jan 21, 2026

Uh oh!

rikatz commented Jan 21, 2026

Uh oh!

rikatz commented Jan 28, 2026

Uh oh!

howardjohn commented Jan 28, 2026

Uh oh!

rikatz commented Jan 28, 2026

Uh oh!

howardjohn commented Jan 28, 2026

Uh oh!

rikatz commented Jan 28, 2026

Uh oh!

howardjohn commented Jan 28, 2026

Uh oh!

rostislavbobo commented Jan 28, 2026

Uh oh!

rikatz commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kl52752 commented Jan 29, 2026

Uh oh!

rostislavbobo commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rikatz commented Jan 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rostislavbobo Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rostislavbobo Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

rostislavbobo commented Jan 19, 2026 •

edited

Loading

rikatz commented Jan 28, 2026 •

edited

Loading

rostislavbobo commented Jan 29, 2026 •

edited

Loading

rostislavbobo Jan 29, 2026 •

edited

Loading

rostislavbobo Jan 29, 2026 •

edited

Loading