I'm looking at enabling Istio across a cluster. Inside the cluster are several services that generate links for clients to follow. Since enabling the istio sidecars the links are being generated incorrectly.
A request will be made to service a at something like http://service-a.foo.svc.cluster.local:7001/x/y/z, but the response from that will be missing the port on any generated links. i.e. http://service-a.foo.svc.cluster.local/x/y/z
It looks like this is because the envoy proxy sidecar is not including an X-Forwarded-Port header, which the service needs to construct a viable link.
Is it possible to configure the sidecars to include that header? Envoy docs suggest some config that is required to add the header, but I don't see how to do that in Istio.
We've had some success with VirtualService resources where the X-Forwarded-Port is manually specified, but we'd have to roll that out to every affected service, and it seems like a workaround rather than a proper fix.
I have made good progress with this. First I should signpost to some links that really helped.
An issue was raised on envoyproxy's github about this exact type of issue. One of the comments talks about fixing this in an Istio deployment using an EnvoyFilter.
I also used this link to debug the headers that were coming through the sidecar. Very useful to see what was going on.
In that comment, the user adds an X-Forwarded-For header specifically for the Spring Actuator endpoints that require it.
I've adapted that answer and applied a filter to the workload in question. I check for the presence of the X-Forwarded-For header, and only add it if one wasn't already specified. In debugging this, I saw many requests coming into the pod with the header set, and envoy happily passes that along - it just doesn't seem to add the header itself.
Here is my filter:
Here is the log output from the Istio proxy, showing a request having the header added using the port that was provided: