Understanding Istio AuthN and authz for kubernetes Pods

Question

I am bit confused about using Istio with EKS. We have 2 spring boot microservices, one is a REST service provider and the other the consumer. We want to implement Authn and authz using Istio.

FOr that: 1. On provider service side : I have the a VirtualService, a Destination Rule (stating that the TLS mode should be ISTIO_MUTUAL for incoming traffic) , an AuthorizationPolicy which basically whitelists the client serviceaccounts. I also have a AuthenticationPolicy as below:

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: $APP_NAME-$FEATURE_NAME-authenticationpolicy
  namespace: $NAME_SPACE
spec:
  targets:
  - name: "$APP_NAME-$FEATURE_NAME"
  peers:
  - mtls:
      mode: STRICT

My understanding here is that this policy wont allow any incoming traffic which is non mtls.

Now I have a doubt that how do I configure my client pod to send all mtls outgoing traffic.I understand I have to create a ServiceAccount which is whitelisted at the provider side using Authz Policy.I am more concerned about my client pod here since I am not sure how to enable mtls at the pod level. FYI, I dont want to enable mtls at the namespace level.I want to do it at the pod level using a yaml file.

Is my understanding about the usage of the Destination rule, Authn and Authz policies correct? Is it correct that Destination rule, Authn and Authz policies have to be at the service provider level? And the client just has to enable MTLS for the communication to work successfully? I have been go thru Istio documentation but this is where I have a doubt

Answer 1

My understanding here is that this policy wont allow any incoming traffic which is non mtls.

That's true, if you set the tls mode to strict then client cert must be presented, connection is in TLS.

---

I am more concerned about my client pod here since I am not sure how to enable mtls at the pod level.

There is good article about how to make that work, specially the part

Setting up mTLS for a single connection between two services

As Bookinfo is the Hello World of Istio, I am going to use this to explain how to set up mTLS from productpage to details service as shown in the above graph snippet.

There are two parts to this:

Install a Policy to tell Details that it wants to receive TLS traffic (only):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: details-receive-tls
spec:
  targets:
  - name: details
  peers:
  - mtls: {}

2. Install a DestinationRule to tell clients (productpage) to talk TLS with details:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details-istio-mtls
spec:
  host: details.bookinfo.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

The following is a graphical representation of the involved services and where the previous two configuration documents apply.

Now when you look closely at the Policy above you will see and entry for the peer authentication

peers:
- mtls: {}

This means that TLS verification is strict and Istio (or rather the Envoy proxy in the pod) requires TLS traffic and a valid certificate. We can pass a flag to get permissive mode:

peers:
- mtls: 
    mode: PERMISSIVE

---

Is it correct that Destination rule, Authn and Authz policies have to be at the service provider level?

As far as I know yes.

And the client just has to enable MTLS for the communication to work successfully?

I'm not sure about that, since MTLS works inside mesh, it depends on your application requirements.

---

I want to do it at the pod level using a yaml file.

There is a link to istio documentation about authentication which include

• Create an HTTPS service with Istio sidecar with mutual TLS enabled
• Mutual TLS Deep-Dive

And another one from github

• Enable mtls for frontend service

Or you can extend your gateway's definition to support mutual TLS. Change the credentials of the ingress gateway by deleting its secret and creating a new one. The server uses the CA certificate to verify its clients, and we must use the name cacert to hold the CA certificate. You can use cert-manager to generate a client certificate.

• https://istio.io/docs/tasks/traffic-management/ingress/secure-ingress-sds/#configure-a-mutual-tls-ingress-gateway
• https://istio.io/docs/tasks/traffic-management/ingress/ingress-certmgr/

---

I have found some tutorials which might be helpful, check it out.

• Managing mutual TLS between services with Istio
• Authorization
• JWT
• istio mtls,jwt,authn

---

Let me know if you have any more questions.

Answer 2

Thanks JT97.This is what I have implemented

1) For authentication, I have implemented an Istio STRICT authn policy for incoming requests that will have to be MTLS enabled. Citadel should take care of identifying the client and service provider whether they are who they claim to be based on thier certificates.

2) For authorization, I have created a Service account in the client and added a authorization policy on the server side to whitelist only those service accounts that I want to use my REST resources( PUT POST etc)

3) The one thing I have configured differently is the destination rule. Ideally it should be at the client side where the client says I am declaring that my destination rule for provider destination is this.What I have done is declared the destination rule at the provider side so that it's communicated to the Istio mesh that it is ready with ISTIO_MUTUAL. Declaring the destination rule at the provider side doesn't make any difference in my opinion.

4.) I have declared the destination rule at the namespace level.Have to test now for clients coming in from outside the namespace but within the mesh.