In TLS communication, the client verifies the server's certificate, but the server does not authenticate the client since the client does not provide a certificate. For scenarios requiring higher security, the server must also verify the client's identity, which requires the use of mTLS communication. In mTLS, both the client and server present certificates, allowing encrypted communication only after mutual verification. This topic explains how to implement end-to-end mTLS communication in your environment using ASM.
Background information
With ASM, you can use mTLS to encrypt end-to-end traffic without modifying the application. Additionally, you can utilize the certificates provided by mTLS at each stage for access control. This approach enhances the overall security of your business.
In a Kubernetes environment, the end-to-end typically includes three stages:
Ingress traffic: Clients outside the cluster access services within the cluster.
East-west traffic: East-west traffic between workloads within the cluster.
Egress traffic: Workloads within the cluster access services outside the cluster.
Using ASM to implement end-to-end mTLS has the following benefits:
Applications can focus on business logic and delegate security capabilities to the service mesh infrastructure, accelerating business iteration.
ASM manages the issuance and rotation of certificates for communication within the cluster, significantly reducing your maintenance burden.
No need to modify business applications during migration, making the migration smoother.
Use mTLS to encrypt ingress traffic
When clients outside the cluster access services within the cluster, they need to go through the ASM ingress gateway. For more information, see Configure mTLS service on ASM ingress gateway and restrict specific client access.
Use mTLS to encrypt east-west traffic
East-west traffic mTLS communication is one of the basic features provided by ASM, and no additional configuration is required. Simply inject the Sidecar proxy into both sides of the communication within the cluster. For more information, see Install a sidecar proxy.
Communication between two pods injected with the Sidecar proxy is automatically upgraded to mTLS, and no modifications to the application are required. Additionally, since both are connected to the ASM control plane, communication between the ASM ingress/egress gateway and the Sidecar proxy also automatically uses mTLS encryption.
The certificates used in mTLS communication are issued based on the ServiceAccount used by the workload and are periodically rotated by the ASM control plane, eliminating the need for manual intervention.
To facilitate the gradual migration of your business to ASM, ASM provides peer identity authentication configuration. During the migration process, you can adjust the peer identity authentication level to PERMISSIVE (accepting both plaintext and mTLS traffic). After the migration is complete, you can change the peer identity authentication level to STRICT (only accepting mTLS traffic) to ensure that all traffic within the cluster is encrypted using mTLS.
Use mTLS to encrypt egress traffic
If you have a service outside the cluster that requires mTLS for access, your application can still initiate plaintext requests. The ASM egress gateway can upgrade these plaintext requests to mTLS and forward them to the external service. For more information, see Use ASM egress gateway to access external mTLS services.