TIS0502 - Namespace-Wide DestinationRule Disabling mTLS is Missing

A DestinationRule disabling namespace-wide mTLS is missing.

Recommendation: Ensure Correct DestinationRule and PeerAuthentication for mTLS

To prevent unintended secure communication, either add a DestinationRule disabling mTLS at the namespace level or update PeerAuthentication to a compatible mode (STRICT or PERMISSIVE) to allow proper connectivity between services.

Examples

1. No Namespace-Wide DestinationRule Configured to Disable mTLS

   # No namespace-wide `DestinationRule` disabling mTLS present in the namespace configuration

   Explanation: Without a DestinationRule explicitly disabling mTLS, services in the namespace may inadvertently attempt to use mTLS for communication, causing connectivity issues if the workloads are not prepared for secure communication.

Recommendation

Change the namespace/mesh-wide DestinationRule to DISABLE mode or update the PeerAuthentication to allow mTLS with STRICT or PERMISSIVE mode.

1. Add Namespace-Wide DestinationRule to Disable mTLS

   Create a DestinationRule in the target namespace to explicitly disable mTLS, ensuring that services communicate in plaintext.

   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: namespace-disable-mtls
     namespace: example-namespace
   spec:
     host: "*.example-namespace.svc.cluster.local"
     trafficPolicy:
       tls:
         mode: DISABLE

   Explanation: This DestinationRule ensures that mTLS is disabled for all services within the example-namespace, allowing them to communicate in plaintext.

2. Update PeerAuthentication to Allow mTLS

   If the intention is to support both mTLS and plaintext communication, update the PeerAuthentication to use PERMISSIVE mode.

   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: permissive-peer-auth
     namespace: example-namespace
   spec:
     mtls:
       mode: PERMISSIVE

   Explanation: Setting the PeerAuthentication mode to PERMISSIVE allows services to accept both mTLS and plaintext connections, making the communication flexible depending on the client capabilities.