The goal of this post is to show how to disable mTLS for a specific namespace using these new objects. If you use Policy objects instead, find out how to approach it here.
Imagine you have a cluster that has mTLS enabled at mesh level:
In terms of configuration, it means that you already have a PeerAuthentication that looks like this one:
This ensures that all workloads in the mesh accept only mTLS communications. In other words, plain communication is not allowed between workloads in the mesh. However, workloads outside the mesh will still be called without mTLS.
Note that by applying the previous PeerAuthentication you are changing the behavior of workloads of the whole service mesh. It is a mesh-wide configuration that will effect workloads beyond this namespace.
I want to disable mTLS for one namespace, what should I do?
The way to achieve this is just as simple as applying a PeerAuthentication in the specific namespace with the
mtls mode set to
DISABLE . It should look like this one:
By applying this rule into the
bookinfo namespace, you are only changing the authentication methods to the workloads in that namespace. Setting the
DISABLE method will configure sidecars to receive only plain communications.
Istio (+v1.5) default installations use the
AutoMtls feature that will enable/disable mTLS depending on the destination workload. Therefore, there is no need to create a Destination Rule to enforce workloads to disable mTLS.
What if I have a workload without a sidecar (not in the mesh) in this namespace? Not a single problem while they use plain communications.
In case you don’t have the terminal nearby, let’s create this PeerAuthentication object from Kiali itself. See how:
Warning here: if you already have a Destination Rule with the
trafficPolicy set to use
mode: ISTIO_MUTUAL it is time to set it back to
DISABLE or simply remove the whole
Once all of this is fixed, you will be able to see the traffic flowing without mTLS. Let’s see how our application transitioned from mTLS to plain traffic, plus, see how I made a mistake and kept mTLS for one service:
In more detail, the three red arrows below will show you the mTLS status of each component in your mesh.
The open lock in the edges shows that either part or all of the traffic is unencrypted (not using mTLS). The traffic observed in the graph still have both mTLS and plain traffic for the last minute. The exact amount of mTLS traffic is displayed in the right hand side panel.
After some time, the whole traffic in the namespace will be shifted to plain communications so you’ll see that no mTLS is observed in the graph.