MeshPolicy already exists with mtls in namespace where istio-injection=enabled

[Baykonur]

After I do draft connect I cannot see with tcpdump 'Istio' before applying the Policy as stated in Transparent mutual TLS, I am guessing because there is already MeshPolicy in that namespace comes with istio installation?

kubectl get MeshPolicy -o yaml
apiVersion: v1
items:
- apiVersion: authentication.istio.io/v1alpha1
  kind: MeshPolicy
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"authentication.istio.io/v1alpha1","kind":"MeshPolicy","metadata":{"annotations":{},"clusterName":"","creationTimestamp":"2018-11-14T20:56:36Z","labels":{"app":"istio-security","chart":"security-1.0.3","heritage":"Tiller","release":"istio"},"name":"default","resourceVersion":"265255","selfLink":"/apis/authentication.istio.io/v1alpha1/default","uid":"c6c4c648-e84f-11e8-a343-080027cc8089"},"spec":{"peers":[{"mtls":{}}]}}
    clusterName: ""
    creationTimestamp: 2018-11-15T20:32:35Z
    labels:
      app: istio-security
      chart: security-1.0.3
      heritage: Tiller
      release: istio
    name: default
    resourceVersion: "282209"
    selfLink: /apis/authentication.istio.io/v1alpha1/default
    uid: 962ad446-e915-11e8-9dd8-080027cc8089
  spec:
    peers:
    - mtls: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Strange enough if I access frontend-app via ambassador annotated service then I can capture 'Istio' with tcpdump before and after applying the Policy...

If I remove the default MeshPolicy then I cannot access at all the Frontend

[pipo02mix]

If I remove the default MeshPolicy then I cannot access at all the Frontend

But did you apply the policy file?

Anyway traffic from ingress to the frontend is not encrypted with these policies but the one going from frontend to backend. To check if mutualTLS is well configured run

$ istioctl authn tls-check backend-app.default.svc.cluster.local

And in case you apply the policies you should see

HOST:PORT           STATUS     SERVER     CLIENT     AUTHN POLICY            DESTINATION RULE
backend-app...:80     OK        mTLS       mTLS     backend-app/default     backend-rule/default

[pipo02mix]

BTW I have discovered istio run a job to apply the default mesh policy when you install it. So it sets permissive which can work with and without SSL encrypted connections. This mode it is meant for making the transition between services with sidecar and without sidecar, so even if a service not in the mesh call a service running in the mesh it will work. But if both services are in the mesh it will encrypt the communication

[Baykonur]

OK it seems the way you deploy istio (yaml, helm or helm-tiller) changes the way how the default mesh policy is applied, which is interesting and requires explanation from istio. I have just removed all (frontend-backend and istio) and deployed istio using Option 2: Install with Helm and Tiller via helm install and now I have the PERMISSIVE mesh policy, during the workshop I had with mTLS where I used yaml files to deploy istio.

First thing I will do on Monday to check how we deployed istio on our Dev cluster at work... I think this issue can be closed, thanks for the workshop.