Please add support for wildcard virtual hosts

[yarivlifchuk]

Hi,

I need multiple virtual host fqdn routed to the same backend service, example:
devxnew-workspaces-ws-8zdgz.istio-wing.dev1.sapwebide.net.sap
devxnew-workspaces-ws-8zdgz-app1.istio-wing.dev1.sapwebide.net.sap
devxnew-workspaces-ws-8zdgz-app2.istio-wing.dev1.sapwebide.net.sap
devxnew-workspaces-ws-8zdgz-app3.istio-wing.dev1.sapwebide.net.sap
devxnew-workspaces-ws-8zdgz-app4.istio-wing.dev1.sapwebide.net.sap
devxnew-workspaces-ws-8zdgz-app5.istio-wing.dev1.webide.net.sap

These virtual host should be replaced with one
devxnew-workspaces-ws-8zdgz*.istio-wing.dev1.webide.net.sap

Describe the solution you'd like
virtual host fqdn support regexp
example: aaa*.dev.one.com

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Contour version:
• Kubernetes version: (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):

[davecheney]

Thank you for your issue. May I ask some follow up questions - Do you need suffix/prefix matching? eg aaa*.domain.com? - Do you need multiple matches? *.*.com ? - Do you need globbing? *.example.com ? - Do you also need tls support for multiple domain names?

…

On 8 Jul 2019, at 00:31, yarivlifchuk ***@***.***> wrote: Hi, I need multiple virtual host fqdn routed to the same backend service, example: devxnew-workspaces-ws-8zdgz.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app1.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app2.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app3.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app4.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app5.istio-wing.dev1.webide.net.sap These virtual host should be replaced with one devxnew-workspaces-ws-8zdgz*.istio-wing.dev1.webide.net.sap Describe the solution you'd like virtual host fqdn support regexp example: aaa*.dev.one.com Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] Environment: Contour version: Kubernetes version: (use kubectl version): Kubernetes installer & version: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[yarivlifchuk]

Sure In-line my comments From: Dave Cheney <[email protected]> Sent: Tuesday, July 9, 2019 12:06 PM To: heptio/contour <[email protected]> Cc: Lifchuk, Yariv <[email protected]>; Author <[email protected]> Subject: Re: [heptio/contour] Virtual host (#1228) Thank you for your issue. May I ask some follow up questions - Do you need suffix/prefix matching? eg aaa*.domain.com? [YL] yes - Do you need multiple matches? *.*.com ? [YL] no - Do you need globbing? *.example.com ? [YL] no - Do you also need tls support for multiple domain names? [YL] yes

On 8 Jul 2019, at 00:31, yarivlifchuk ***@***.******@***.***>> wrote: Hi, I need multiple virtual host fqdn routed to the same backend service, example: devxnew-workspaces-ws-8zdgz.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app1.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app2.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app3.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app4.istio-wing.dev1.sapwebide.net.sap devxnew-workspaces-ws-8zdgz-app5.istio-wing.dev1.webide.net.sap These virtual host should be replaced with one devxnew-workspaces-ws-8zdgz*.istio-wing.dev1.webide.net.sap Describe the solution you'd like virtual host fqdn support regexp example: aaa*.dev.one.com Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] Environment: Contour version: Kubernetes version: (use kubectl version): Kubernetes installer & version: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1228>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AI2H3ZFLAC2VWEBK7ZOYYETP6RII7ANCNFSM4H6V2H3Q>.

[stevesloka]

Thanks for the feedback @yarivlifchuk, I'm working on a design proposal (which I'll have soon) to revamp what Contour allows users to route on and with. This is super helpful to drive that design. I'll post back when I have the design ready.

[chen-anders]

In our case, we'd need support for something like *.example.com .

[bgagnon]

Is there a technical difference between this feature and having multiple HTTProxy/IngressRoutes with different fqdns and a delegation to a common one? Is it for cases where the fqdn values are numerous, or not registerable in the control plane?

[chen-anders]

One example use-case that I'm targeting here (that we currently use nginx-ingress for) is that we have 65,000+ customers that have some <username-derived-subdomain>.example.com as part of how one of our legacy main applications work. It would seem untenable to have to enumerate each one in the HTTProxy rules.

[bgagnon]

Thanks for clearing that up @chen-anders !

[davidhole]

@bgagnon We have the same use-case as @chen-anders... Thousands of subdomains which are served that way for vanity URL purposes... business-name.ourdomain.com

Currently using nginx-ingress to handle this, but wanting to move to contour for many many reasons...

This would be a fantastic addition. Thanks for your time and efforts!

[jpeach]

xref #2138

[mspinassi]

+1

[xaleeks]

This is pretty important, but always leaves some room for a potential disaster. We should put some thought into design here, although it feels fairly basic.

[youngnick]

The service-apis defines a "wildcard" hostname as one that contains a * for the whole first label of the hostname. (This is "globbing" in Dave's questions above.) Implementing only that would be much easier than a more complex scheme, and would get us a fair chunk of this functionality.

We have #2138 which covers implementing this for Ingress V1 - the service-apis wildcard match is the same. I'd suggest that we implement #2138, and then follow up here and see how many people's needs that can fill.

[xaleeks]

sounds good, we'll leave it out of v1.13

Thought of something else which is what if I wanted a regex to cover a large number of domains except for a particular one that should go to a different service. Would we need to introduce some notion of priority when there are multiple matches. Or are we implementing full blown regex, like support negative look ahead etc

[youngnick]

We could conceivably implement full regex for fqdn, but that's difficult verging on impossible to reconcile with SNI matching based on hostname. In order to ensure that things match on hostname properly, we need to order the hostnames in most-specific to least-specific order, and with full regex support, that order is not really defined.

In short, globbing a whole DNS label is achievable, after that, the more clever we get, the harder it is to make it work as you would expect. ( A DNS label is any part of a hostname between periods.)

You can use the basic globbing support to do a large number of domains with exceptions, but the exceptions will need to be precise matches (that is, have no wildcards in them). This is again because when you go smaller than a single label, it's difficult to order the rules from most- to least-specific.

Effectively, the most-specific to least-specific ordering is priority for matches, and we avoid needing to have some out-of-band priority by mandating globbing only at the DNS label level.

[sunjayBhatia]

sounds good, we'll leave it out of v1.13

Thought of something else which is what if I wanted a regex to cover a large number of domains except for a particular one that should go to a different service. Would we need to introduce some notion of priority when there are multiple matches. Or are we implementing full blown regex, like support negative look ahead etc

I was going to say, should I pick this up, but then again seeing this comment and the others, maybe not

Should it be pulled out of the prioritized backlog and pull in #2138 instead? Ah I see the 1.13 board is the one to pull from, disregard this

[kevinlmadison]

Hey guys, wondering what the status on this is? This would be an amazingly helpful addition.

[sunjayBhatia]

We are adding support for wildcard hosts as part of Ingress v1 support: #3381

Gateway API objects will also support wildcard hosts as per the spec: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.Listener (and other resources)

[amdonov]

While it's great to have wildcard support on ingress and gateway resources, it would still be helpful to have on HTTPProxy. Please correct me if I'm wrong. I can't figure out how to do TLS passthrough with ingress. Gateway isn't ideal for us because it is so new and forces use of the operator. We're using some options with the helm chart such as node selectors, tolerations, and hostNetwork that the operator doesn't support. In addition, the specification doesn't seem to support/address proxy-protocol. We'd love to continue with our current deployment approach and use HTTPProxy for passthrough and proxy-protocol support where needed, but we really need glob matching. Nothing fancy just what's required for gateway.

[youngnick]

Thanks @amdonov. So you just want to be able to do the same first-label-only wildcard match that we do for Gateway? We may be able to port that functionality to HTTPProxy if that's all that's required (since we've already figured out how to do it for Gateway).

[artificial-aidan]

+1 on this. We require HTTPProxy for client cert authentication, but also use wildcard domain matching.

[youngnick]

Thanks for that @artificial-aidan. Would the same first-label-only wildcard match work for you?

[artificial-aidan]

I believe it would. As long as first-label-only works with multiple trailing domains, i.e. *.sub.example.com

[youngnick]

Awesome. Yes, first-label-only just means that only the first label, up to the period, can be replaced.

So *.sub.example.com would match foo.sub.example.com and bar.sub.example.com, but not foo.bar.sub.example.com.

[artificial-aidan]

Awesome. I'll stay subscribed to this.

[youngnick]

Okay, so the TODO for this issue is this;

• take the first-label wildcard semantics that we have for Ingress and Gateway API, and apply it to HTTPProxy's spec.virtualhost.fqdn field.
• The rules about root HTTPProxy objects should be largely unchanged, since *.bar.com and foo.bar.com are separate hostnames, and so can have separate HTTPProxy root objects.

This issue is ready to be picked up.

[xaleeks]

Do we have capacity to pick this up in 1.20. Or shall we move it to 1.21

[artificial-aidan]

What is the size of it? Are the HTTPProxy and Gateway API objects similar? If its mostly copy paste I may have some bandwidth to contribute.

[xaleeks]

Thanks for wanting to contribute to this. Maybe @sunjayBhatia can give some guidance

[sunjayBhatia]

should be a somewhat straightforward change, the main thing is adding the appropriate unit and end-to-end tests

[youngnick]

Yes, I think a fair bit will be copy-and-paste or reusing helpers from Ingress/Gateway API code. And I agree that the main thing is adding the tests, some of the tests for the DAG in particular are way too big (it's on the list).

If you would like to take this one @artificial-aidan, please feel free, and hit up the Slack channel if you need help with shepherding.

[stevesloka]

@artificial-aidan were you still interested in picking this up? If not I can take it. =)

[artificial-aidan]

Been pretty busy lately. Go for it. If I get some free time I'll reach out to see if you need help in anyway.