Mutual TLS

TLS authentication overview

Istio offers mutual TLS as a solution for service-to-service authentication.

Note: For FIPS-compliant TLS settings, see FIPS-compliant service mesh.

Istio uses the sidecar pattern, meaning that each application container has a sidecar Envoy proxy container running beside it in the same pod.

  1. When a service receives or sends network traffic, the traffic always goes through the Envoy proxies first.
  2. When mTLS is enabled between two services, the client side and server side Envoy proxies verify each other’s identities before sending requests.
  3. If the verification is successful, then the client-side proxy encrypts the traffic, and sends it to the server-side proxy.
  4. The server-side proxy decrypts the traffic and forwards it locally to the actual destination service.

isito-mtls isito-mtls

In Service Mesh Manager, you can manage mTLS settings between services on the UI, mesh-wide, namespace-wide, and on the service-specific level.

Change mTLS settings using the UI

  • To configure service-specific mTLS settings, select the service on the MENU > TOPOLOGY or MENU > SERVICES page, then select MTLS POLICIES. You can configure the MTLS policy you want to use independently for each port of the service. The following policies are available:

    • STRICT: The service can accept only mutual TLS traffic.
    • PERMISSIVE: The service can accept both plaintext/unencrypted traffic and mutual TLS traffic at the same time.
    • DISABLED: The service can accept plaintext/unencrypted traffic only.
    • DEFAULT: Use the global MTLS policy.

    mtls-set mtls-set

    When a load is sent to the service, you can easily verify whether the traffic between your services is actually encrypted or not by selecting EDGE LABELS > security. Either red open locks or green closed ones are displayed between the services in the UI, indicating that encrypted or non-encrypted data has been sent between the services.