Istio Authentication -Part 1


Istio is a service mesh for your microservices, which is designed for observability, routing, and resilience to traffic. It secures both north-south traffic and east-west traffic. North-south traffic is traffic entering (ingress) and exiting (egress) the service mesh. Istio handles north-south traffic through ingress and egress gateways, and traffic routing is managed by virtual services.

East-west traffic is traffic within the mesh, typically service-to-service. Istio’ s Envoy proxy manages east-west traffic, running as a sidecar in the Kubernetes pod of the service it is protecting.


There are two types of authentication provided by Istio.

  • Peer Authentication
    For service-to-service authentication.
  • Request Authentication
    For end-user authentication. Using JSON Web Tokens (JWT)

In this article we will be exploring Istio peer authentication .


  1. Cluster Environment created with EKS or KOPS
  2. Kubectl installed
  3. Istio installed
  4. Need Public key to access the cluster nodes
Service to Service — Workflow

The above diagram depicts the workflow of our sample microservice.

Deploy application into four different namespaces namely istio-servicea, istio-serviceb, servicec and istio-serviced.
* istio-servicea→ pods with manually injected istio sidecars
* istio-serviceb → pods with manually injected istio sidecars
* servicec → pods with no istio sidecar
* istio-serviced→ pods with manually injected istio sidecars

service-b,service-c,service-d running on different namespaces invoke service-a running on istio-servicea namespace.

Also service-e running on different namespaces invoke welcome-app running on istio-servicea namespace.

Create namespace

Verify that Namespace is created properly by executing the following command.

Side Car Injection

This will instruct Istio to automatically inject Envoy proxy when we deploy our application in the same namespace.

Deploy Services

# The YAML files required for this setup is available in the GitHUB repository
#You need to run the kubectl commands from within the folder where YAML files are present.
Or else please do provide the appropriate folder path while running the kubectl commands.

kubectl command — Application service

After deploying the application, we can see that Istio has added a sidecar for every pod created.

kubectl command — Application pods

To get the details of the container run the following command.

Now we will be able to see both application container as well as proxy container in our pod.

Before Peer Authentication

Both sidecar enabled and sidecar not enabled services can access all services where sidecar is enabled.

We used ClusterIP which is the simplest type, and default one in kubernetes cluster.
ClusterIP will not enable the application to be accessed from internet. So to run the application we need to login to the particular node where service is being deployed.

Use the public key to connect to the EKS cluster node and access the application using curl command as shown below.

Metrics — Before Peer Authentication

Namespace Level

Policy to allow mTLS traffic for all workloads under namespace istio-servicea.

Note: mTLS STRICT mode is enabled globally, for namespace istio-servicea.
Since servicec namespace has no sidecar, plain text is sent which is rejected by namespace istio-servicea.

Metrics — Istio Namespace Level

Workload Specific

Policies to allow both mTLS & plaintext traffic for all workloads under namespace istio-servicea, but require mTLS for workload service-a.

Metrics — Istio Workload Specific

Note: mTLS STRICT mode is enabled globally, for workload service-a running on namespace istio-servicea.
Except service-a all other workload running on this namespace can be accessed by both sidecar enabled and sidecar not enabled services running
on different namespaces.

Authorization Policy

Istio Authorization Policy enables access control on workloads in the mesh.

In our example, we have 2 services namely service-b and service-d running on namespace istio-service-b where side car is injected.
Both services can access service-a running on namespace istio-service-a where side car is enabled. In certain cases, we need particular service can access our workload, but all other services should not.
For that we need to enable Istio Authorization Policy .
In our case we allows requests from
service account “cluster.local/ns/istio-serviceb/sa/auth-test-sa”
to access the workload with “GET” method.

Specify service account in your deployment yaml file under spec section.

service-b enabled with Service Account
service-d where Service Account not enabled
Metrics — Istio Authorization Policy



Istio-Authorization Policy


We have now successfully enabled Istio PeerAuthentication for our application , we will see how to implement Request Authentication for external request in next article.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store