How to connect Namespaces over ingress/egress gateways only?

Security
21

The former. Just wanted a heartbeat and see if there is any traction to support this.

22

@nitishm This is definitely something we would like to support. Let me discuss it with networking folks and get back to you.

1 Like
23

@nitishm, @skydoctor I chatted with @Costin_Manolache regarding the potential improvements on Ingress and Egress traffic control.

  1. For sending all traffic to the egress-gateway, the recommended way is to use the combination of Istio networking policies (VirtualService/Gateway/DestinationRules) and k8s network policy as suggested in https://istio.io/docs/examples/advanced-gateways/egress-gateway/.

  2. For sending all egress traffic coming in to the egress gateway to a server that is not pre-configured (e.g., dynamically determined based on SNI). This will require changes to Envoy to support dynamically generated destination clusters. This would be a useful feature for both Envoy and Istio. I did a quick search and found that there is an Envoy tracking issue to implement it.

cc. @louiscryan @duderino

24

Thanks for looking into this @liminwang. The key problem with the prescribed method to send all traffic to egress-gateway is that one instance of ServiceEntry + VirtualService + DestinationRule needs to be created for every external host or at best every wildcarded domain. It would be great to have an option to configure a “default” route in the envoy sidecar that matches for all domains and all prefixes and send that to a pre-configured cluster i.e. the egress-gateway. Unlike the doc examples where it was known that traffic for edition.cnn.com or *.wikipedia.org needs to be sent through the egress-gateway, in the generic use-case, we would not know these external domains in advance. In some cases, the external server could be an IP address in which case even wildcarding would not work.

Once at the egress-gateway, I agree that we need that envoy feature to send the traffic to a destination that is not a pre-configured cluster but is instead read from the SNI (for HTTPS) or the host/authority header (for HTTP).

1 Like
25

@skydoctor Thanks for explaining the problem. My understanding is, issue 1 and 2 are correlated. Because of 2, currently a specific ServiceEntry needs to be created for every external host (or every wildcarded domain). Once 2 is solved, we will be able to remove this requirement (requiring some code changes on Istio side as well).

26

Makes sense. There seems to be progress on the Envoy issue. Let’s re-group when that work is complete.