The istioctl tool can be used to check whether the TLS settings match between the authentication policy and the destination rules for a particular microservice. Let's take a look:

1. Check the TLS flow between the server and the client:

$ HTTPBIN=$(kubectl -n istio-lab get pods -l app=httpbin -o jsonpath={.items[0].metadata.name}) ; echo $HTTPBIN
httpbin-v1-b9985cc7d-4wmcf

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

--- SERVER     CLIENT  AUTHN POLICY  DESTINATION RULE
--- HTTP/mTLS  HTTP    default/      -

If the status shows Conflict, this is an indication that the destination rules are in conflict with the protocol. In this example, the server (httpbin service) supports HTTP and mTLS, while the client supports HTTP, so the status is OK. If the client only supported mTLS, then the preceding status would have been in Conflict.

2. Modify the curl command to pass the client cert and key parameters in addition to cacert:

$ curl -HHost:httpbin.istio.io --resolve httpbin.istio.io:$INGRESS_PORT:$INGRESS_HOST --cacert $HOME/step/ca-chain.crt --cert $HOME/step/client.crt --key $HOME/step/client.key https://httpbin.istio.io/status/418

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`

This example shows how to enable mutual TLS without having to write a single line of code in the application. We have already covered terminating TLS traffic at the edge of the mesh through the Ingress gateway. The communication between microservices is still HTTP-based after the Ingress gateway.

3. Let's check the TLS settings between the Bookinfo productpage:

$ PRODUCT_PAGE=$(kubectl -n istio-lab get pods -l app=productpage -o jsonpath={.items..metadata.name}) ; echo $PRODUCT_PAGE
productpage-v1-74dfdd8b47-xmdpn

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

--- SERVER     CLIENT  AUTHN POLICY  DESTINATION RULE
--- HTTP/mTLS  HTTP    default/      -

Notice that the server supports both mTLS and HTTP (permissive TLS), but the client is only sending HTTP requests. Hence, mTLS is not enabled between the client and server. The default policy is used for authentication, and the destination rules are defined using productpage.

Check the default authentication policy, which is PERMISSIVE in this case (mTLS and HTTP). When the default mesh policy is set to PERMISSIVE, no authentication or authorization checks will be performed by default on plaintext HTTP traffic.

Let's go over how to secure communication between microservices using mutual TLS. This type of security is desired when processing business applications from the backend, especially when they are distributed in a zero-trust network.