Routing to external services
Enable services in your service mesh to route to endpoints that are located outside the service mesh.
Overview
In some cases, one of your Istio-managed apps might need to communicate with services that are external to the service mesh. For example, your app might need to contact a public API or an on-prem database. If you installed Istio with the REGISTRY_ONLY option, communication is allowed only between services in the mesh. Communication to services outside the mesh is prohibited.
To allow services in the mesh to talk to services outside the mesh, you can leverage Gloo ExternalService and ExternalEndpoint custom resources to securely expose external endpoints. Gloo Mesh Enterprise translates these resources into an Istio ServiceEntry. Similar to virtual destinations, you can choose to assign a unique internal hostname to your external endpoint that your services in the service mesh use to send requests to.
To learn how to set up routing to external services, see Route to external services.
For more information about external services and external endpoints, see the following resources:
- Gloo Mesh Enterprise API docs for ExternalEndpoint
- Gloo Mesh Enterprise API docs for ExternalService
Want to route to a serverless function? Try out the Gloo CloudProvider instead of an ExternalService custom resource. For more information, see AWS Lambda in the Gloo Mesh Gateway docs.
About external services and external endpoints
ExternalService and ExternalEndpoint resources are used to make non-mesh or external services known to the services in the mesh. These external services can refer to a service outside the mesh but still within the cluster environment or to an external service that runs outside the cluster environment.
To understand when to use these ExternalService and ExternalEndpoint resources, let’s consider an example where a service in the mesh wants to connect to an external, on-prem database that is spread across multiple data centers. Each database instance is assigned a static IP address or hostname that you can use to connect to the instance. You have the option to create an ExternalService resource and include the IP addresses, CIDR range, or hostnames to reach the database instances. Services in the mesh can now route traffic to these database instances by using the IP or hostname of the database instances directly. You also have the option to apply traffic policies to the ExternalService resource to control and manipulate the traffic before it is forwarded to these endpoints.
Using ExternalService resources is a good approach, but how do you make sure that your services in your service mesh are aware of all the external endpoints that you created, and that requests to these endpoints are load balanced accordingly? Maybe, you even want requests from your service mesh to be routed to the closest external endpoint by default. You can solve these problems by using the ExternalService and ExternalEndpoint custom resources together.
An ExternalEndpoint creates an internal DNS entry or IP address that behaves similarly to setting a CNAME or A record in your DNS provider. Instead of updating the services in the mesh with all of the IP addresses or hostnames for each external endpoint, the services can use the internal hostname or IP address to communicate with these endpoints directly.
For more information, see the Routing examples for external services.
Allow or block all egress traffic
When you install Istio in your cluster, your service mesh is configured with the ALLOW_ANY outbound traffic policy by default. This option permits all egress traffic for all services in the service mesh so that services can communicate with services that are not in the mesh, including external endpoints.
If the outbound traffic policy is set to REGISTRY_ONLY, the Istio proxy blocks traffic to services that are not part of the mesh or are hosted outside the cluster, such as a public web server. To make non-mesh or external endpoints reachable by a service in the mesh, you set up ExternalService and ExternalEndpoint custom resources for these endpoints. Note that the REGISTRY_ONLY traffic policy blocks only traffic to hosts and can be bypassed if traffic is sent to an IP address instead.
To control egress traffic in your service mesh, it is recommended to set up an egress gateway that all egress traffic for an ExternalService is routed through. By also applying access policies to the ExternalService resource, you can ensure that only certain services in your mesh can send a request to the external endpoint.
If you do not use an egress gateway to route all egress traffic through, and you use a wildcard prefix domain for the external service host without selecting any ExternalEndpoints, the REGISTRY_ONLY outbound traffic policy can be bypassed and traffic can be sent to any external service by using a TCP passthrough listener on the sidecar proxy.
Blocking egress traffic with an egress gateway and access policies works only if clients send traffic to the egress gateway through the client’s sidecar proxy. If the sidecar proxy is bypassed, requests to an external endpoint might still be allowed, which can be a risk for malicious attacks. To make sure that no egress traffic is allowed, even if the client’s sidecar proxy is bypassed, create a network policy that blocks all egress traffic in addition to setting up an egress gateway. You can further reduce the surface for malicious attacks by deploying the egress gateway to a dedicated node. Also note that you cannot apply other policies, such as outlier detection or active healthchecks, to the egress gateway.
Perform TLS origination with egress gateways
You can use an egress gateway to originate TLS connections and secure the connection to the external endpoint.
When a client request is sent to an external endpoint, the client’s sidecar proxy intercepts this request and securely connects to the egress gateway via mutual TLS. The egress gateway then terminates the incoming TLS connection. To protect the connection from the egress gateway to the external service, you can choose to originate a new TLS connection at the gateway and encrypt the client request before it is sent to the external endpoint.
For more information, see Route all egress traffic through an egress gateway.
Routing examples for external services
Review the following routing examples to learn more about how you can leverage ExternalService and ExternalEndpoint custom resources in your service mesh.
Route to an IP or hostname directly
The following diagram shows how you can use an external service resource to route traffic to an endpoint that is located outside your service mesh by using the endpoint’s IP address, CIDR range, or hostname. To communicate with the external endpoint, the service in the mesh must know the IP address or hostname of the external endpoint that it wants to reach. No load balancing between external endpoints is provided. If the IP address or hostname of a database instance changes, you must update these values in the external service custom resource.
Route to an external endpoint by using the internal DNS name
The following diagram shows how you can leverage an external endpoint and external service resources together to set up an internal hostname for your database instances. If a service in the mesh wants to communicate with any of the database instances, a request is sent to the internal hostname. Services in the mesh do not need to be aware of the IP address or hostname of each individual instance. With this approach, traffic to the database instances is automatically load balanced.
Route all egress traffic through an egress gateway
Instead of sending traffic from a service in the mesh to an external endpoint directly, you can route all egress traffic through an egress gateway as shown in the following diagram. Because the egress gateway is part of the service mesh, the request between the client and the egress gateway is secured via mTLS. You must make sure that your client app makes the request to the external service by using the HTTP protocol. Then, the client’s sidecar proxy encrypts the request via TLS and sends the request to the egress gateway. The egress gateway terminates the TLC connection and originates a new TLS connection with the target destination.
Apply overlapping external service configuration
In some cases, you might have overlapping configuration across multiple external service resources. Gloo Mesh Enterprise validates the addresses that you specify in each external service, and does not translate an external service that defines the same address as an external service that already exists in your Gloo environment. However, you can apply external services that define the same address in different workspaces, if the workspaces do not import or export the external service resources between them. For example, you might represent the same database with the same address by applying an external service in a staging workspace and by applying an external service in a prod workspace. Because you do not import or export the external service resources between these two workspaces, the external service resources can be safely applied.