I’ve just spent a few hours unwinding a problem of my own making - I use a single ingressgateway in the istio-system namespace, and then I publish virtualservices in each namespace (dev, prod, test, etc), to direct traffic to services in these namespaces.
I created virtualservices in two namespaces, using the identical hostname. Since both are bound to my gateway, I ended up with traffic ingressing the gateway for the hostname randomly (or was it random?) hitting each service.
Other than being rather confusing, it occurs to me that this behaviour would be a handy way to “intercept” production traffic, simply by deploying a virtualservice with the hostname “prod-auth-server.example.com” into a test/dev namespace.
What’s the recommended way to avoid this vulnerability/misconfiguration?
We have written a validating webhook to prevent situations that would clearly overlap. But there still some amount of risk as any new VirtualService could apply a prefix route for example that is more generic. So this validation does a decent enough job of preventing predictable patterns, but can’t safe guard things entirely.
And you would not match a VirtualService deployed in the test or dev namespace with the prod.domain.tld hostname. See the docs linked for more information (starting at “A host is specified as a dnsName with an optional namespace/ prefix.”).
Does that help @funkypenguin? Or perhaps I misunderstood your question.
Thanks @gertvdijk - that’s helpful, but doesn’t help my specific application, since I use dynamic hostnames in the namespaces (in fact, I also use dynamic namespace names), and I wouldn’t want my CI to be altering the IngressGateway resource within istio-system every time!