Standard TLS authenticates in one direction: the client verifies the server's certificate, but the server does not verify the client. Mutual TLS (mTLS) closes this gap -- both sides present certificates and verify each other before exchanging data. This makes mTLS the foundation for zero-trust service-to-service communication.
Alibaba Cloud Service Mesh (ASM) applies mTLS across all three stages of traffic in a Kubernetes environment without requiring changes to application code. You can also use the certificates provided by mTLS at each stage for access control. Additionally, ASM manages certificate issuance and rotation automatically, so you do not need to handle certificates manually.
Traffic stages and how ASM secures them
End-to-end traffic in a Kubernetes environment passes through three stages. ASM secures each stage differently:
| Stage | Direction | How ASM secures it |
|---|---|---|
| Ingress | External clients to in-cluster services | External clients access in-cluster services through the ASM ingress gateway. You can configure mTLS and restrict access to specific client certificates. |
| East-west | Between workloads inside the cluster | Sidecar proxies automatically upgrade connections to mTLS. No application changes or additional configuration required. |
| Egress | In-cluster workloads to external services | The ASM egress gateway intercepts plaintext requests from workloads and upgrades them to mTLS before forwarding to the external service. |
Why use ASM for mTLS
| Benefit | Description |
|---|---|
| Separation of concerns | Applications focus on business logic while ASM handles authentication and encryption at the infrastructure level. This accelerates development cycles. |
| Automated certificate management | ASM issues certificates based on the Kubernetes ServiceAccount of each workload and rotates them automatically. No manual certificate operations required. |
| Non-disruptive adoption | Existing applications do not need code changes. Sidecar proxy injection and gateway configuration happen at the infrastructure level. |
Secure ingress traffic with mTLS
External clients reach in-cluster services through the ASM ingress gateway. To enforce mTLS at the ingress:
Configure the ASM ingress gateway to require client certificates.
Restrict access to specific clients by validating their certificate attributes.
For detailed setup instructions, see Configure mTLS service on ASM ingress gateway and restrict specific client access.
Secure east-west traffic with mTLS
East-west mTLS is a built-in capability of ASM. After you inject sidecar proxies into both sides of a connection, traffic between them is automatically upgraded to mTLS -- no additional configuration needed.
To inject sidecar proxies, see Install a sidecar proxy.
What is covered automatically
Pod-to-Pod traffic: Communication between two Pods with injected sidecar proxies uses mTLS automatically.
Gateway-to-sidecar traffic: The ASM ingress gateway, egress gateway, and sidecar proxies all connect to the ASM control plane. Communication between any of these components also uses mTLS.
Certificate lifecycle
Certificates for east-west mTLS are issued based on the ServiceAccount identity of each workload. The ASM control plane handles both issuance and periodic rotation, so no manual certificate management is required.
Migrate to strict mTLS
ASM supports gradual migration from plaintext to full mTLS through peer identity authentication policies:
During migration, set the peer identity authentication mode to
PERMISSIVE. In this mode, workloads accept both plaintext and mTLS traffic. This allows non-meshed services to continue communicating during the transition.After migration, switch the peer identity authentication mode to
STRICT. In this mode, workloads accept only mTLS traffic, which ensures full encryption for all east-west communication.
Secure egress traffic with mTLS
When an in-cluster workload calls an external service that requires mTLS, the application can continue sending plaintext requests. The ASM egress gateway intercepts these requests, upgrades them to mTLS, and forwards them to the external service. This eliminates the need for application-level TLS configuration when accessing external mTLS endpoints.
For setup instructions, see Use ASM egress gateway to access external mTLS services.