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.
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.