Accessing External Services
Because all outbound traffic from an Istio-enabled pod is redirected to its sidecar proxy by default, accessibility of URLs outside of the cluster depends on the configuration of the proxy. By default, Istio configures the Envoy proxy to passthrough requests for unknown services. Although this provides a convenient way to get started with Istio, configuring stricter control is usually preferable.
This task shows you how to access external services in three different ways:
- Allow the Envoy proxy to pass requests through to services that are not configured inside the mesh.
- Configure service entries1 to provide controlled access to external services.
- Completely bypass the Envoy proxy for a specific range of IPs.
Before you begin
Setup Istio by following the instructions in the Installation guide2.
Deploy the sleep3 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:
Envoy passthrough to external services
Istio has an installation option5,
global.outboundTrafficPolicy.mode
, that configures the sidecar handling
of external services, that is, those services that are not defined in Istio’s internal service registry.
If this option is set to ALLOW_ANY
, the Istio proxy lets calls to unknown services pass through.
If the option is set to REGISTRY_ONLY
, then the Istio proxy blocks any host without an HTTP service or
service entry defined within the mesh.
ALLOW_ANY
is the default value, allowing you to start evaluating Istio quickly,
without controlling access to external services.
You can then decide to configure access to external services later.
To see this approach in action you need to ensure that your Istio installation is configured with the
global.outboundTrafficPolicy.mode
option set toALLOW_ANY
. Unless you explicitly set it toREGISTRY_ONLY
mode when you installed Istio, it is probably enabled by default.Run the following command to confirm it is configured correctly:
The string
mode: ALLOW_ANY
should appear in the output if it is enabled.Make a couple of requests to external HTTPS services from the
SOURCE_POD
to confirm successful200
responses:
Congratulations! You successfully sent egress traffic from your mesh.
This simple approach to access external services, has the drawback that you lose Istio monitoring and control for traffic to external services; calls to external services will not appear in the Mixer log, for example. The next section shows you how to monitor and control your mesh’s access to external services.
Controlled access to external services
Using Istio ServiceEntry
configurations, you can access any publicly accessible service
from within your Istio cluster. This section shows you how to configure access to an external HTTP service,
httpbin.org6, as well as an external HTTPS service,
www.google.com7 without losing Istio’s traffic monitoring and control features.
Change to the blocking-by-default policy
To demonstrate the controlled way of enabling access to external services, you need to change the
global.outboundTrafficPolicy.mode
option from the ALLOW_ANY
mode to the REGISTRY_ONLY
mode.
Run the following command to change the
global.outboundTrafficPolicy.mode
option toREGISTRY_ONLY
:Make a couple of requests to external HTTPS services from
SOURCE_POD
to verify that they are now blocked:
Access an external HTTP service
Create a
ServiceEntry
to allow access to an external HTTP service:Make a request to the external HTTP service from
SOURCE_POD
:Note the headers added by the Istio sidecar proxy:
X-Envoy-Decorator-Operation
.Check the log of the sidecar proxy of
SOURCE_POD
:Note the entry related to your HTTP request to
httpbin.org/headers
.Check the Mixer log. If Istio is deployed in the
istio-system
namespace, the command to print the log is:Note that the
destinationServiceHost
attribute is equal tohttpbin.org
. Also notice the HTTP-related attributes:method
,url
,responseCode
and others. Using Istio egress traffic control, you can monitor access to external HTTP services, including the HTTP-related information of each access.
Access an external HTTPS service
Create a
ServiceEntry
to allow access to an external HTTPS service.Make a request to the external HTTPS service from
SOURCE_POD
:Check the log of the sidecar proxy of
SOURCE_POD
:Note the entry related to your HTTPS request to
www.google.com
.Check the Mixer log. If Istio is deployed in the
istio-system
namespace, the command to print the log is:Note that the
requestedServerName
attribute is equal towww.google.com
. Using Istio egress traffic control, you can monitor access to external HTTPS services, in particular the SNI8 and the number of sent and received bytes. Note that in HTTPS all the HTTP-related information like method, URL path, response code, is encrypted so Istio cannot see and cannot monitor that information for HTTPS. If you need to monitor HTTP-related information in access to external HTTPS services, you may want to let your applications issue HTTP requests and configure Istio to perform TLS origination9.
Manage traffic to external services
Similar to inter-cluster requests, Istio
routing rules
can also be set for external services that are accessed using ServiceEntry
configurations.
In this example, you set a timeout rule on calls to the httpbin.org
service.
From inside the pod being used as the test source, make a curl request to the
/delay
endpoint of the httpbin.org external service:The request should return 200 (OK) in approximately 5 seconds.
Exit the source pod and use
kubectl
to set a 3s timeout on calls to thehttpbin.org
external service:Wait a few seconds, then make the curl request again:
This time a 504 (Gateway Timeout) appears after 3 seconds. Although httpbin.org was waiting 5 seconds, Istio cut off the request at 3 seconds.
Cleanup the controlled access to external services
Direct access to external services
If you want to completely bypass Istio for a specific IP range,
you can configure the Envoy sidecars to prevent them from
intercepting10
external requests. To set up the bypass, change either the global.proxy.includeIPRanges
or the global.proxy.excludeIPRanges
configuration option5 and
update the istio-sidecar-injector
configuration map using the kubectl apply
command. This can also
be configured on a pod by setting corresponding annotations11 such as
traffic.sidecar.istio.io/includeOutboundIPRanges
.
After updating the istio-sidecar-injector
configuration, it affects all
future application pod deployments.
A simple way to exclude all external IPs from being redirected to the sidecar proxy is
to set the global.proxy.includeIPRanges
configuration option to the IP range or ranges
used for internal cluster services.
These IP range values depend on the platform where your cluster runs.
Determine the internal IP ranges for your platform
Set the value of global.proxy.includeIPRanges
according to your cluster provider.
IBM Cloud Private
Get your
service_cluster_ip_range
from IBM Cloud Private configuration file undercluster/config.yaml
:The following is a sample output:
Use
--set global.proxy.includeIPRanges="10.0.0.1/24"
IBM Cloud Kubernetes Service
Use --set global.proxy.includeIPRanges="172.30.0.0/16\,172.21.0.0/16\,10.10.10.0/24"
Google Container Engine (GKE)
The ranges are not fixed, so you will need to run the gcloud container clusters describe
command to determine the
ranges to use. For example:
Use --set global.proxy.includeIPRanges="10.4.0.0/14\,10.7.240.0/20"
Azure Container Service(ACS)
Use --set global.proxy.includeIPRanges="10.244.0.0/16\,10.240.0.0/16
Minikube, Docker For Desktop, Bare Metal
The default value is 10.96.0.0/12
, but it’s not fixed. Use the following command to determine your actual value:
Use --set global.proxy.includeIPRanges="10.96.0.0/12"
Configuring the proxy bypass
Update your istio-sidecar-injector
configuration map using the IP ranges specific to your platform.
For example, if the range is 10.0.0.1/24, use the following command:
Use the same command that you used to install Istio12 and
add --set values.global.proxy.includeIPRanges="10.0.0.1/24"
.
Access the external services
Because the bypass configuration only affects new deployments, you need to redeploy the sleep
application as described in the Before you begin section.
After updating the istio-sidecar-injector
configmap and redeploying the sleep
application,
the Istio sidecar will only intercept and manage internal requests
within the cluster. Any external request bypasses the sidecar and goes straight to its intended destination.
For example:
Unlike accessing external services through HTTP or HTTPS, you don’t see any headers related to the Istio sidecar and the requests sent to external services appear neither in the log of the sidecar nor in the Mixer log. Bypassing the Istio sidecars means you can no longer monitor the access to external services.
Cleanup the direct access to external services
Update the istio-sidecar-injector.configmap.yaml
configuration map to redirect all outbound traffic to the sidecar
proxies:
Understanding what happened
In this task you looked at three ways to call external services from an Istio mesh:
Configuring Envoy to allow access to any external service.
Use a service entry to register an accessible external service inside the mesh. This is the recommended approach.
Configuring the Istio sidecar to exclude external IPs from its remapped IP table.
The first approach directs traffic through the Istio sidecar proxy, including calls to services that are unknown inside the mesh. When using this approach, you can’t monitor access to external services or take advantage of Istio’s traffic control features for them. To easily switch to the second approach for specific services, simply create service entries for those external services. This process allows you to initially access any external service and then later decide whether or not to control access, enable traffic monitoring, and use traffic control features as needed.
The second approach lets you use all of the same Istio service mesh features for calls to services inside or outside of the cluster. In this task, you learned how to monitor access to external services and set a timeout rule for calls to an external service.
The third approach bypasses the Istio sidecar proxy, giving your services direct access to any external server. However, configuring the proxy this way does require cluster-provider specific knowledge and configuration. Similar to the first approach, you also lose monitoring of access to external services and you can’t apply Istio features on traffic to external services.
Security note
To implement egress traffic control in a more secure way, you must direct egress traffic through an egress gateway13 and review the security concerns described in the additional security considerations section.
Cleanup
Shutdown the sleep3 service:
Set the outbound traffic policy mode to your desired value
Check the current value:
The output will be either
mode: ALLOW_ANY
ormode: REGISTRY_ONLY
.If you want to change the mode, perform the following commands: