Standard TLS only authenticates one side: the client verifies the server's certificate, but the server never verifies the client. Mutual TLS (mTLS) closes this gap -- both sides present certificates and verify each other before exchanging data, providing authenticated, encrypted communication at every hop.
Alibaba Cloud Service Mesh (ASM) implements mTLS at the infrastructure layer across all three traffic stages in a Kubernetes environment -- ingress, east-west, and egress -- without requiring changes to your application code. Sidecar proxies handle certificate exchange and encryption transparently, and ASM automatically manages the full certificate lifecycle.
How ASM implements mTLS
End-to-end traffic in a Kubernetes cluster passes through three stages. ASM secures each one with mTLS:
| Stage | Traffic path | How ASM applies mTLS |
|---|---|---|
| Ingress | External clients -> services inside the cluster | Through the ASM ingress gateway |
| East-west | Workload <-> workload inside the cluster | Automatically, through sidecar proxies |
| Egress | Workloads inside the cluster -> external services | Through the ASM egress gateway |
Certificate provisioning workflow
When a workload starts, ASM automatically provisions identity certificates through the following flow:
The sidecar proxy in the pod sends a certificate signing request (CSR) to the ASM control plane.
The ASM control plane validates the request and issues a certificate bound to the pod's
ServiceAccountidentity.When two sidecar-injected pods communicate, their proxies perform a mutual TLS handshake, verifying each other's identity before exchanging data.
The ASM control plane periodically rotates these certificates without manual intervention.
Because the ASM ingress gateway and egress gateway also connect to the ASM control plane, traffic between gateways and sidecar proxies is encrypted with mTLS as well.
Benefits
| Benefit | Description |
|---|---|
| Business logic focus | Applications can focus on business logic and delegate security capabilities to the service mesh infrastructure, accelerating business iteration. |
| Zero application changes | Sidecar proxies handle certificate exchange and encryption transparently. Migrate existing services to ASM without modifying application code. |
| Automatic certificate management | ASM issues certificates based on each workload's ServiceAccount and rotates them automatically. No manual certificate provisioning or renewal is required. |
| Granular access control | The identity certificates that mTLS provides can also drive authorization policies, giving you fine-grained control over which services can communicate. |
Encrypt ingress traffic
External clients reach cluster services through the ASM ingress gateway. To require mTLS at the ingress layer, configure the gateway to present a server certificate and validate the client certificate before forwarding traffic to backend services.
For step-by-step instructions, see Configure mTLS service on ASM ingress gateway and restrict specific client access.
Encrypt east-west traffic
East-west mTLS is a built-in capability of ASM. Once both communicating workloads have a sidecar proxy injected, all traffic between them is automatically upgraded to mTLS -- no additional configuration is needed.
To inject sidecar proxies into your workloads, see Install a sidecar proxy.
Migrate from PERMISSIVE to STRICT mode
During migration, not all workloads may have sidecar proxies injected at the same time. ASM provides two peer authentication modes for a gradual rollout:
| Mode | Behavior | When to use |
|---|---|---|
PERMISSIVE | Accepts both plaintext and mTLS traffic | During migration, while some workloads still lack sidecar proxies |
STRICT | Accepts only mTLS traffic | After all workloads have sidecar proxies injected |
Recommended migration path:
Start with
PERMISSIVEmode to avoid breaking existing plaintext connections.Inject sidecar proxies into all workloads. For instructions, see Install a sidecar proxy.
Verify that all workloads are meshed and that inter-service traffic uses mTLS.
Switch to
STRICTmode to enforce full encryption across the cluster.
After switching to STRICT mode, any workloads without a sidecar proxy will lose connectivity to meshed services. Make sure all workloads are meshed before you switch.
Encrypt egress traffic
When a workload inside the cluster needs to reach an external service that requires mTLS, the application can still send plaintext requests. The ASM egress gateway intercepts these requests, upgrades them to mTLS, and forwards them to the external service. This keeps mTLS complexity out of your application code.
For configuration details, see Use ASM egress gateway to access external mTLS services.
Coverage boundaries
mTLS is not applied to all traffic by default. The following scenario is not covered:
| Scenario | Reason | Mitigation |
|---|---|---|
| Traffic to or from pods without sidecar proxies | mTLS requires both sides to have a sidecar proxy | Inject sidecar proxies into all workloads |