ingress with wildcard and ssl-passthrough take always precedence over https subdomain about kubernetes-ingress HOT 6 OPEN

Hi @ynuyasha , I'm looking at it and will get back to you with some news. Thanks for reporting.

from kubernetes-ingress.

Can you indicate what you get in your /etc/haproxy/maps/path-prefix.map file with regards to these two ingress paths ? I'd also like to get the version number of the controller and if relevant of HAProxy (if modified).

from kubernetes-ingress.

------------------host.map---------------------------------
.domain.tld                  .domain.tld
argocd.domain.tld                     argocd.domain.tld
-----------------path-prefix.map------------------------------------------------------------
.domain.tld/                  development_domain_https.dbe4b28f9c4404fc36a7ae76ead9a37d
argocd.domain.tld/                    argocd_argocd-server_http.dbe4b28f9c4404fc36a7ae76ead9a37d
----------------sni.map---------------------------------------------------------------------
.domain.tld                      development_domain_https.dbe4b28f9c4404fc36a7ae76ead9a37d
--------------------------------------------------------------------------------------------

Image: haproxytech/kubernetes-ingress:1.10.4
Image ID: docker.io/haproxytech/kubernetes-ingress@sha256:a378e3999ae728422425947e98ba3cbf72fc076fcb79462d98902921d298d20f

from kubernetes-ingress.

Hi @ynuyasha , can you paste the output of a verbose curl to the wrong redirection ? Can you also check the log output for the request ?

from kubernetes-ingress.

Hey @ivanmatmati unfortunately i don't have anymore this configuration online because i have switched from sni to http to go forward with the project, so i can't give you the curl but i have the haproxy logs with the wrong redirect:

172.30.106.217:57848 [16/Jan/2024:17:57:51.308] ssl development_domain_https/SRV_1 78/0/311 6130 -- 4/3/1/1/0 0/0 SNI: argocd.domain.tld

Anyway Daniel Epperson has also all hints about this issue

from kubernetes-ingress.

Ingress Controller does this "fallback" behavior already if an incoming SNI is not matched on the ssl-passthrough listener (frontend ssl). The problem you were facing is that the your Ingress object with ssl-passthrough enabled was *.domain.tld so it always matched before any subdomains could be evaluated by the later frontend https.

To work around the issue you would need to not use the wildcard *.domain.tld in the ssl-passthrough Ingress object and instead specify each domain which need to use passthrough.

I think what you need is a "fallback" service with ssl-passthrough after all other options have been evaluated. For example a.domain.tld goes to svc a and b.domain.tld goes to svc b (both with SSL termination at IC) but anything else not matched by Ingress objects should fall back to svc sslpass with ssl passthrough enabled. Perhaps if "frontend ssl" was evaluated after "frontend https" this would do what you're asking?

from kubernetes-ingress.