Implement end-to-end mTLS encryption for applications using ASM
In standard TLS, the client verifies the server's certificate, but the server has no way to authenticate the client. Mutual TLS (mTLS) closes this gap by requiring both sides to present and verify certificates before any encrypted communication begins. Alibaba Cloud Service Mesh (ASM) adds end-to-end mTLS to your Kubernetes environment without application code changes -- certificates are issued, rotated, and enforced automatically so your applications can focus on business logic.
Benefits
| Benefit | Description |
|---|---|
| No application changes | ASM encrypts traffic at the infrastructure layer. Existing workloads migrate to mTLS without code modifications. |
| Automatic certificate management | The ASM control plane issues certificates based on each workload's ServiceAccount identity and rotates them periodically. No manual intervention is needed. |
| Certificate-based access control | mTLS certificates at every stage of the traffic path enforce identity-based access policies. |
How it works
In a Kubernetes environment, end-to-end traffic spans two segments:
| Traffic segment | Direction | Description |
|---|---|---|
| Ingress traffic | External to internal | Clients outside the cluster reach services inside the cluster through the ASM ingress gateway. |
| East-west traffic | Internal to internal | Workloads inside the cluster communicate with each other. |
ASM secures both segments with mTLS. The following sections explain how to configure each segment.
Encrypt ingress traffic
External clients reach internal services through the ASM ingress gateway. Configure the gateway to require client certificates so that only authorized clients can establish connections.
For step-by-step instructions, see Configure an mTLS service on an ASM ingress gateway and restrict access from specific clients.
Encrypt east-west traffic
mTLS for east-west traffic is a built-in ASM capability. Enable Ambient mode for both communicating workloads, and traffic between them is encrypted automatically. No additional configuration is needed.
For a walkthrough, see Deploy a sample application and enable Ambient mode to implement encrypted communication.
After you enable Ambient mode:
Pod-to-pod traffic upgrades to mTLS automatically. No application changes are required.
Gateway-to-proxy traffic is also encrypted. Both the ASM ingress gateway and the proxies connect to the ASM control plane, so mTLS covers this path as well.
Certificate lifecycle
Certificates used in mTLS are issued based on each workload's ServiceAccount. The ASM control plane handles the full certificate lifecycle -- issuing certificates when workloads start and rotating them periodically before they expire. No manual intervention or downtime is needed.
Migrate to strict mTLS
ASM supports phased migration from plaintext to fully encrypted traffic through peer authentication policies. This lets you onboard workloads gradually without disrupting services that have not yet joined the mesh.
| Phase | Mode | Behavior | When to use |
|---|---|---|---|
| Onboarding | PERMISSIVE | Accepts both plaintext and mTLS traffic. | While adding workloads to the mesh. Existing non-meshed clients continue to work. |
| Full enforcement | STRICT | Accepts only mTLS traffic. Plaintext connections are rejected. | After all workloads communicate over mTLS. Ensures all traffic within the cluster is encrypted. |