Egress Gateways with TLS Origination (File Mount)
The TLS Origination for Egress Traffic2 example shows how to configure Istio to perform TLS origination for traffic to an external service. The
Configure an Egress Gateway3 example shows how to configure Istio to direct egress traffic through a dedicated egress gateway service. This example combines the previous two by describing how to configure an egress gateway to perform TLS origination for traffic to external services.Before you begin
Setup Istio by following the instructions in the Installation guide4.
Start the sleep5 sample which will be used as a test source for external calls.
If you have enabled automatic sidecar injection, do
otherwise, you have to manually inject the sidecar before deploying the
sleep
application:Note that any pod that you can
exec
andcurl
from would do.Create a shell variable to hold the name of the source pod for sending requests to external services. If you used the sleep5 sample, run:
For macOS users, verify that you are using
openssl
version 1.1 or later:If the previous command outputs a version
1.1
or later, as shown, youropenssl
command should work correctly with the instructions in this task. Otherwise, upgrade youropenssl
or try a different implementation ofopenssl
, for example on a Linux machine.
Perform TLS origination with an egress gateway
This section describes how to perform the same TLS origination as in the TLS Origination for Egress Traffic2 example, only this time using an egress gateway. Note that in this case the TLS origination will be done by the egress gateway, as opposed to by the sidecar in the previous example.
Define a
ServiceEntry
foredition.cnn.com
:Verify that your
ServiceEntry
was applied correctly by sending a request to http://edition.cnn.com/politics7.Your
ServiceEntry
was configured correctly if you see 301 Moved Permanently in the output.Create an egress
Gateway
for edition.cnn.com, port 80, and a destination rule for sidecar requests that will be directed to the egress gateway.Define a
VirtualService
to direct the traffic through the egress gateway, and aDestinationRule
to perform TLS origination for requests toedition.cnn.com
:Send an HTTP request to http://edition.cnn.com/politics7.
The output should be the same as in the TLS Origination for Egress Traffic2 example, with TLS origination: without the 301 Moved Permanently message.
Check the log of the
istio-egressgateway
pod and you should see 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:
Cleanup the TLS origination example
Remove the Istio configuration items you created:
Perform mutual TLS origination with an egress gateway
Similar to the previous section, this section describes how to configure an egress gateway to perform TLS origination for an external service, only this time using a service that requires mutual TLS.
This example is considerably more involved because you need to first:
- generate client and server certificates
- deploy an external service that supports the mutual TLS protocol
- redeploy the egress gateway with the needed mutual TLS certs
Only then can you configure the external traffic to go through the egress gateway which will perform TLS origination.
Generate client and server certificates and keys
For this task you can use your favorite tool to generate certificates and keys. The commands below use openssl8
Create a root certificate and private key to sign the certificate for your services:
Create a certificate and a private key for
my-nginx.mesh-external.svc.cluster.local
:Generate client certificate and private key:
Deploy a mutual TLS server
To simulate an actual external service that supports the mutual TLS protocol, deploy an NGINX9 server in your Kubernetes cluster, but running outside of the Istio service mesh, i.e., in a namespace without Istio sidecar proxy injection enabled.
Create a namespace to represent services outside the Istio mesh, namely
mesh-external
. Note that the sidecar proxy will not be automatically injected into the pods in this namespace since the automatic sidecar injection was not enabled on it.Create Kubernetes Secrets10 to hold the server’s and CA certificates.
Create a configuration file for the NGINX server:
Create a Kubernetes ConfigMap11 to hold the configuration of the NGINX server:
Deploy the NGINX server:
Redeploy the egress gateway with the client certificates
Create Kubernetes Secrets10 to hold the client’s and CA certificates.
To include a volume mounted from the new created secret, update the
istio-egressgateway
deployment. To patch theistio-egressgateway
deployment, create the followinggateway-patch.json
file:Apply
istio-egressgateway
deployment patch with the following command:Verify that the key and the certificate are successfully loaded in the
istio-egressgateway
pod:tls.crt
andtls.key
should exist in/etc/istio/nginx-client-certs
, whileca-chain.cert.pem
in/etc/istio/nginx-ca-certs
.
Configure mutual TLS origination for egress traffic
Create an egress
Gateway
formy-nginx.mesh-external.svc.cluster.local
, port 443, and destination rules and virtual services to direct the traffic through the egress gateway and from the egress gateway to the external service.Define a
VirtualService
to direct the traffic through the egress gateway:Add a
DestinationRule
to perform mutual TLS originationSend an HTTP request to
http://my-nginx.mesh-external.svc.cluster.local
: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:
Cleanup the mutual TLS origination example
Remove created Kubernetes resources:
Delete the certificates and private keys:
Delete the generated configuration files used in this example:
Cleanup
Delete the sleep
service and deployment: