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

Security
1

Hello,

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?

2

@YangminZhu can you take a look? Thanks.

1 Like
3

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

4

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. https://istio.io/v1.3/docs/tasks/security/https-overlay/ You can follow this instruction and see if there’s any issue.