Traffic Encryption (mTLS)

You want traffic between your own services inside the cluster to be encrypted
and authenticated, not just traffic arriving from the internet. The platform
does this with mutual TLS (mTLS) provided by Linkerd: both ends of a connection
present a certificate, so data in transit is protected and only trusted services
can talk to each other. Certificate issuance and rotation are handled for you.

No application code changes are required.

Before you start

• Plan a window for the change. Enabling mTLS on a workload requires the pods to
  be restarted, so treat it like any other deployment: a Component running a
  single replica will have a short gap in service while it restarts.
• Decide which workloads are in scope. Not everything benefits:
  • Traffic that already terminates its own TLS end to end gains nothing.
  • Connections to managed data services outside the cluster — databases,
    caches, and similar — are not pod-to-pod traffic and are not covered here.
  • Short-lived job and CronJob pods behave differently from long-running
    services once a sidecar is attached. Raise a request before enabling mTLS on
    those, rather than labelling them and finding out.

Enabling mTLS

1. In SVIEW, add two Global Variables to the relevant Environment:

terraform.variables.linkerd = true
terraform.variables.trust_manager = true

2. Add the label linkerd.io/inject=enabled to the deployment or the namespace
   you want encrypted.
3. Restart the affected deployments.

Once the restart completes, traffic between mTLS-enabled pods is encrypted and
authenticated automatically.

How to confirm traffic is actually encrypted

Labelling alone does not encrypt anything — the pods must have been restarted
since the label was applied, and both ends of a connection must be enabled.
Check in this order:

1. In SVIEW, open the Component dashboard and confirm the pods restarted after
   you added the label, and that the Component is healthy.
2. Confirm that the pods are now running an extra proxy container alongside your
   application container. That sidecar is what performs the encryption — if it
   is absent, the workload was not injected. With Kubernetes namespace
   access you can see the container list with:

kubectl get pod <pod-name> -n <your-namespace> -o jsonpath='{.spec.containers[*].name}{"\n"}'

3. Confirm the other side is enabled too. Encryption applies between
   mTLS-enabled pods, so a call from an injected pod to an uninjected one is not
   protected. Check the label on both workloads.

If you need written confirmation of the mesh's own view of encrypted traffic —
for an audit, for example — raise a request and CTO2B will provide it.

Common issues

Still having issues? Raise a request with the namespace, both Component names,
and the error you are seeing.

Related articles

• Namespace Access
• Network Policies
• Ingress, Custom Domains and TLS