MTLSPolicyConflict
This message occurs when a destination rule resource and a policy resource are in conflict with regards to mutual TLS. The two resources are in conflict if they each specify incompatible mutual TLS modes to be used; this conflict means traffic matching the destination rule to the specified host will be rejected.
This message is only produced on service meshes that are not using automatic mutual TLS.
An example
Consider an Istio mesh with the following mesh policy:
apiVersion: authentication.istio.io/v1alpha1
kind: MeshPolicy
metadata:
name: default
spec:
peers:
- mtls: {}
The effect of this policy resource is that all services have an authentication policy requiring mutual TLS to be used. However, note that without a corresponding destination rule requiring traffic to use mutual TLS, traffic will be sent to services without using mutual TLS. This conflict means that traffic destined for services in the mesh will ultimately fail.
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:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mtls-for-cluster
spec:
host: *.svc.cluster.local
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
Which destination rules and policies are relevant to a service
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 my-service
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 policy resource named
default
in namespacemy-namespace
that does not contain atarget
. This policy implicitly applies to the entire namespace. - A mesh policy resource named
default
.
To determine which destination rules are applied to traffic sent to
my-service
, we must first know which namespace the traffic originates from.
For the sake of this example, let’s call that namespace other-namespace
.
Destination rules are matched in the following order:
- A destination rule in namespace
other-namespace
that specifies a host that matchesmy-service.my-namespace.svc.cluster.local
. 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 theMeshConfig
resource. 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.
How to resolve
Look at the output of the message. You should see something like:
Error [IST0113] (DestinationRule default-rule.istio-system) A DestinationRule
and Policy are in conflict with regards to mTLS for host
myhost.my-namespace.svc.cluster.local:8080. The DestinationRule
"istio-system/default-rule" specifies that mTLS must be true but the Policy
object "my-namespace/my-policy" specifies Plaintext.
Contained in this message are the two resources that are in conflict:
- Policy resource
my-namespace/my-policy
, which is specifying ‘Plaintext’ as its supported mutual TLS mode. - Destination rule resource
istio-system/default-rule
, which is requiring mutual TLS when sending traffic to hostmyhost.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 theMeshConfig
resource. 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 ofISTIO_MUTUAL
. Because this rule is located in the same namespace as the service, it will override the global destination ruleistio-system/default-rule
.