intermediate 2 min answer

Where should TLS terminate in a platform serving customer traffic, and what changes when a compliance requirement demands encryption in transit inside the network?

hasuratlsmtlsservice-meshcompliance
Show the full answer Hide the answer

The default and its rationale

Terminate at the edge — a load balancer or proxy — and use plain HTTP internally. This is simple, gives one place to manage certificates, keeps CPU cost at the boundary, and allows the proxy to inspect and route requests.

It rests on an assumption that is increasingly rejected: that the internal network is trustworthy.

What changes with encryption-in-transit requirements

  • Mutual TLS between services, which provides both encryption and cryptographic service identity. The identity is usually the more valuable half — it replaces network-location-based trust with something that cannot be spoofed by being inside the network.
  • Certificate lifecycle becomes an operational system. Thousands of short-lived certificates, rotated automatically, with a failure mode that must be understood. Expired certificates are among the most common causes of self-inflicted outages, and the answer is automation with alerting well ahead of expiry, not longer lifetimes.
  • A service mesh becomes attractive, because it provides mTLS without changing application code. That is its strongest justification — stronger than traffic management or observability, which are available more cheaply elsewhere.
  • Debugging becomes harder. Packet inspection stops working, which changes how network problems are diagnosed and forces investment in application-level tracing.

The nuance worth stating

Encryption in transit and service identity are separable, and identity is usually the point. A system with mTLS but no authorisation policy has encrypted channels between services that will still do whatever they are asked. The value arrives when the identity is used for authorisation — this service may call that endpoint — which is the part teams defer.

The pragmatic middle

For most organisations: TLS at the edge, mTLS for traffic crossing a trust boundary (between clusters, between environments, to third parties, across a data-classification line), and plain internal traffic within a single tightly controlled boundary — with the classification of what counts as a boundary written down rather than assumed.