I want to get egress traces and metrics from a pod which I don't control much (in terms of code) to a third-party egress endpoint (that I don't control at all). You can think of it as e.g. traffic from a wordpress installation to api.wordpress.org.

I plan to terminate the tls on the egress and then create a new tls session from there. For that I generate a certificate for api.wordpress.org from a CA that I can inject into the pod.

I have the following configuration:

---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: egress-api-wordpress-org
spec:
  hosts:
    - api.wordpress.org
  gateways:
    - mesh
    - egress-api-wordpress-org
  tls:
    - match:
        - gateways:
            - mesh
          port: 443
          sniHosts:
            - api.wordpress.org
      route:
        - destination:
            host: istio-egressgateway.istio-egress.svc.cluster.local
            port:
              number: 443
  http:
    - match:
        - gateways:
            - egress-api-wordpress-org
          port: 443
      route:
        - destination:
            host: api.wordpress.org
            port:
              number: 443
---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: egress-api-wordpress-org
spec:
  hosts:
    - api.wordpress.org
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  resolution: DNS
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
spec:
  host: api.wordpress.org
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
      - port:
          number: 443
        tls:
          mode: SIMPLE

With this setup I see the traffic passing through the egress (and I have the metrics and traces egress-side). However, there are no details on the origin -- which kind of makes sense as the sidecar's envoy can't see what's the traffic inside.

Is there any way to provide the origin details to the egress without hacking on the origin pod's source code? I'm generally fine with weird things like tls-in-tls if it's possible to set it up (I'm not sure I can terminate tls on egress twice -- for istio_mutual and simple layers).