Traefik Mesh Gateway mTLS Without Sidecars Across Clusters

Securing east-west traffic across multiple Kubernetes clusters usually means choosing between manual certificate management and a full sidecar mesh. Traefik Mesh, part of Traefik Proxy Enterprise, takes a gateway-centric approach: Traefik Proxy instances act as mesh gateways and the Ingress Controller automates service discovery, so application pods stay mesh-unaware.

The useful takeaway is mTLS automation without per-pod proxies. Identity and encryption are enforced at the gateway boundary, with certificate lifecycle handled by the mesh control plane rather than application teams.

Gateway-centric discovery instead of sidecar sprawl

Traditional service meshes inject a sidecar proxy into each pod. That gives fine-grained control but adds resource overhead and complicates pod lifecycle management.

Traefik Mesh instead uses the Traefik Proxy as a service-mesh gateway. Internal microservices are discovered automatically via Kubernetes providers, and the mesh routes between clusters through the gateways. Application code does not need mesh-specific protocols or injected configuration.

Automated mTLS and cross-cluster trust

Mutual TLS (mTLS) requires both client and server to present and verify certificates. In multi-cluster setups, the hard part is Certificate Authority (CA) synchronization and rotation across clusters.

Traefik Mesh integrates certificate management into the mesh. Gateways terminate and originate mTLS for traffic that crosses the mesh, and the control plane distributes trust roots to the participating proxies. This removes manual secret rotation from developers.

Limitation: Traefik Mesh features are Enterprise only and are not available in the open source edition. Cross-cluster CA synchronization is a critical operational dependency; mismatched trust roots cause handshake failures and service outages.

Worked example: canary TrafficRoute

Traffic shaping is expressed with Custom Resource Definitions (CRDs). The following conceptual TrafficRoute splits internal requests between a stable service and a canary:

apiVersion: traefik.io/v1alpha1
kind: TrafficRoute
metadata:
  name: api-service-canary
  namespace: production
spec:
  rule:
  - Host(`api.internal.local`)
    Path(`/v1/data`)
  match:
    services:
    - name: api-v1
      weight: 90
    - name: api-v2-canary
      weight: 10

Apply from an admin workstation with kubeconfig access to the target cluster:

kubectl apply -f canary.yaml

Required permissions: ability to create traefik.io/v1alpha1 TrafficRoute resources in the namespace. Risk: incorrect weights can send production traffic to an unstable canary. Verify with kubectl get trafficroute -n production and check the Traefik Dashboard for correct service mapping. Field names may vary by version; confirm the CRD schema installed in your cluster before applying.

Verify mTLS and observability

Check that mesh services are identified correctly in the Traefik Dashboard under the providers view.

To inspect the handshake, run from a pod in the same trust domain with network access to the target service:

curl -v https://service-b.internal.cluster.local/health

Expected check: the TLS certificate presented chains to the internal mesh CA rather than producing a verification error. Do not treat this as guaranteed output; confirm against your own CA configuration.

Observability is built in via metrics and traces for request latency and error rates across the topology. Performance overhead can accumulate with additional proxy hops in deep call chains, which is the trade-off against sidecar-based latency.

Start with a single trust domain, validate CA distribution between clusters, and monitor handshake errors before expanding canary weights.