I'm working on a project using the Gateway API on GKE with Istio as the service mesh. My objective is to utilize Google's managed Gateway API to handle external traffic, rather than an Istio-managed one. The challenge I'm facing is securing the traffic between this external Gateway and the backend pods, which aren't set up to handle HTTPS natively. While Istio mTLS protects traffic between pods, it doesn't automatically secure communication between the external Gateway API and backend pods. I'm looking for a strategy to either terminate TLS close to the pod or establish a secure channel to ensure that traffic remains encrypted within the cluster. Is there a way to manage TLS termination for traffic between the Gateway API and the pods using the Istio sidecar?
1 Answer
You might want to try using a `TLSRoute` in `Passthrough` mode for your situation. That could help with managing the traffic. Plus, according to the documentation, combining Terminate TLS mode with BackendTLSPolicy is supported in HTTPRoute, which effectively provides a connection that is first terminated at the Gateway and then re-encrypted.
Can you elaborate on that? The external Gateway API will definitely secure the client connection. The main issue is how to set up a new HTTPS connection from the Gateway to the backend if the pods themselves can’t handle HTTPS. The Istio sidecar usually requires mTLS traffic, but it seems like it can't manage direct HTTPS termination from the external Gateway API. To clarify, if I'm using a dedicated Envoy Proxy as the Gateway, it can terminate TLS for the client side, but how does Envoy create another secured connection to the backend if that service can't handle the TLS?