We will be using a slightly different version of the bookinfo application, which has a new ratings-v2 service that calls the MongoDB service:

To redefine the destination rules, follow these steps:

1. We added the following stanza after the host for the destination rules for productpage, details, ratings, and reviews:

trafficPolicy:
  tls:
    mode: ISTIO_MUTUAL

2. Here are the modified destination rules for the bookinfo application. Let's take a look:

# Script : 05-create-mtls-bookinfo-destination-rules.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
     version: v1
---

This is the destination rule definition for the reviews microservice:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---

This is the destination rule definition for the ratings microservice:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:

...
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---

This is the destination rule definition for the details microservice:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---

3. Apply the modified destination rules for the bookinfo microservices:

$ kubectl -n istio-lab apply -f 05-create-mtls-bookinfo-destination-rules.yaml 
destinationrule.networking.istio.io/productpage configured
destinationrule.networking.istio.io/reviews configured
destinationrule.networking.istio.io/ratings configured
destinationrule.networking.istio.io/details configured

4. Now that we've defined the destination rule for each microservice, we can check the TLS between the productpage microservice and ingress gateway:

$ istioctl authn tls-check $PRODUCT_PAGE.istio-lab istio-ingressgateway.istio-system.svc.cluster.local
HOST:PORT                                               ---   
istio-ingressgateway.istio-system.svc.cluster.local:80  ---   

--- STATUS     SERVER        CLIENT     
--- OK         HTTP/mTLS     HTTP       

--- AUTHN POLICY     DESTINATION RULE
--- default/         -

$ istioctl authn tls-check $PRODUCT_PAGE.istio-lab productpage.istio-lab.svc.cluster.local
HOST:PORT                                      ---  
productpage.istio-lab.svc.cluster.local:9080   ---  

--- STATUS     SERVER        CLIENT     
--- OK         HTTP/mTLS     mTLS       

--- AUTHN POLICY     DESTINATION RULE
--- default/         productpage/istio-lab

The preceding result shows that the traffic between the microservices is mTLS and that the status is OK. The traffic at the Ingress gateway can be either HTTP or HTTPS due to our definition of a simple TLS while defining the gateway for the bookinfo.istio.io host. 

Similarly, redefine the destination rule for httpbin:

# Script : 06-create-mtls-httpbin-destination-rules.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

5. Apply the destination rule for httpbin:

$ kubectl -n istio-lab apply -f 06-create-mtls-httpbin-destination-rules.yaml 
destinationrule.networking.istio.io/httpbin configured

After turning on mTLS (ISTIO_MUTUAL) for the httpbin microservice through the destination rule, check TLS using istioctl. The client only accepts mTLS. 

From your browser window tab, refresh the third tab, that is, http://httpbin.istio.io/headers. You will notice an entry for the additional header for SECURE IDENTITY of the service through SPIFFY URI:

"X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/istio-lab/sa/default;Hash=1466acd2330485fcf8036746a6728937ea8a672bd54c5d19236a8e8c75ad19d1;Subject="";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"

We can turn on mutual TLS either globally, at the namespace level, or at the service level. The TLS policy that's defined at service level takes precedence over the namespace-level policy. In our case, we will turn on mutual TLS at the istio-lab namespace level. 

The global mTLS can be enabled by editing the Istio MeshPolicy primitive and changing mtls to nil (=PERMISSIVE), as follows:

apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
  name: "default"
spec:
  peers:
  - mtls: {}

Next, we will enable TLS at the namespace level.