I have two isolated namespaces by NetworkPolicy and ingress/egress gateways in each, I need a solution to route traffic between them over egress/ingress gateways only. And also I need mTLS with certificates provided by external CA between gateways.
@wenchenglu@Tao_Li Have you guys considered this use case. We (affirmed networks) need to support this model as well.
Essentially, provide namespace network isolation (using network policies) and permit ingress only through ingress gateway and egress only via the egress gateway. Both Gateways will have mTLS enabled.
We would love to discuss this further with you guys if you are up for it ??
Nitishm, from security perspective, i don’t see any problems, but we need to support your case, but need to check with networking team to see whether this is feasible.
From the security perspective we need to support SDS on the egress gateway. With that in place both ingress and egress gateway certificate management would be handled uniformly.
I assume by “SDS on egress gateway”, you mean using SDS to get external key/cert for egress gateway, right? It’s already working for Ingress, does it work for egress?
Yup SDS to get external key/cert for egress gateway.
It’s supported on the ingress gateway which can be enabled through helm values specific to the ingress gateway. I would imagine the same mechanism could be enabled on the egress gateway to inject the ingress-sds agent. But unfortunately it does not exist today in 1.1
I love that. Let us know if you have time to contribute to this effort and we can work together to make this happen. We may also discuss later how to delegate the client workload identity to the external server through egress if you happen to have that use case.
How can we address services in this scenario? If we have only ingress endpoint, we can’t reach services behind ingress gateway, the only solution that I see, is to create virtualservice for ingress host with different uri matches. But it’s not convenient in some scenarios.
@1113 Yes you will need VirtualServices to route to your Services within the namespace. Because of the NetworkPolicies you will be forced to go this route (unless of course you create rules to ALLOW ingress traffic for those specific services. But I am guessing that is not the intended model.).
@wenchenglu, @Tao_Li One of the challenges we are facing currently, that I forgot to mention, is to configure the workload Sidecars to forcefully route all namespace-external traffic through the Egress Gateway. Is this possible using some Istio resources ? The idea is to have DENY ALL ACLs for all egress traffic other than the necessary metrics, egress GW, istio controlplane ports.
Thanks @wenchenglu. To prevent a rouge agent from bypassing the sidecar proxy and accessing external services directly, we will definitely look into k8s network policies as you suggest. But currently we are struggling with configuring all legitimate egress traffic from the sidecar to go through the egress gateway. This is easy for pre-configured specific external servers (following https://istio.io/docs/examples/advanced-gateways/egress-gateway/), but in our use-case, the set of external servers is not known apriori. And for supporting that, we apparently need a complicated setup with an additional Nginx SNI proxy which is far from ideal (https://istio.io/docs/examples/advanced-gateways/wildcard-egress-hosts/).
We are looking for enhancements that would make it easier to say:
Send all namespace-external traffic from the sidecar to the egress-gateway. Probably need to exclude istio control plane requests?
Send all egress traffic coming in to the egress gateway to the external server’s fqdn/ip as provided by the application without having to pre-configure white-listed external servers.
@liminwang could you help look into this and see if we can contribute to improving the egress traffic control by working with Istio network folks
fyi @duderino
I’m already tested these instructions separately, everything works perfectly, but I can’t test all chain right now because of some problems in our cluster.