Can the Istio ingressgateway proxy traffic to external HTTPS service?

Networking
1

We have a question about the Istio ingressgateway. We have (in our opinion) a rather typical setup where we do TLS termination in the Istio ingressgateway (example.com in the diagram) and then route the traffic to internal Kubernetes services based on hostnames and URLs. So far, so good.
Now we have the requirement to send certain traffic, based on URL prefixes, to an external HTTPS service (example2.com in the diagram). We know how to do TLS origination, and it works quite well from within the mesh (e.g. a curl command in a bash shell running inside a pod with sidecar). But we can’t get it to work from the ingress gateway.
To put it in different words: we want HTTPS requests to be decrypted by the ingress gateway, it should look at hostname and path prefix and proxy certain traffic to an external HTTPS service. Here’s a diagram that explains it:

Untitled Diagram(1)
Untitled Diagram(1)1902×582 13.6 KB

Is that possible to implement with Istio? We have tried many combinations with ServiceEntry and DestinationRules, but the ingressgateway fails to do the TLS origination (which works fine from pods in the mesh)

2

@cbenien we had to change the destination rule to have a traffic policy for it to work with the ingress gateway / virtual service proxy pass:

spec:
host: {{ .service.hostname }}
trafficPolicy:
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE
sni: {{ .service.hostname }}

3

Hi @ceastman-ibm, thank you for the reply! I did already have a traffic policy. I took the time to simplify our configuration and make it possible to run it in Docker Desktop. I especially wanted to try if the latest version of Istio makes a difference (we are still on 1.5.8 in our system). To further simplify, I removed the TLS on the frontend and the URL prefix matching. Here’s the current config:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - httpbin.example.com
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-passthrough
spec:
  gateways:
  - httpbin-gateway
  - mesh
  hosts:
  - httpbin.example.com   # when used from the ingress gateway
  - httpbin.org           # when used within the mesh
  http:
  - route:
    - destination:
        port: 
          number: 443
        subset: tls-origination
        host: httpbin.org
    rewrite:
      authority: httpbin.org
    headers:
      request:
        set:
          x-virtualservice-frontend: "Added by VirtualService"
---    
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin-org
spec:
  host: httpbin.org
  subsets:
  - name: tls-origination
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
      portLevelSettings:
      - port:
          number: 443
        tls:
          mode: SIMPLE 
          sni: httpbin.org
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-org
spec:
  location: MESH_EXTERNAL
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http-port
    protocol: HTTP
  - number: 443
    name: https-port
    protocol: HTTPS
  resolution: DNS

Here’s the result:

$ curl localhost/get -H "Host: httpbin.example.com"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

TLS origination from within the mesh works fine, here’s a pod with a sidecar:

root@ubuntu:/# curl httpbin.org/get
{
  "args": {}, 
  "headers": {
    "Accept": "*/*", 
    "Content-Length": "0", 
    "Host": "httpbin.org", 
    "User-Agent": "curl/7.68.0", 
    "X-Amzn-Trace-Id": "Root=1-5f58b447-07148aa8d0eb29e4168872d8", 
    "X-B3-Sampled": "1", 
    "X-B3-Spanid": "42442ddcd57969ef", 
    "X-B3-Traceid": "6b0c834c73b68e6c42442ddcd57969ef", 
    "X-Envoy-Attempt-Count": "1", 
    "X-Envoy-Decorator-Operation": "httpbin.org:443/*", 
    "X-Envoy-Peer-Metadata": "ChoKCkNMVVNURVJfSUQSDBoKS3ViZXJuZXRlcwobCgxJTlNUQU5DRV9JUFMSCxoJMTAuMS4wLjQ4Cr4BCgZMQUJFTFMSswEqsAEKGQoMaXN0aW8uaW8vcmV2EgkaB2RlZmF1bHQKDwoDcnVuEggaBnVidW50dQokChlzZWN1cml0eS5pc3Rpby5pby90bHNNb2RlEgcaBWlzdGlvCisKH3NlcnZpY2UuaXN0aW8uaW8vY2Fub25pY2FsLW5hbWUSCBoGdWJ1bnR1Ci8KI3NlcnZpY2UuaXN0aW8uaW8vY2Fub25pY2FsLXJldmlzaW9uEggaBmxhdGVzdAoaCgdNRVNIX0lEEg8aDWNsdXN0ZXIubG9jYWwKEAoETkFNRRIIGgZ1YnVudHUKFgoJTkFNRVNQQUNFEgkaB2RlZmF1bHQKPgoFT1dORVISNRoza3ViZXJuZXRlczovL2FwaXMvdjEvbmFtZXNwYWNlcy9kZWZhdWx0L3BvZHMvdWJ1bnR1ChwKD1NFUlZJQ0VfQUNDT1VOVBIJGgdkZWZhdWx0ChkKDVdPUktMT0FEX05BTUUSCBoGdWJ1bnR1", 
    "X-Envoy-Peer-Metadata-Id": "sidecar~10.1.0.48~ubuntu.default~default.svc.cluster.local", 
    "X-Virtualservice-Frontend": "Added by VirtualService"
  }, 
  "origin": "82.X.X.X", 
  "url": "https://httpbin.org/get"
}
4

the doc for Istio 1.5 is the same as the Istio 1.7 related to egress-tls-origination, did anyone else encounter the same issue with the example provided?