Traefik Mesh Automatic mTLS: Embedded CA, Service Identities, and Rotation Risks

The problem: plaintext service-to-service traffic

Inside many Kubernetes clusters, traffic between services travels unencrypted by default. If your platform needs zero-trust networking or compliance requires encrypted east-west traffic, you face a choice: manage certificates manually for every service pair, or adopt a mesh that handles issuance and rotation for you.

Traefik Mesh includes an embedded certificate authority that can issue mTLS certificates automatically. The useful takeaway is that you can enable mutual TLS between mesh services without creating secrets by hand, but you must coordinate it with ingress TLS and expect brief connection errors during certificate rotation.

How automatic mTLS is assigned

Traefik Mesh derives service identities from Kubernetes ServiceAccount resources. When a workload uses an annotated ServiceAccount, the mesh controller treats it as a trust boundary. The embedded CA issues a certificate to that workload, and the Traefik proxy sidecar presents it during TLS handshakes.

Terms used here:

• mTLS (mutual TLS): both sides of a connection present and verify certificates.
• Embedded CA: a certificate authority running inside the cluster, managed by Traefik Mesh, rather than an external CA such as Let’s Encrypt for internal traffic.
• ServiceAccount: a Kubernetes identity used by pods in a namespace.

Worked example: enable mesh mTLS

Prerequisites: a Kubernetes cluster, Helm installed, and cluster-admin or namespace-admin permissions to install the chart. Run these commands from your local workstation or CI runner.

helm repo add traefik https://helm.traefik.io/traefik
helm repo update
helm install traefik-mesh traefik/traefik-mesh \
  --namespace traefik-mesh \
  --create-namespace \
  --set mesh.enabled=true \
  --set mesh.mtls.enabled=true

Risk: installing a mesh changes cluster state. If you already run an ingress controller with TLS termination, test in a staging namespace first because mesh mTLS and ingress TLS can conflict on the same service ports.

Check that auto-generated secrets appear:

kubectl get secrets -n traefik-mesh | grep tls

Expected check: secrets named for mesh services should appear after workloads start. If no secrets appear, confirm the mesh controller is running and that target pods use annotated ServiceAccounts.

Verify rotation visibility with Prometheus:

curl http://prometheus-service:9090/metrics | grep traefik_mesh_tls_certificates_total

Expected check: an increasing counter indicates the controller is actively issuing or renewing certificates. A flat counter does not necessarily mean failure; it may mean no rotation is due yet.

Trade-offs and limitations

Automatic mTLS is not a drop-in replacement for every TLS setup.

Issue	What happens	Practical check
Ingress TLS conflicts	If your ingress controller terminates TLS at the edge and the mesh also expects mTLS on the same backend service, handshakes can fail.	Terminate TLS at only one layer, or merge ingress and mesh TLS configuration carefully.
Rotation outages	When the embedded CA rotates a certificate, dependent services may briefly reject connections until they reload the new certificate.	Test rolling updates in staging and monitor connection errors during renewal windows.
Non-Kubernetes support	Traefik Mesh outside Kubernetes is experimental and may require custom CA configuration.	Confirm your environment is supported before relying on automatic issuance.

Practical way to check the result

Deploy two test services in the mesh, enable mTLS, and capture traffic between them. You should see TLS handshakes rather than plaintext HTTP. Then force or wait for a certificate rotation and confirm services recover without manual intervention.

Closing

Enable Traefik Mesh mTLS in a non-production namespace first. Watch the traefik-mesh namespace for auto-generated secrets, monitor the Prometheus certificate counter, and schedule rotation tests before rolling to production. The embedded CA removes manual secret creation, but it does not remove the need to test how your services behave when certificates change.