Disabling mTLS for one namespace with Istio PeerAuthentications

Istio 1.5 introduced a set of new objects for dealing with Authentication: PeerAuthentication and RequestAuthentication. These objects replaced the old Policy objects (removed in Istio 1.6).

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:

Service mesh with mTLS enabled at mesh level

In terms of configuration, it means that you already have a PeerAuthentication that looks like this one:

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

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:

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "bookinfo"
spec:
  mtls:
    mode: DISABLE

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:

Create Istio Objects from the console

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 tls field.

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.

51% of last minute request used mTLS

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.

If you like what you saw and you want to try it, you can quickly install Kiali. I am sure you will also enjoy our runtime metrics, custom dashboards, correlation of metrics and tracing as well as troubleshooting your Istio configuration files.