Skip to content

CONCEPT Cited by 1 source

Mutual TLS (mTLS)

Mutual TLS (mTLS) is TLS with two-way peer authentication: both ends of the connection present certificates, and each verifies the other's identity against a trust anchor, before encrypted traffic flows. In a service-mesh context, this means a calling service presents its cert to the callee and the callee presents its cert back — neither side accepts traffic from an unauthenticated peer.

It is the foundational primitive for zero-trust networking: "trusted network" as a security boundary is replaced by "cryptographically-authenticated peer" on every hop.

One-way TLS vs mTLS

  • One-way TLS (the default): server presents a cert, client verifies the server's identity. Client is anonymous to the TLS layer (usually authenticated at a higher layer via tokens/JWTs). This is what every https:// browser connection is.
  • mTLS: both sides present certs. The server learns the client's identity at the TLS layer, not at the application layer.

Why mTLS in service meshes

  • Zero-trust between services. Even inside the VPC / Kubernetes cluster, a callee verifies who its caller is — kills lateral-move attack vectors after a compromise.
  • Decoupling from application auth. Identity at the transport layer means every service gets peer auth "for free"; no per-application JWT/session handling required.
  • Audit at the cert level. Certificates issued to named workloads give a cryptographic audit surface that JWTs from one shared identity provider do not.
  • Required in regulated environments (PCI, HIPAA, FedRAMP, etc.) that mandate in-network peer authentication.

PKI substrate

mTLS requires a private certificate authority issuing certs to workloads — public web-PKI CAs don't issue workload identities. AWS's primitive is AWS Private CA; the Kubernetes / Istio analog is the mesh's built-in CA or cert-manager-driven issuers. Short-lived certs (hours or days, not years) are the rotation-friendly norm.

Implementations

  • AWS App Mesh — supports mTLS; uses AWS Private CA certs; customer-managed Envoy sidecar handles the handshake.
  • AWS ECS Service Connect — does not yet support mTLS as of the 2025-01-18 migration announcement. Explicitly named as a feature gap vs. App Mesh.
  • Istio — mTLS is a default-on primitive; the sidecar Envoy handles it transparently.
  • Proxyless meshes (Databricks Robinhood, gRPC xDS) — mTLS implemented in the client library, not a sidecar.

The Service Connect gap

The 2025-01-18 App Mesh → Service Connect migration guide explicitly names mTLS as the most consequential Service Connect feature gap: App Mesh supports it, Service Connect (at the time) does not. For regulated workloads that picked App Mesh specifically for mTLS, the migration options are:

  1. Stay on App Mesh until 2026-09-30 EOL and re-evaluate before then.
  2. Exit to a self-managed systems/envoy/Istio stack (recovering mTLS but losing the AWS-managed operational benefit).
  3. Migrate to Service Connect and accept the gap (works if mTLS was belt-and-suspenders to other controls; fails audit if it was load-bearing).

Seen in

Last updated · 200 distilled / 1,178 read