Discuss domain match vs. wildcard match for listener hostnames

[jpeach]

In #193, we define a "Domain" match type to match a set of hostnames to a single domain name. The semantics of matching the "example.com" domain are the same as matching a TLS wildcard of "*.example.com" (i.e. a single leftmost domain label is wild).

In #193 there was some discussion that "wildcard" terminology was easier to understand. So we could consider changing this:

hostname:
  match: Domain
  name: example.com

to this:

hostname:
  match: Wildcard
  name: *.example.com

[bowei]

Couple things to clarify:

• Does domain match suffix or only a single level (a la TLS SAN)?
• Do people care about the more esoteric wildcard expressions e.g. a*z.example.com. Are there compelling enough users to support this?

I do like the simplicity of Domain to describe and understand.

[jpeach]

Couple things to clarify:

• Does domain match suffix or only a single level (a la TLS SAN)?

A single level.

• Do people care about the more esoteric wildcard expressions e.g. a*z.example.com. Are there compelling enough users to support this?

We could also introduce these sorts of matches with separate Wildcard or Regex match types (might be proxy-dependent implementations).

[hbagdi]

A single level.

James, in our conversation, I think you mentioned this to support subdomains as well. This is certainly a feature that users want.

Do people care about the more esoteric wildcard expressions

I've seen people do this with headers and paths but (I daresay) never with host.

[jpeach]

A single level.

James, in our conversation, I think you mentioned this to support subdomains as well. This is certainly a feature that users want.

If you have more than 1 level of wildcard, how do you select the right server certificate (since that is only allowed to match a single level)?

[hbagdi]

If you have more than 1 level of wildcard, how do you select the right server certificate (since that is only allowed to match a single level)?

I think our minds are on different tracks because of bad naming.
What I meant was (and maybe @bowei too) was that is it possible to do *.subdomain.example.com or not?

[jpeach]

On 9 Jun 2020, at 12:32 pm, Harry ***@***.***> wrote: If you have more than 1 level of wildcard, how do you select the right server certificate (since that is only allowed to match a single level)? I think our minds are on different tracks because of bad naming. What I meant was (and maybe @bowei too) was that is it possible to do *.subdomain.example.com or not?

Yes. This would match “foo.subdomain.example.com” and “bar.subdomain.example.com”, but not “foo.bar.subdomain.example.com”.

[szuecs]

A while ago I implemented a best match certificate function in our Kube-ingress-aws-controller and so I would like to ask how you would resolve multiple cert matches.
Q1)
Assume you have foo.example.org in the request and you have 2 certificates one for foo.example.org and the other with *.example.org.

Q2)
Assume you have foo.example.org in the request and you have 2 certificates one for foo.example.org and the other foo.example.org, but validity is different. For example the first is valid for the next 20d started from 90d-20d and the other for 90d which was just issued.

Do you think these questions would have a defined answer and if so what would be the answers?

My answers would be for
Q1: as Long certificate with foo.example.org is valid serve this, if not fallback to wildcard.

Q2: newest wins, because of certificate rotation

[jpeach]

A while ago I implemented a best match certificate function in our Kube-ingress-aws-controller and so I would like to ask how you would resolve multiple cert matches.
Q1)
Assume you have foo.example.org in the request and you have 2 certificates one for foo.example.org and the other with *.example.org.

The Listener docs specify that these should be matched from most to least specific. foo.example.org is more specific than a wildcard, so it matches first.

https://github.com/kubernetes-sigs/service-apis/blob/master/apis/v1alpha1/gateway_types.go#L74-L80

Q2)
Assume you have foo.example.org in the request and you have 2 certificates one for foo.example.org and the other foo.example.org, but validity is different. For example the first is valid for the next 20d started from 90d-20d and the other for 90d which was just issued.

AFAIK this isn't addressed anywhere in the API, so it's implementation-specific.

[szuecs]

Thanks for the answers!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hbagdi]

Fixed with #416
/close

[k8s-ci-robot]

@hbagdi: Closing this issue.

In response to this:

Fixed with #416
/close

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/test-infra repository.