@costinm commented on Sat May 27 2017

In a multi-cluster environment, or if CDNs or other infrastructure is required, istio ingress
may be behind another L7 load balancer, which may handle TLS and route to a region/cluster
running istio.

The LB will update X-Forwarded-For, X-Forwarded-Proto - and possibly other headers in
case of TLS-client authentication.

In this mode, the istio ingress should only accept traffic from the frontend (no external IP),

• or should have a whitelist or other mean to identify traffic from the front load
  balancer ( so the injected attributes are accepted only from the front load balancer,
  and filtered out/rejected if they are sent by an attacker)

XFF is most common, and each load balancer has a number of extensions. For examples
if Envoy is used as a global/front load balancer it may use x-envoy-external-address and
set other headers https://lyft.github.io/envoy/docs/configuration/http_conn_man/headers.html
Haproxy defines a number of TLS-related headers http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

@therc commented on Tue May 30 2017

On a related note: how are proxies like Google's Identity-Aware Proxy or bitly's oauth2_proxy supposed to be chained?

@kyessenov commented on Tue May 30 2017

IAP proxy is a different use case. I think with regards to platform-provided proxy like GKE ingress controller, chaining them is a common use-case and as long as the proxy passes the origin information through headers, we should be ok to utilize it in Istio.

IAP proxy or any other single-purpose proxy can be set-up between GKE ingress and Istio ingress as a proxy pool deployment with manual configuration to pass-through requests to istio-ingress service. Again, the origin information must be preserved by this proxy.

@costinm commented on Tue May 30 2017

IAP is a bit different - it may also use X-Goog-Authenticated-User-JWT, which is a JWT signed by
IAP, adding an extra layer of protection. But AFAIK it's only available in some environments.
The critical part is accepting headers from "trusted" chained proxies, and rejecting headers from external users - ideally all components, including chained proxies, would use authenticated TLS, like
istio auth enables, which will have a similar benefit.

In general, the process for chaining IAP and IAP-like proxies would be similar - istio-ingress and the other components will need to know the list of injected headers, and have some way to verify the request is from the trusted proxy.

In some cases it may be possible to chain IAP-like proxies behind Istio-ingress - it depends
a lot on whether you accept TLS-client cert authentication, and where you want to terminate
the original TLS cert.