#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.

• Navigate to the Services Detail Overview page.
• A lock icon is displayed on graph edges where mTLS is active.
• In the Network section of the UI, mTLS-enabled ports are also marked with a lock icon.