Mutual TLS: Securing Microservices in Service Mesh

The world is moving toward microservices-based applications. Service mesh is emerging as one of the main architectures to deploy and manage microservices environments, because of the benefits it brings with advanced traffic management, holistic observability and better security. Microservices communicate with each other through APIs, so securing communications between the individual services is becoming more important than ever and has to be addressed.

Mutual TLS (mTLS) secures communication between microservices in a service mesh. It uses cryptographically secure techniques to mutually authenticate individual microservices and encrypt the traffic between them.

Why mTLS?

According to Google, 90% of internet traffic is encrypted to prevent eavesdropping and man-in-the-middle attacks. Yet many cloud native application deployments today do not have encrypted communications between microservices, based on the weak assumption that traffic inside the cluster is secure and not susceptible to attacks. This is a risky assumption. Not only should communications between microservices be secured, but many regulations (like GDPR and HIPAA) also recommend end-to-end encryption to protect all data in transit.

In this era of zero trust security, each individual microservice communication (request-response) must be authenticated, authorized and encrypted. Here’s why:

• Authentication uniquely identifies each microservice and ensures that a rogue microservice cannot access your sensitive data.
• Authorization determines which microservices can communicate with each other. You wouldn’t want the microservice that handles your company’s credit card processing to communicate with the microservice that manages the door badge reader for your office building.
• Encryption not only prevents third parties from intercepting and viewing your data in transit, but also thwarts man-in-the-middle attacks. You definitely don’t want credit card data to be visible to unauthorized entities on the network.

As companies move towards zero trust security, mTLS provides a cryptographically secure way to authenticate, encrypt and enforce communication policies between microservices.

What Is mTLS?

Mutual TLS (or mTLS) refers to transport layer security that uses a two-way encrypted channel between the server and client. Today, mTLS is the preferred protocol for securing communications among microservices in cloud native applications.

Figure 1: What is mTLS?

While transport layer security (TLS) has been used to secure traffic between clients and servers on the internet for many years, it typically uses unidirectional identification — where a server presents a certificate to prove its identity to a client. A basic example of this one-way authentication is when you access your bank account online. The server sends your computer a certificate to prove it is actually the bank you are connecting to. That same certificate includes a public encryption key that is used to create a cryptographically secure encrypted link between you and the bank over which data passes.

Mutual TLS extends the client-server TLS model to include authentication of both parties. Where the bank relies on other, application-specific mechanisms to confirm a client’s identity — such as a user name and password (often accompanied by two-factor authentication) — mTLS uses x.509 certificates to identify and authenticate each microservice. Each certificate contains a public encryption key and an identity, and is signed by a trusted certificate authority who proves that the certificate represents the entity presenting it.

In mTLS, each microservice in a service mesh verifies the other’s certificate and uses the public keys to create encryption keys unique to each conversation. This enables the communications between pairs of microservices to be authenticated and encrypted.

How mTLS Works in a Service Mesh

What we have learned at NetScaler, is, at a high level, the process of authenticating and establishing an encrypted channel using certificate-based mutual authentication in a service mesh involves the following steps:

1. Microservice A sends a request for the certificate of microservice B.