Mutual TLS: Vital for Securing Microservices in a Service Mesh

Why do you need mTLS?

While TLS is being used to secure traffic between clients and servers on the internet, it does so by using unidirectional authentication — the server presents a digital certificate to prove its identity to a client. This is the classic scenario of a user accessing a web-based service or a website.

Mutual TLS extends the client-server TLS model to include authentication of both communicating parties. mTLS uses x.509 certificates to identify and authenticate each microservice. Each certificate contains a public encryption key, and an identity – it is signed by a trusted certificate authority (CA). 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.

As zero trust security is becoming the cornerstone of corporate cybersecurity strategies and privacy compliance requirements are increasing, mTLS provides a secure way to ensure that each individual microservice communication is authenticated, authorized, and encrypted.

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. And encryption not only prevents third parties from intercepting and viewing your data in transit, but also defends against man-in-the-middle attacks.

Sponsorships Available

Sponsorships Available

Sponsorships Available

How service mesh and mTLS work together

Service mesh control planes like Istio provide secure service-to-service communication, without the need for any application code changes. From an mTLS perspective, all service mesh control planes must offer a certificate authority to handle certificate signing and management, and a configuration API server to distribute authentication and authorization policies as well as secure naming information to the proxies.

Embedding mTLS into a service mesh control plane provides further functional benefits, such as:

• Automatically encrypt and decrypt requests and responses to remove the burden from your application developers
• Improve performance by prioritizing the reuse of existing connections, reducing the need for the computationally expensive creation of new ones
• Understand and enforce how services are communicating, and prove it cryptographically

mTLS and sidecars

Certificate management and policy enforcement should not be allocated to the application microservice container. This is where sidecar patterns come in handy.

Sidecars were named after the sidecar attached to a motorcycle. In the pattern, the sidecar is attached to a parent application and provides supporting features for the application. The sidecar also shares the same lifecycle as the parent application, as it is created and retired alongside the parent.

Going back to mTLS in service mesh, the control plane distributes the certificates and authorization policies to the sidecars. When two microservices need to communicate, the sidecars establish a secure proxy-proxy link and are responsible for encrypting the traffic through it.

Although it is possible to define security policies and implement authentication and encryption in the application microservices themselves, this is not efficient. You will need to implement authentication mechanisms, define authorization policies, and establish traffic encryption in the code of each microservice.

Even worse, you must write these into each microservice, update it when the application changes, and test it on every release to ensure that the new code does not break the communication. This adds excessive burden onto the shoulders of developers, leads to errors and prevents them from focusing on code that implements business logic.

When two microservices need to communicate, it is the sidecars that establish the mTLS connection to encrypt all traffic. The sidecars exchange certificates and authenticate each other with the certificate authority. They check the authorization policies in the configuration pushed by the control plane, to see if the microservices are allowed to communicate. If authorization is granted, the sidecars establish a secure link using a generated session key. The actual microservice application is not affected.

How to make mTLS work for your service mesh

Mutual TLS is a critical component of zero trust networking, and is vital to secure the communications between the microservices in your service mesh. Implementation, however, is not entirely straightforward. This is where cert-manager comes in handy.

Developed by Venafi’s partners at Jetstack, cert-manager integrates with Istio service mesh to provide signing capabilities for workloads. Working with the Security WG in the Istio community, the cert-manager team at Jetstack have built an integration that enables cert-manager to sign workload certificates in an Istio service mesh for mutual TLS authentication.

Related posts

• Key Factors for Successful Certificate Management
• Certificate Management Best Practices
• Why Manual Certificate Management Really Hurts
• New Analyst Guidelines for Machine Identity Management [Gartner]

When transitioning to a microservices architecture, it is important to consider that breaking applications into smaller pieces increases the surface area for attacks. 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.

Mutual TLS (mTLS) addresses this security challenge by protecting communication between microservices in a service mesh. mTLS provides client and server-side security for service-to-service communications. It enables organizations to enhance network security with reduced operational burden.

“>