How to enable automatic mTLS using istio mesh in AWS EKS?

2
votes

I have recently started learning and implementing istio in AWS EKS cluster. For configuring TLS for ingress gateway, I followed this guide which simply asks you to add AWS ACM ARN id to istio-ingressgateway as an annotation. So, I had to neither use certs to create secret nor use envoyproxy's SDS.

This setup terminates TLS at gateway, but I also want to enable mTLS within mesh for securing service-service communication. By following their documentation, I created this policy to enforce mTLS within a namespace:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: xyz-mtls-policy
  namespace: xyz-dev
spec:
  mtls:
    mode: STRICT

But even after applying this, I see one service being able to call another service using http.

So my question is: how do I use the ACM certs to implement mTLS in my namespace?

1
securitykubernetesistioamazon-eksaws-certificate-manager
You're calling from inside or outside the mesh? If it's inside the mesh then I would say it's working fine, take a look here. Additionally take a look here. – Jakub
calling from inside the mesh. I did refer this article earlier, but could not figure out how to check that connection_security_policy metric. Finally was able to check from prometheus and it is set to mutual_tls even though I have not applied the above policy. I am on istio 1.6.8, think it enables mTLS by default. Is there any clear process to prove that it is indeed using mTLS? – Grimlock
I have answered all your questions in the answer. – Jakub

1 Answers

1
votes

If you're calling from inside the mesh I would say it's working fine, take a look here and here.

Mutual TLS in Istio

Istio offers mutual TLS as a solution for service-to-service authentication.

Istio uses the sidecar pattern, meaning that each application container has a sidecar Envoy proxy container running beside it in the same pod.

  • When a service receives or sends network traffic, the traffic always goes through the Envoy proxies first.

  • When mTLS is enabled between two services, the client side and server side Envoy proxies verify each other’s identities before sending requests.

  • If the verification is successful, then the client-side proxy encrypts the traffic, and sends it to the server-side proxy.

  • The server-side proxy decrypts the traffic and forwards it locally to the actual destination service.

enter image description here

I am on istio 1.6.8, think it enables mTLS by default.

Yes, it's enabled by default since istio 1.5 version. There are related docs about this.

Automatic mutual TLS is now enabled by default. Traffic between sidecars is automatically configured as mutual TLS. You can disable this explicitly if you worry about the encryption overhead by adding the option -- set values.global.mtls.auto=false during install. For more details, refer to automatic mutual TLS.

Is there any clear process to prove that it is indeed using mTLS?

I would say there are 3 ways

  • Test with pods

You can change it from strict to permissive and call it from outside the mesh, it should work. Then change it to strict and call it again, it shouldn't work. In both ways you should be able to call it from a pod inside the mesh.

  • Kiali

If you want to see it visual way kiali should have something like a padlock when mtls is enabled, there is github issue about that.

enter image description here enter image description here

  • Prometheus

It was already mentioned in the banzaicloud, and you mentioned that in the comments, you can check the Connection Security Policy metric label. Istio sets this label to mutual_tls if the request has actually been encrypted.

Let me know if have any more questions.