Skip to main content
banner image
venafi logo

Why Mutual TLS Is Vital for Securing Microservices in a Service Mesh

Why Mutual TLS Is Vital for Securing Microservices in a Service Mesh

April 28, 2022 | Anastasios Arampatzis

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.

Venafi TLS Protect can solve your machine identity challenges.
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.

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 Jetstack, a Venafi company, 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

Like this blog? We think you will love this.
Featured Blog

How to Stop Outages in Your Kubernetes Clusters [Case Study]

InfoSec vs platform development teams

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Anastasios Arampatzis
Anastasios Arampatzis

Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more