Istio DISABLE PeerAuthentication on workloads

Networking
1

I’m using Istio v1.9.3 to enforce a STRICT mTLS policy across my entire mesh. For one particular clustered workload, I’d like to disable mTLS communication entirely. According to the docs, I should be able to target the cluster pods and override the default mode with something like this:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: my-cluster
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: cluster-tech
      app.kubernetes.io/instance: my-cluster
  mtls:
    mode: DISABLE

Unfortunately, this breaks the internal communication between the cluster pods and I end up seeing a long string of istio-proxy log entries like the following:

example-cluster-worker-0 istio-proxy [2021-04-27T17:33:44.226Z] "- - -" 0 UF,URX - - "-" 0 0 0 - "-" "-" "-" "-" "127.0.0.1:2385" inbound|2385|| - 10.244.223.60:2385 192.168.64.30:51622 - -

Here comes the weird part: if I create this policy at the namespace level, then communication works properly.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: ns-policy
  namespace: default
spec:
  mtls:
    mode: DISABLE

I guess I have a couple of questions:

  1. Is applying a DISABLE policy at the workload level support, or only at the namespace and mesh levels?
  2. Am I missing some other, required configuration that has to accompany this resource?
  3. Is this is unexpected behavior, would you like me to submit a bug in GitHub?
2

AFAIK, 1) There is no exemption for this. 2) Don’t think there is any additional configuration. Are the matchLabels defined correctly? 3) Sounds like the correct thing to do.
A few questions - are all workloads in the namespace default, and not in any other namespace? Also, are you combining the PeerAuthenticationPolicy with some kind of DestinationRule? IIUC, PeerAuthenticationPolicies only define how to authenticate connection requests. To direct Istio Agents to not use mTLS in the first place, a DestinationRule needs to be applied.
Otherwise, you have an authentication policy that tells workloads not to accept mutual mTLS connections, but agents are still attempting to connect to them with mTLS (default behavior after 1.4)