1
votes

So in this scenario, I want to be able to rewrite the Host header when a request comes in so that it routes to a VirtualService listening on the host that I've rewritten. I have an Envoy Filter with the following code in it.

serviceName = headers:get("x-service-name")
headers:add("X-Forwarded-Host", headers:get(":authority"))
headers:replace("host", serviceName .. ".company.local")
headers:replace(":authority", serviceName.. ".company.local")

And a VirtualService that has a setup similar to the following

gateways:
- my-gateway
hosts:
- my-service.company.local
http:
....

However, if I try to make a call to the service with something along the lines of the following, I get a 404 response from Istio.

curl -H "X-Service-Name: my-service" http://ingress.company.com

The host I'm trying to route to (my-service.company.local) doesn't actually exist, and DNS resolution wouldn't provide anything, I was sort of just hoping that Istio would see the host in the VS and direct traffic that way, is that not the case?

If DNS does need to resolve, would I be able to use a ServiceEntry with a host that forwards traffic to the right Kubernetes service or something, so that I don't need to create a real DNS entry?

1
To which pod are you applying the Envoy filter to? If it is a pod that the Virtual Service is pointing to, then it is too late as request probably does not reach the proxy in that pod. You might want to try applying the filter to the Ingressgateway pod but I do not know how it will behave.Szymig
Did you ever figure out how to do this? I have some lua which is doing a similar thing; from what I can tell it's not changing the cluster in envoy which might be the problem.Naphta

1 Answers

0
votes

I was going through the same problem here and trying to rewrite the :authority header wouldn't trigger the new route. But I realized that you can add header base routes to the Envoy routing rules and have your plugin just add those headers. There is no need to mess up with Envoy's internal headers.