Chapter 9. Enabling mutual Transport Layer Security


You can use Red Hat OpenShift Service Mesh for your application to customize the communication security between the complex array of microservices. Mutual Transport Layer Security (mTLS) is a protocol that enables two parties to authenticate each other.

9.1. About mutual Transport Layer Security (mTLS)

In OpenShift Service Mesh 3, you use the Istio resource instead of the ServiceMeshControlPlane resource to configure mTLS settings.

In OpenShift Service Mesh 3, you configure STRICT mTLS mode by using the PeerAuthentication and DestinationRule resources. You set TLS protocol versions through Istio Workload Minimum TLS Version Configuration.

Review the following Istio resources and concepts to configure mTLS settings properly:

PeerAuthentication
defines the type of mTLS traffic a sidecar accepts. PERMISSIVE mode allows both plain text and mTLS traffic. STRICT mode requires mTLS for all incoming traffic..
DestinationRule
configures the type of TLS traffic a sidecar sends. In DISABLE mode, the sidecar sends plain text. In SIMPLE, MUTUAL, and ISTIO_MUTUAL modes, the sidecar establishes a TLS connection.
Auto mTLS
ensures the mesh uses mTLS by default to encrypt all inter-mesh traffic, regardless of the PeerAuthentication mode configuration. The enableAutoMtls global mesh configuration field controls Auto mTLS, which OpenShift Service Mesh 2 and 3 enable by default. The mTLS setting operates entirely between sidecar proxies, requiring no changes to application or service code.

By default, PeerAuthentication uses PERMISSIVE mode, allowing sidecars in the Service Mesh to accept both plain text and mTLS-encrypted traffic.

You can restrict workloads to accept only encrypted mTLS traffic by enabling the STRICT mode in PeerAuthentication.

You can see the following example configuration for reference:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: <namespace>
spec:
  mtls:
    mode: STRICT

You can enable mTLS for all destination hosts in the <namespace> by creating a DestinationRule resource with MUTUAL or ISTIO_MUTUAL mode if you disable auto mTLS and apply STRICT mode to PeerAuthentication.

You can see the following example configuration for reference:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: enable-mtls
  namespace: <namespace>
spec:
  host: "*.<namespace>.svc.cluster.local"
  trafficPolicy:
   tls:
    mode: ISTIO_MUTUAL

You can configure mTLS across the entire mesh by applying the PeerAuthentication policy to the istiod namespace, such as istio-system. The istiod namespace name must match to the spec.namespace field of your Istio resource.

You can see the following example configuration for reference:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Additionally, create a DestinationRule resource to disable mTLS for communication with the API server, as it does not have a sidecar. Apply similar DestinationRule configurations for other services without sidecars.

You can see the following example configuration for reference:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-server
  namespace: istio-system
spec:
  host: kubernetes.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE

9.4. Validating encryptions with Kiali

The Kiali console offers several ways to validate whether or not your applications, services, and workloads have Mutual Transport Layer Security (mTLS) encryption enabled.

The Services Detail Overview page displays a Security icon on the graph edges where at least one request with mTLS enabled is present. Also note that Kiali displays a lock icon in the Network section next to ports that use mTLS configuration.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top