In the constantly changing world of micro services, keeping communication routes safe is very important. Mutual TLS (mTLS) is a strong security system that makes sure both the client and the server can trust each other by adding an extra layer of authentication. We’ll learn more about mTLS in this blog post, including why it’s important, how it works in a service mesh, and some examples from real life.

How Does Mutual TLS (mTLS) Work

At its core, Mutual TLS (mTLS) is an addition to the Transport Layer Security (TLS) system that makes sure that both the client and the server are who they say they are when they talk to each other. In regular TLS, only the server is verified. With mTLS, the client also needs to show its credentials. This mutual authentication adds a new level of trust by making sure that both sides are real.

Mutual TLS (mTLS) Benefits in Micro Services

Setting up a safe and reliable connection is very important in a micro services design, where services often talk to each other over the network. mTLS solves common security problems:

Identity Verification and MITM: The client and the server both show digital certificates that prove who they are. So, people can’t get in without permission or pretend to be someone else. It also prevent man-in-the-middle attack as both sides authenticate each other.
Data Privacy: mTLS encrypts the communication route, which keeps people from listening in or changing the data that is being sent.

Example: NGINX Service Mesh

NGINX service mesh provides out of the box mTLS support when deployed on Kubernetes cluster. NGINX used service called SPIRE to manage the same. For configurability NGINX provides three modes namely off, permissive, and strict. mTLS support can be enabled when deploying NGINX service mesh by using flag –mtls-mode. For example

nginx-meshctl deploy ... --mtls-mode strict

By enabling mTLS mode, NGINX use the default self signed certificate. NGINX support something called Upstream Authority to get certificate from PKI providers. Supported PKI providers are disk, was_pca, awssecret, vault and cert manager. For example if we want to use cert-manager which is popular on Kubernetes platform

apiVersion: "v1"
upstreamAuthority: "cert-manager"
config:
  namespace: "certmanager-namespace"
  issuer_name: "letsencrypt-issuer"

For production deployment, it is recommended to use intermediate certificates which keeps the root certificate secure and add the certificate in the chain instead of key. Choose pathlen field and SPIRE key manager for intermediate and signing certificates.

Example: Istio

Now, let’s look at how mTLS can be used in a service mes called Istio.

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
helm install istio istio-official/istiod --version [version-number]

# Enable automatic sidecar injection
kubectl label namespace default istio-injection=enabled

We need to set up a DestinationRule in Istio for the services you want to protect in order to use mTLS for example, have a look on the below minimal configuration of service called test service

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: test-service-mtls
spec:
  host: test-service-mtls.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

To check mTLS in action, you can deploy a simple client server application in Kubernetes and can use the below command to test the communication. where client and services are two different pods

kubectl exec -it [client-pod-name] -- curl [http://service-name:port]

By using mTLS in a service mesh like Istio, NGINX mesh services and other tools you protect your micro services design from threats and build a strong base for trust. As micro services become more common, mTLS plays an even more important part in making sure that the data being sent between services is kept safe and private.