#Enabling mutual Transport Layer Security

Alauda Service Mesh supports configuring secure communication between services using Mutual Transport Layer Security (mTLS), a protocol that ensures mutual authentication between service clients and servers.

#About mutual Transport Layer Security (mTLS)

In Alauda Service Mesh, mTLS settings can be configured using the Istio resource.

STRICT mTLS mode can be configured using the PeerAuthentication and DestinationRule resources.

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

• PeerAuthentication Defines the mTLS mode accepted by sidecar proxies.

  • PERMISSIVE: Accepts both plaintext and mTLS traffic.
  • STRICT: Only mTLS traffic is accepted.

• DestinationRule Defines the TLS mode used for traffic sent from sidecar proxies.

  • DISABLE: Sends plaintext traffic.
  • SIMPLE, MUTUAL, ISTIO_MUTUAL: Sends traffic using TLS.

• Auto mTLS Automatically enables mTLS for inter-mesh communication, regardless of the PeerAuthentication mode. This feature is controlled by the enableAutoMtls field in the mesh configuration and is enabled by default. Auto mTLS operates at the proxy level and requires no changes to application code.

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

#Enabling strict mTLS mode by using the namespace

You can enforce strict mTLS mode for all workloads in a specific namespace by applying a PeerAuthentication policy.

Example PeerAuthentication policy for a namespace

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 when auto mTLS is disabled and PeerAuthentication is set to STRICT mode.

Example DestinationRule policy for a namespace

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

#Enabling strict mTLS across the whole service mesh

You can enforce strict mTLS cluster-wide by applying a PeerAuthentication policy in the control plane namespace (e.g., istio-system). The namespace must match the value of the spec.namespace field in the Istio resource.

Example PeerAuthentication policy for the whole mesh

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.

Example DestinationRule policy for the whole mesh

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

#Validating encryptions with Kiali

The Kiali console offers several ways to validate whether or not your applications, services, and workloads have mTLS encryption enabled.

• On the Traffic Graph page, select Display > Security to show a lock icon on every edge that carries mTLS traffic.
• On the Namespaces page, the mTLS column reports the mode of each namespace, such as Strict, Permissive, or Disabled. The namespace detail page reports the same value in its mTLS field. Hover over the lock icon to see whether the mode is set on the namespace or inherited from the mesh-wide configuration.
• On the Mesh page, select the control plane node to read the mesh-wide mTLS status in its side panel.