Is it possible that an identical PeerAuthentication could result in two different network environments?


I’m in the middle of upgrading istio from 1.5.4 to 1.6.1 on my private environment and I found something weird.
I had a workload set that had been working properly with istio 1.5.4.
However, once I applied the version 1.6.1 into it as canary, it no longer works appropriately.
I tried to adjust a namespace-wide PeerAuthentication with Permissive type to the workload set and I found that it worked differently with those versions. It worked worked with 1.5.4 perfectly but it didn’t with 1.6.4.
So I additionally tested it with another tls mode ‘Disable’ with the same namespace-wide PeerAuthentication, then it worked in both of versions obviously.

Speaking with more details,

  1. there had been no PeerAuthentication affecting to it before I applied the PeerAuthentication.
  2. It has the top priority of authentication policy in my workload set as there is no other one.
  3. I think it is the most important and interesting point that every workload in it communicates with each other through ssl mode.

Honestly, I think that it is normal that it doesn’t work with permissive mode due to #3 on both of versions, however, it works with permissive mode of version 1.5.4.
Could anyone let me know why it works differently?

@YangminZhu can you take a look? Thanks.

1 Like

seems some difference of auto mTLS in 1.5 and 1.6? cc @incfly for further look.

1.5 to 1.6 change to make auto mTLS enabled by default, so the client workloads start to send mTLS traffic.

However, the real issue seems to be is: your client and server won’t work with Istio mTLS anyway. You can try at 1.5 with STRICT && DestinationRule.ISTIO_MUTUAL see if it works or not.

We support https over Istio mTLS. You can follow this instruction and see if there’s any issue.