Este contenido no está disponible en el idioma seleccionado.
Chapter 10. 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.
10.1. About mutual Transport Layer Security (mTLS) Copiar enlaceEnlace copiado en el portapapeles!
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. In
PERMISSIVE
mode, both plaintext and mTLS traffic are accepted. InSTRICT
mode, only mTLS traffic is allowed. DestinationRule
-
configures the type of TLS traffic a sidecar sends. In
DISABLE
mode, the sidecar sends plaintext. InSIMPLE
,MUTUAL
, andISTIO_MUTUAL
modes, the sidecar establishes a TLS connection. Auto mTLS
-
ensures that all inter-mesh traffic is encrypted with mTLS by default, regardless of the
PeerAuthentication
mode configuration.Auto mTLS
is controlled by the global mesh configuration fieldenableAutoMtls
, which is enabled by default in OpenShift Service Mesh 2 and 3. The mTLS setting operates entirely between sidecar proxies, requiring no changes to application or service code.
By default, PeerAuthentication
is set to PERMISSIVE
mode, allowing sidecars in the Service Mesh to accept both plain-text and mTLS-encrypted traffic.
10.2. Enabling strict mTLS mode by using the namespace Copiar enlaceEnlace copiado en el portapapeles!
You can restrict workloads to accept only encrypted mTLS traffic by enabling the STRICT
mode in PeerAuthentication
.
Example PeerAuthentication
policy for a namespace
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
10.3. Enabling strict mTLS across the whole service mesh Copiar enlaceEnlace copiado en el portapapeles!
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.
Example PeerAuthentication
policy for the whole mesh
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
10.4. Validating encryptions with Kiali Copiar enlaceEnlace copiado en el portapapeles!
The Kiali console offers several ways to validate whether or not your applications, services, and workloads have 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 are configured for mTLS.