Egress Gateways
The Control Egress Traffic1 task shows how to configure Istio to allow access to external HTTP and HTTPS services from applications inside the mesh. There, the external services are called directly from the client sidecar. This example also shows how to configure Istio to call external services, although this time indirectly via a dedicated egress gateway service.
Istio uses ingress and egress gateways2 to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.
Use case
Consider an organization that has a strict security requirement that all traffic leaving the service mesh must flow through a set of dedicated nodes. These nodes will run on dedicated machines, separated from the rest of the nodes running applications in the cluster. These special nodes will serve for policy enforcement on the egress traffic and will be monitored more thoroughly than other nodes.
Another use case is a cluster where the application nodes don’t have public IPs, so the in-mesh services that run on them cannot access the Internet. Defining an egress gateway, directing all the egress traffic through it, and allocating public IPs to the egress gateway nodes allows the application nodes to access external services in a controlled way.
Before you begin
Setup Istio by following the instructions in the Installation guide3.
Deploy the sleep4 sample app to use as a test source for sending requests. If you have automatic sidecar injection enabled, run the following command to deploy the sample app:
Otherwise, manually inject the sidecar before deploying the
sleep
application with the following command:Set the
SOURCE_POD
environment variable to the name of your source pod:
Deploy Istio egress gateway
Check if the Istio egress gateway is deployed:
If no pods are returned, deploy the Istio egress gateway by performing the next step.
Run the following command:
Egress gateway for HTTP traffic
First create a ServiceEntry
to allow direct traffic to an external service.
Define a
ServiceEntry
foredition.cnn.com
:Verify that your
ServiceEntry
was applied correctly by sending an HTTP request to http://edition.cnn.com/politics6.The output should be the same as in the TLS Origination for Egress Traffic7 example, without TLS origination.
Create an egress
Gateway
for edition.cnn.com, port 80, and a destination rule for traffic directed to the egress gateway.Define a
VirtualService
to direct traffic from the sidecars to the egress gateway and from the egress gateway to the external service:Resend the HTTP request to http://edition.cnn.com/politics8.
The output should be the same as in the step 2.
Check the log of the
istio-egressgateway
pod for a line corresponding to our request. If Istio is deployed in theistio-system
namespace, the command to print the log is:You should see a line similar to the following:
Note that you only redirected the traffic from port 80 to the egress gateway. The HTTPS traffic to port 443 went directly to edition.cnn.com.
Cleanup HTTP gateway
Remove the previous definitions before proceeding to the next step:
Egress gateway for HTTPS traffic
In this section you direct HTTPS traffic (TLS originated by the application) through an egress gateway.
You need to specify port 443 with protocol TLS
in a corresponding ServiceEntry
, an egress Gateway
and a VirtualService
.
Define a
ServiceEntry
foredition.cnn.com
:Verify that your
ServiceEntry
was applied correctly by sending an HTTPS request to https://edition.cnn.com/politics8.Create an egress
Gateway
for edition.cnn.com, a destination rule and a virtual service to direct the traffic through the egress gateway and from the egress gateway to the external service.Send an HTTPS request to https://edition.cnn.com/politics8. The output should be the same as before.
Check the log of the egress gateway’s proxy. If Istio is deployed in the
istio-system
namespace, the command to print the log is:You should see a line similar to the following:
Cleanup HTTPS gateway
Additional security considerations
Note that defining an egress Gateway
in Istio does not in itself provides any special treatment for the nodes
on which the egress gateway service runs. It is up to the cluster administrator or the cloud provider to deploy
the egress gateways on dedicated nodes and to introduce additional security measures to make these nodes more
secure than the rest of the mesh.
Istio cannot securely enforce that all egress traffic actually flows through the egress gateways. Istio only enables such flow through its sidecar proxies. If attackers bypass the sidecar proxy, they could directly access external services without traversing the egress gateway. Thus, the attackers escape Istio’s control and monitoring. The cluster administrator or the cloud provider must ensure that no traffic leaves the mesh bypassing the egress gateway. Mechanisms external to Istio must enforce this requirement. For example, the cluster administrator can configure a firewall to deny all traffic not coming from the egress gateway. The Kubernetes network policies9 can also forbid all the egress traffic not originating from the egress gateway (see the next section for an example). Additionally, the cluster administrator or the cloud provider can configure the network to ensure application nodes can only access the Internet via a gateway. To do this, the cluster administrator or the cloud provider can prevent the allocation of public IPs to pods other than gateways and can configure NAT devices to drop packets not originating at the egress gateways.
Apply Kubernetes network policies
This section shows you how to create a
Kubernetes network policy9 to prevent
bypassing of the egress gateway. To test the network policy, you create a namespace, test-egress
, deploy
the sleep4 sample to it, and then attempt to send requests to a gateway-secured
external service.
Follow the steps in the Egress gateway for HTTPS traffic section.
Create the
test-egress
namespace:Deploy the sleep4 sample to the
test-egress
namespace.Check that the deployed pod has a single container with no Istio sidecar attached:
Send an HTTPS request to https://edition.cnn.com/politics8 from the
sleep
pod in thetest-egress
namespace. The request will succeed since you did not define any restrictive policies yet.Label the namespaces where the Istio components (the control plane and the gateways) run. If you deployed the Istio components to
istio-system
, the command is:Label the
kube-system
namespace.Define a
NetworkPolicy
to limit the egress traffic from thetest-egress
namespace to traffic destined toistio-system
, and to thekube-system
DNS service (port 53):Resend the previous HTTPS request to https://edition.cnn.com/politics8. Now it should fail since the traffic is blocked by the network policy. Note that the
sleep
pod cannot bypassistio-egressgateway
. The only way it can accessedition.cnn.com
is by using an Istio sidecar proxy and by directing the traffic toistio-egressgateway
. This setting demonstrates that even if some malicious pod manages to bypass its sidecar proxy, it will not be able to access external sites and will be blocked by the network policy.Now inject an Istio sidecar proxy into the
sleep
pod in thetest-egress
namespace by first enabling automatic sidecar proxy injection in thetest-egress
namespace:Then redeploy the
sleep
deployment:Check that the deployed pod has two containers, including the Istio sidecar proxy (
istio-proxy
):Create the same destination rule as for the
sleep
pod in thedefault
namespace to direct the traffic through the egress gateway:Send an HTTPS request to https://edition.cnn.com/politics8. Now it should succeed since the traffic flows to
istio-egressgateway
in theistio-system
namespace, which is allowed by the Network Policy you defined.istio-egressgateway
forwards the traffic toedition.cnn.com
.Check the log of the egress gateway’s proxy. If Istio is deployed in the
istio-system
namespace, the command to print the log is:You should see a line similar to the following:
Cleanup network policies
Delete the resources created in this section:
Follow the steps in the Cleanup HTTPS gateway section.
Troubleshooting
If mutual TLS Authentication10 is enabled, verify the correct certificate of the egress gateway:
For HTTPS traffic (TLS originated by the application), test the traffic flow by using the openssl command. openssl has an explicit option for setting the SNI, namely
-servername
.If you get the certificate as in the output above, your traffic is routed correctly. Check the statistics of the egress gateway’s proxy and see a counter that corresponds to your requests (sent by openssl and curl) to edition.cnn.com.
Cleanup
Shutdown the sleep4 service: