Unable to forward XFF to istio proxy

[istio]

Unable to forward XFF to istio proxy

[kyessenov]

Are you saying that sidecar Envoy strips XFF? It seems that sidecar operates in the transparent mode, meaning the header is preserved https://lyft.github.io/envoy/docs/configuration/http_conn_man/headers.html#id9

[rshriram]

Yes definitely! It's a very small addition. Can you edit the issue title accordingly so that we can track this ?

On Thu, Jun 1, 2017 at 1:59 AM Christopher Lillthors < ***@***.***> wrote: Tested without any difference. The istio proxy seems to be working in "isolated mode" and will not trust any of the external XFF headers. Will you be able to flip the "use_remote_address" flag in an upcoming release? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qdy31LYzyIAZsfjTFx1omEiyVXT_2ks5r_lM3gaJpZM4NsTAL> .

-- ~shriram

[rshriram]

It does strip XFF though, IIRC. But it's for a good reason. It makes little sense to forward XFF headers, does it?

On Wed, May 31, 2017 at 7:07 PM Kuat ***@***.***> wrote: Are you saying that sidecar Envoy strips XFF? It seems that sidecar operates in the transparent mode, meaning the header is preserved https://lyft.github.io/envoy/docs/configuration/http_conn_man/headers.html#id9 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qdwSGhSFatFBtTknDQ1bOy1HLFDUfks5r_fKvgaJpZM4NsTAL> .

-- ~shriram

[christopherL91]

The problem occurs on gke since google is setting the client ip in a X-Forwarded-For header which then needs to be passed down. For now I have an nginx container before istio that does ssl-termination and passes the XFF headers to istio, but the istio proxy is filtering them out before the request ends up in the server. I wasn't able to get istio go pick up the XFF headers on it's own. Maybe there's a config that needs to tweaked?

[christopherL91]

btw, is it an acceptable solution to set a container before istio, or are you meant to terminate inside istio? I'm running istio-auth

[rshriram]

If you want ssl termination, istio ingress supports it. You get full mutual tls auth from ingress to all backend services. We don't have support for mutual tls auth right now, from ingress to clients. That aside, do you want the XFF header to be sent to your application itself ?

On Wed, May 31, 2017 at 7:16 PM Christopher Lillthors < ***@***.***> wrote: The problem occurs on gke since google is setting the client ip in a X-Forwarded-For header which then needs to be passed down. For now I have an nginx container before istio that does ssl-termination and passes the XFF headers to istio, but the istio proxy is filtering them out before the request ends up in the server. I wasn't able to get istio go pick up the XFF headers on it's own. Maybe there's a config that needs to tweaked?

-- ~shriram

[christopherL91]

Yes I would like to have the XFF headers inside the application. How do you fix that?

[rshriram]

I think this would require enabling the "use_remote_address" option in Envoy to allow envoy to append to XFF instead of stripping it. Just to eliminate some possibilities, would you mind trying with Istio ingress controller for SSL termination instead of nginx? -- ~shriram

[christopherL91]

Tested without any difference. The istio proxy seems to be working in "isolated mode" and will not trust any of the external XFF headers. Will you be able to flip the "use_remote_address" flag in an upcoming release?

[ldemailly]

@christopherL91 does 0.1.6 work for you now ?

[ldemailly]

closing assuming this is solved, please reopen if not