Skip to content

Multiple CustomDomainMappings referencing wildcard cert generates multiple gateways for the same host port combination #1421

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

Open
mhowell24 opened this issue Apr 2, 2025 · 2 comments

Comments

@mhowell24
Copy link

HI guys,

I hit an issue the other day when trying to setup up two knative-services in two different namespaces with domainMapping for two different subdomains of the same domain where the domainMapping references a wildcarded cert for that domain. This resulted in one service working with the custom domain however the second does not. Note that while the domain being mapped was not a wildcard the cert being used was.

I could be wrong or misunderstanding how knative/net-istio works since I'm relatively new to knative-serving but I think this is because net-istio generates multiple wildcarded TLS gateways both referecing the *.foo.com domain on port 443. The first gateway to be created gets applied to the ingress-gateway and works. However the second does not get applied and is not visable as a listener in the ingress-gateway config, because the host port pair is already being used for the previously created wildcarded gateway. This breaks traffic for the second service, because the knative-serving virtualServices routes reference the gateway the traffic has to pass through as part of the route's matching criteria and that means there is no way of routing any traffic the second service on the custom domain, sinces it matches the first gateways wildcarded listener but then there is no route because there are no virtualServices with routes for that host bound to the gateway for the first service.

Looking through the code it looks like multiple wildcarded gateways get created intentionally. When reconciling the knative-ingress the referenced secrets get catigorised based on if they contain a wildcarded cert or not and if is wildcarded then a wildcard gateway gets created. I think the problem here lies with the fact that even if the ingress has a fully specified name e.g. bar.foo.com the generated gateway created use the decoded infro from the cert and creates a wildcarded gateway.

Is there a reason to not always use the host from the knative-ingress regardless of what is in the cert info? If the host was not wildcarded (link my instance above) I think this would have generated a working configuration with a gateway for each fully qualified domain served using the wildcarded cert.

@mhowell24
Copy link
Author

I would be happy to submit a PR for the above if you are happy with the proposed solution of always using the kingress host?

@dprotaso
Copy link
Contributor

Do you have an example yaml of your setup?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants