Reading the blog article/readme, the architecture bears some similarities to the newly introduced Gateways in Istio, that allows bridging multiple kubernetes clusters or any infrastructure for that matter, while still leveraging a TLS infrastructure. (Disclaimer: I am one of the authors of the gateway in Istio). It would be educational and helpful for others (using Istio) to know the drawbacks of the architecture I describe below. If there are any limitations, we would be happy to address them. [sorry for spamming your issue list, but I couldn't get hold of your email]
Here is a simple strawman version of cross cluster communication using the gateways (https://github.com/rshriram/istio_federation_demo) which uses a similar architecture to yours (a globally shared DNS domain, ingress gateway to route to appropriate backend service, etc.). It has end to end mTLS (shared root CA, per cluster intermediate CA, etc.). With that, you would simply be able to do something like http://foo.bar.com, that would be upgraded to mTLS by the local sidecar (istio proxy), and forwarded to the remote gateway (authenticated via mTLS again), and then to the backend service.
Reading the blog article/readme, the architecture bears some similarities to the newly introduced Gateways in Istio, that allows bridging multiple kubernetes clusters or any infrastructure for that matter, while still leveraging a TLS infrastructure. (Disclaimer: I am one of the authors of the gateway in Istio). It would be educational and helpful for others (using Istio) to know the drawbacks of the architecture I describe below. If there are any limitations, we would be happy to address them. [sorry for spamming your issue list, but I couldn't get hold of your email]
Here is a simple strawman version of cross cluster communication using the gateways (https://github.com/rshriram/istio_federation_demo) which uses a similar architecture to yours (a globally shared DNS domain, ingress gateway to route to appropriate backend service, etc.). It has end to end mTLS (shared root CA, per cluster intermediate CA, etc.). With that, you would simply be able to do something like http://foo.bar.com, that would be upgraded to mTLS by the local sidecar (istio proxy), and forwarded to the remote gateway (authenticated via mTLS again), and then to the backend service.