Strict Client mTLS

Concept

By default, when auto mTLS is enabled (trafficMode: REQUIRED), an Istio sidecar originates a connection to a mesh-internal upstream using mTLS. If the sidecar cannot confirm the destination is mesh-managed — for example, because the destination isn't injected, or because service discovery hasn't yet converged across clusters — it falls back to plaintext rather than failing the connection.

strictClientMtls closes that fallback. When enabled, sidecars always originate connections to mesh-internal upstreams using ISTIO_MUTUAL, regardless of whether a matching mTLS policy has been discovered for the destination. Any destination that cannot terminate mTLS will simply reject the connection, rather than silently falling back to plaintext.

Enabling strictClientMtls also changes how XCP Edge implements authentication.trafficMode: REQUIRED. Previously, XCP Edge enforced REQUIRED by generating an explicit tls: ISTIO_MUTUAL DestinationRule for every host that needed it. In large meshes this doesn't scale: enforcing mTLS on even a single service in a workspace spanning hundreds of namespaces can generate a DestinationRule per namespace, adding significant load to XCP Edge and istiod as the mesh grows. With strictClientMtls enabled, strict origination is already the client-side default, so XCP Edge stops generating those per-host rules — eliminating the DestinationRule growth without requiring you to micromanage enforcement namespace by namespace.

Non-injected and plaintext-only workloads fail closed

Once strictClientMtls is enabled, any workload that cannot accept mTLS — such as a non-injected pod, or a service that intentionally only speaks plaintext — will fail to receive traffic from mesh clients, since sidecars no longer fall back to plaintext for unrecognized destinations.

If you have workloads that must remain reachable over plaintext, exempt them by setting authentication.trafficMode: OPTIONAL for those hosts. This causes XCP Edge to emit a tls: DISABLE DestinationRule for them, opting them out of strict client mTLS.

Enabling strict client mTLS

strictClientMtls is set on the Istio component of an Istio revision, under isolationBoundaries, in the ControlPlane custom resource:

spec:
  components:
    xcp:
      isolationBoundaries:
        - name: global
          revisions:
            - name: default
              istio:
                strictClientMtls: true

Because the setting is scoped to a single Istio revision, it can be rolled out incrementally — for example, enabled first on a canary revision to validate the change before applying it to default. See Istio Isolation Boundaries for background on revisions and isolation boundaries.