PeerAuthentication Strict does not appear to be working

Security
1

Hi,
I have the following peerauthentication using istio 1.7.3. It is in the istio-system namespace

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

I have the following pods in ns foo1

NAME                                   READY   STATUS    RESTARTS   AGE
sleep-7bcd6c9698-ksc4z                 2/2     Running   0          2d4h
sleep-linux-bd846f6f6-sl8sm            2/2     Running   0          2d3h
springboot-5f47dfdf48-wbc7v            1/1     Running   0          15m
springboot-external-77687fdcb7-lq76g   2/2     Running   0          25m

And services

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
sleep                 ClusterIP   10.96.56.153    <none>        80/TCP     2d4h
sleep-linux           ClusterIP   10.96.173.104   <none>        80/TCP     2d3h
springboot            ClusterIP   10.96.53.223    <none>        8080/TCP   23m
springboot-external   ClusterIP   10.96.106.7     <none>        8000/TCP   33m

Note that springboot has no Envoy
springboot-external calls springboot. I would have expected that call to fail due to strict MTLS but it doesn’t. it works perfectly

Accessing Url http://springboot.foo1:8080/
Http Call returned 200

Is this a bug or my misunderstanding of how this works?

Tnx
Doug

Part 2
Part of my misunderstanding was i was applying 1.4.6 behavior to 1.7.3
In 1.4.6, I had to create a destination rule to allow outbound calls to non proxied services but allow seems to be the default behavior in 1.7.3 ( which is easier imo )

2

@incfly - would you have an idea regarding what the expected behavior is? The task on the Istio website indicates that when mTLS is enforced through PeerAuthentication, http (non-TLS) communication initiated from native workloads (non-Istio) to Istio-workloads will fail. It says nothing about http communication initiated from istio-workloads to native workloads. For the record, when I try it on my cluster, I see the same behavior as mentioned above - http communication from istio-workload to non-istio workload goes through fine which seems counter-intuitive.

3

I tested this scenario in 1.4.6 and the call to the non-Istio workload fails with 503 which is diff than 1.7.3
To make the call work, I had to add a destination rule as doc’d in 1.4.6

Similar to this

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: "httpbin-legacy"
 namespace: "legacy"
spec:
 host: "httpbin.legacy.svc.cluster.local"
 trafficPolicy:
   tls:
     mode: DISABLE
EOF

Anyhow, behavior is def different between 1.7.3 and 1.4.6

4

Expected behavior as I understand correctly.

istio workloads → non sidecar workloads.

include and before 1.4, you enable mesh wide mtls via DestinationRule. Istio calls non sidecar also are affectd by that configuration. So istio client envoy send mTLS traffic, to non sidecar server, fails as expected.

from 1.5 and newer release, auto mTLS is enabled by default. Istio automatically detects the remote server side does not have envoy sidecar. Therefore, when you don’t have destinationrule for that service, Istio use plain text by default. which makes you see 200.

5

Thanks for the clarification. I was working off of behavior of 1.4.6

I think STRICT is what threw me. In my mind, that would mean “must” and since its mutual, on both sides. That’s why I found it surprising that the default was to make the communication less secure.

Regards
Doug

6

Due to your services use all mTLS and plaintext traffic so you need to set mTLS mode is PERMISSIVE.
You can refer istio doc as bellow: