Hello!
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.
Is there any one who can help?
We are trying to do something similar. Can you elaborate on the problems/limitations that you are facing ? Maybe we could share some insights ?!
@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 ??
FYI: @skydoctor
PS: The external client/external server could themselves be Istio Egress/Ingress Gateways, respectively. (i.e. namespace to namespace communication)
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
so egress to external server is also mTLS?
Yes, external server would support mTLS and egress gateway to external server should have mTLS in this use-case.
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.
@liminwang
I don’t think we can provide a strong egress control through sidecar envoy currently (there have been some discussions to improve that work through CNI), see https://istio.io/docs/tasks/traffic-management/egress/?_ga=2.121788043.1297637210.1558573004-166046602.1550116756#security-note. As noted in this doc, you might consider k8s network policy and see if that can provide what you need.
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:
@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 think, all can be done using this two official instructions:
And NetworkPolicy of cause to isolate namespaces.
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.
Any updates on this ?
@nitishm, are you asking about updates on improving the egress traffic control or something else?
fyi @liminwang
