From the previous chapter, we configured the Istio ingress gateway to expose the bookinfo HTTP service's endpoints to external traffic. In this section, we will configure simple or mutual TLS to provide HTTPS access to the external traffic to access bookinfo services. It is our assumption that you have an understanding of simple and mutual TLS authentication. Additional information can be found here: https://bit.ly/2voH44c.

Simple or mutual TLS termination at the ingress gateway for incoming requests assumes that downstream services are safe and not liable to external attacks or insider threats. After the ingress gateway has been secured, downstream service communication is done using a plaintext HTTP protocol. 

If access is requested to external services, TLS origination should start an egress gateway for secure communication with an external service. It is not good practice for a microservice to initiate an HTTPS session with an external service. We lose monitoring and policy enforcement because of sidecar proxies. In such cases, there are two recommended options:

• TLS origination at the sidecar proxy level: Communication between the sidecar and the external service is encrypted, but pod to sidecar communication is not encrypted. A simple use case could be an environment where microservices are running in a federated, multi-Kubernetes cluster, and the network is prone to internal threats and is inherently insecure.

• TLS origination at the egress gateway: The communication behind the egress gateway is not encrypted. A use case could be an environment where microservices are running within the same Kubernetes cluster and the internal threat is not a concern.  

Modern microservices design should always be done by keeping the zero-trust network in mind without any requirement for any type of firewall. Such a requirement can be easily met by adopting Istio's service mesh architecture on top of cloud-native microservices-based applications. 

We will not be covering mount-based secrets where keys and certificates from secrets are mounted within a container. This approach can cause performance regression during certificate rotation whenever a sidecar restart picks up new keys and certificates.

Since private keys are distributed through secrets, the pod owner can see the value of the secret. Through Secret Discovery Service (SDS), private keys never leave the node, and it resides only at the Citadel agent and sidecar memory. The secret volumes are no longer mounted within a pod. The sidecar is able to renew keys and certificates through the SDS API; hence, there is no need to recycle the sidecar to pick up new keys and certificates. 

Now, let's work on securing the ingress gateway with simple or mutual TLS termination using SDS by Istio.