-
Notifications
You must be signed in to change notification settings - Fork 689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ingress V1: hostname wildcard support #2138
Comments
Using ingress conformance tests as integration tests, however we have a general issue with the conformance tests: In #1697 and #1714 we stopped accepting I made a PR to change the secrets generated by the tests to a TLS certificate (kubernetes-sigs/ingress-controller-conformance#88) but should we reconsider allowing |
Also it seems this test: https://github.com/kubernetes-sigs/ingress-controller-conformance/blob/79bd068cbb31d77c2a060f61eea795f9791a3d48/features/host_rules.feature#L78-L82 is failing when wildcards are enabled (all other wildcard tests pass) (The test sets up a wildcard
Envoy might be doing too aggressive of matching, not the per-label wildcard matching we want |
So, envoy may match more than one label as part of the |
Yeah, from looking at Envoy code it looks like wildcard matching on virtualhost domain is a simple prefix ( We can do what we want to do using a regex match on the |
See #3180 |
Ive got the plain HTTP stuff working for this (worth making its own PR?) Now for Ingresses with TLS enabled there are a few cases:
|
I think that allowing this usecase at all will make the SNI binding much more difficult. I am not convinced it's worth all the extra effort, feels like YAGNI. Thanks for the deep thought on this @sunjayBhatia! |
Having some trouble with the wildcard filter chain and SNI/ With no code changes to the Lua filter we add to HTTPS filter chains, requests that match a wildcard host are all rejected with code 421 since nothing will literally equal the wildcard hostname. Obviously we can get around this, but a further issue is that I can't seem to get the requested server name from TLS/SNI in the Lua code. It's a little funny, I think I should be able to get it since the access logger has access to this in the Mostly for my own notes around test cases: With a wildcard host and cert for
|
Couple of points that may be relevant
|
Yes, I think that @jpeach's first point is a great one - the important thing we are aiming for here is that you can't specify a client cert in the TLS config, then swing between virtualhosts. I think it's fair to make the argument that if you are specifying a client cert, it's specified at the virtualhost level, so any routes under that will require the client cert. In that case, your last concern doesn't matter, since any two hostnames that match the FQDN have the same security posture. |
So with this Ingress:
Couldn’t we get misrouted requests, following the logic in envoyproxy/envoy#6767 (comment) (assuming a request first to foo.foo.com then another from the same browser to bar.foo.com) |
🤦 I was thinking about this as a HTTPProxy thing, d'oh. I see what you are talking about now. I will need to think about this a bit. |
That was the use case I was thinking about in my last comment in #1228. Whatever approach we go with for using wildcard TLS certs, can we make sure it works the same way for HTTProxy as it does for Ingress? and in the future for httproutes. |
I think it is a lot simpler with HTTPProxy since there is only one virtual host configuration (FQDN + TLS config) at the root of a tree of HTTPProxies (here) and included "child" HTTPProxies cannot have virtual host configuration. Unlike In general, Gateway APIs seems simpler as well since we don't have to match the hostname a secret is meant for to the hostname a listener/route is meant for. There is also a specific mechanism for a Gateway to say that TLS settings can be configured via Routes or not. |
- Wildcard virtualhosts now allowed - Envoy's virtualhost matching does not match on a single DNS label like we want to implement - For wildcard host routes, we add a header match rule to match on the ":authority" header that is more strict and will only match one DNS label wildcard - Adds an integration test to validate behavior with a wildcard certificate - Passes ingress conformance tests for wildcards - Adds the "regex" header match strategy (only internal for now) - Ensure regex header matches are sorted correctly (after exact, before contains matches) Fixes #2138 Updates #2139 Signed-off-by: Sunjay Bhatia <[email protected]>
Support Ingress V1 hostname wildcards
https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20190125-ingress-api-group.md#hostname-wildcards
This may have knock-on effects on HTTPS, as a wildcard hostname probably needs a wildcard TLS certificate. Alternatively, you could support routing several non-wildcard TLS certificates to a single wildcard hostname.
The text was updated successfully, but these errors were encountered: