Egress using Wildcard Hosts
The Accessing External Services6 task and
the Configure an Egress Gateway7 example
describe how to configure egress traffic for specific hostnames, like edition.cnn.com
.
This example shows how to enable egress traffic for a set of hosts in a common domain, for
example *.wikipedia.org
, instead of configuring each and every host separately.
Background
Suppose you want to enable egress traffic in Istio for the wikipedia.org
sites in all languages.
Each version of wikipedia.org
in a particular language has its own hostname, e.g., en.wikipedia.org
and
de.wikipedia.org
in the English and the German languages, respectively.
You want to enable egress traffic by common configuration items for all the Wikipedia sites,
without the need to specify every language’s site separately.
Before you begin
Install Istio using the
demo
configuration profile8 and with the blocking-by-default outbound traffic policy:Deploy the sleep9 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:
Configure direct traffic to a wildcard host
The first, and simplest, way to access a set of hosts within a common domain is by configuring
a simple ServiceEntry
with a wildcard host and calling the services directly from the sidecar.
When calling services directly (i.e., not via an egress gateway), the configuration for
a wildcard host is no different than that of any other (e.g., fully qualified) host,
only much more convenient when there are many hosts within the common domain.
Define a
ServiceEntry
for*.wikipedia.org
:Send HTTPS requests to https://en.wikipedia.org11 and https://de.wikipedia.org12:
Cleanup direct traffic to a wildcard host
Configure egress gateway traffic to a wildcard host
The configuration for accessing a wildcard host via an egress gateway depends on whether or not the set of wildcard domains are served by a single common host. This is the case for *.wikipedia.org. All of the language-specific sites are served by every one of the wikipedia.org servers. You can route the traffic to an IP of any *.wikipedia.org site, including www.wikipedia.org, and it will manage to serve13 any specific site.
In the general case, where all the domain names of a wildcard are not served by a single hosting server, a more complex configuration is required.
Wildcard configuration for a single hosting server
When all wildcard hosts are served by a single server, the configuration for egress gateway-based access to a wildcard host is very similar to that of any host, with one exception: the configured route destination will not be the same as the configured host, i.e., the wildcard. It will instead be configured with the host of the single server for the set of domains.
Create an egress
Gateway
for *.wikipedia.org, a destination rule and a virtual service to direct the traffic through the egress gateway and from the egress gateway to the external service.Create a
ServiceEntry
for the destination server, www.wikipedia.org.Send HTTPS requests to https://en.wikipedia.org11 and https://de.wikipedia.org12:
Check the statistics of the egress gateway’s proxy for the counter that corresponds to your requests to *.wikipedia.org. If Istio is deployed in the
istio-system
namespace, the command to print the counter is:
Cleanup wildcard configuration for a single hosting server
Wildcard configuration for arbitrary domains
The configuration in the previous section worked because all the *.wikipedia.org sites can
be served by any one of the wikipedia.org servers. However, this is not always the case.
For example, you may want to configure egress control for access to more general
wildcard domains like *.com
or *.org
.
Configuring traffic to arbitrary wildcard domains introduces a challenge for Istio gateways. In the previous section you directed the traffic to www.wikipedia.org, which was made known to your gateway during configuration. The gateway, however, would not know the IP address of any arbitrary host it receives in a request. This is due to a limitation of Envoy14, the proxy used by the default Istio egress gateway. Envoy routes traffic either to predefined hosts, predefined IP addresses, or to the original destination IP address of the request. In the gateway case, the original destination IP of the request is lost since the request is first routed to the egress gateway and its destination IP address is the IP address of the gateway.
Consequently, the Istio gateway based on Envoy cannot route traffic to an arbitrary host that is not preconfigured, and therefore is unable to perform traffic control for arbitrary wildcard domains. To enable such traffic control for HTTPS, and for any TLS, you need to deploy an SNI forward proxy in addition to Envoy. Envoy will route the requests destined for a wildcard domain to the SNI forward proxy, which, in turn, will forward the requests to the destination specified by the SNI value.
The egress gateway with SNI proxy and the related parts of the Istio architecture are shown in the following diagram:
The following sections show you how to redeploy the egress gateway with an SNI proxy and then configure Istio to route HTTPS traffic through the gateway to arbitrary wildcard domains.
Setup egress gateway with SNI proxy
In this section you deploy an egress gateway with an SNI proxy in addition to the standard Istio Envoy proxy.
This example uses Nginx15 for the SNI proxy, although any SNI proxy that is capable of routing traffic
according to arbitrary, not-preconfigured, SNI values would do.
The SNI proxy will listen on port 8443
, although you can use any port other than the ports specified for
the egress Gateway
and for the VirtualServices
bound to it.
The SNI proxy will forward the traffic to port 443
.
Create a configuration file for the Nginx SNI proxy. You may want to edit the file to specify additional Nginx settings, if required. Note that the
listen
directive of theserver
specifies port8443
, itsproxy_pass
directive usesssl_preread_server_name
with port443
andssl_preread
ison
to enableSNI
reading.Create a Kubernetes ConfigMap16 to hold the configuration of the Nginx SNI proxy:
Create an
IstioOperator
CR to add a new egress gateway with SNI proxy:Deploy the new gateway:
Verify that the new egress gateway is running. Note that the pod has two containers (one is the Envoy proxy and the second one is the SNI proxy).
Create a service entry with a static address equal to 127.0.0.1 (
localhost
), and disable mutual TLS for traffic directed to the new service entry:
Configure traffic through egress gateway with SNI proxy
Define a
ServiceEntry
for*.wikipedia.org
:Create an egress
Gateway
for *.wikipedia.org, port 443, protocol TLS, and a virtual service to direct the traffic destined for *.wikipedia.org through the gateway.Add an
EnvoyFilter
to the gateway, to prevent it from being deceived.Send HTTPS requests to https://en.wikipedia.org11 and https://de.wikipedia.org12:
Check the log of the egress gateway’s Envoy proxy. If Istio is deployed in the
istio-system
namespace, the command to print the log is:You should see lines similar to the following:
Check the logs of the SNI proxy. If Istio is deployed in the
istio-system
namespace, the command to print the log is:
Cleanup wildcard configuration for arbitrary domains
Delete the configuration items for *.wikipedia.org:
Delete the configuration items for the
egressgateway-with-sni-proxy
deployment:Remove the configuration files you created:
Cleanup
Shutdown the sleep9 service:
Uninstall Istio from your cluster: