MTLSPolicyConflict
This message is deprecated and only produced on service meshes that are using alpha authentication policy.
Consider an Istio mesh with the following mesh policy:
In this example, you can fix the issue in one of two ways: you could downgrade the mesh policy’s mutual TLS requirements to accept plaintext traffic (which might include removing the mesh policy entirely), or you can create a corresponding destination rule that specifies to use mutual TLS for traffic within the mesh:
To effectively resolve mutual TLS conflicts, it’s helpful to understand how both destination rules and policies affect traffic to a service. Consider an example service named in namespace my-namespace
. To determine which policy object is applied to my-service
, the following resources are matched in order:
- A policy resource in namespace
my-namespace
that contains atarget
specifyingmy-service
. - A mesh policy resource named
default
.
- A destination rule in namespace
other-namespace
that specifies a host that matches . This may be an exact match or a wildcard match. Also note that theexportTo
field, which controls the visibility of configuration resources, will effectively be ignored as resources within the same namespace as the source service are always visible. - A destination rule in namespace
my-namespace
that specifies a host that matchesmy-service.my-namespace.svc.cluster.local
. This may be an exact match or a wildcard match. Note that theexportTo
field must specify that this resource is public (e.g. it has the value"*"
or is not specified) in order for a match to occur. - A destination rule in the “root namespace” (which is, by default,
istio-system
) that matchesmy-service.my-namespace.svc.cluster.local
. The root namespace is controlled by therootNamespace
property in the . Note that theexportTo
field must specify that this resource is public (e.g. it has the value"*"
or is not specified) in order for a match to occur.
Finally, be aware that Istio doesn’t apply any concept of inheritance when following these rules. The first resources that matches the specified criteria is used.
Look at the output of the message. You should see something like:
- Destination rule resource , which is requiring mutual TLS when sending traffic to host
myhost.my-namespace.svc.cluster.local:8080
You can fix the conflict by doing one of the following:
- Modifying policy resource
my-namespace/my-policy
to require mutual TLS as an authentication mode. In general this is done by adding apeers
attribute to the resource with a child ofmtls
. You can read more about how this is achieved on the reference page for policy objects. - Modifying destination rule
istio-system/default-rule
to not use mutual TLS by removing theISTIO_MUTUAL
traffic policy. Note thatdefault-rule
is in theistio-system
namespace - by default, theistio-system
namespace is considered the “root namespace” for configuration (although this can be overridden via therootNamespace
property in the . That means that this destination rule potentially affects all other services in the mesh. - Add a new destination rule in the same namespace as the service (in this case, namespace
my-namespace
), and do not specify a traffic policy of . Because this rule is located in the same namespace as the service, it will override the global destination ruleistio-system/default-rule
.