Microservices Authentication In Action with Service Mesh

Context

Microservices architecture is the most famous pattern in the Software Architecture today, there are many articles on the internet that tries to explain the benefits and drawbacks present in this architecture style.

I’ve got a couple of years working with microservices and, for me, the most problematic part is related to apply security in this scenario. There are many patterns and tools which try to solve it, most part of them is related to the languages and framework.

That way we have a sort of problems because we need to apply security in the “Software” layer and it might cause problems like:

  • Incorrect implementation by developers
  • Different implementation because of the frameworks “implies” their own patterns like Spring Security or Apache Shiro
  • Usually, languages imply their own patterns as well
  • Add certificates in the application layer add some extra complexity to managing these certificates
  • The framework should support certificate configuration
  • Security implemented with different patterns in the Solution
  • Developers don’t know the security standards in-depth it causes some security leaks.

Security is a non-functional requirement and in the most part of the companies, there is a specific area which will define standards and manage security in the whole ecosystem. It means define network firewalls, network privileges and so on.

We need to find a way to create a standard for security in our microservice solution. ISTIO a Service Mesh implementation can help us adding security in the platform (a.k.a kubernetes) in an easy way.

Let’s understand that!!!

Istio Service Mesh Implementation

The explanation about Istio is out of scope in this blog post. If you need some explanations about you can find it in my previous article.

Authentication types in ISTIO

Istio offers two types of authentication. The first one targets the end-users and the second one aims the service-to-service authentication with certificates, we will understand a little deeper about these two models.

End-User Authentication

This feature aims to authenticate the end-user, it means a person who is trying to access our system or a simple device or application which is trying to access our solution.

Istio enables request level authentication through the JWT specification, the most used security specification for cloud-native applications. Also, Istio enables simple integration with OpenId-Connect specification, another relevant standard for security.

With a couple of configurations like JWT Issuer, JWKS URI, and some paths to include and exclude we are able to protect our microservices with OAuth authentication flow.

It is configured by yaml files which one is very simple and intuitive.

Service-to-Service Authentication

This kind of authentication sometimes is called transport authentication, it will verify the client connection to check the communication. Istio offers mtls as a full-stack solution for transport authentication.

Citadel it the component that will provide the digital certificates based on SPIFFE standards for each sidecar a.k.a envoy proxies present in the Data Plane.

In the next sections, I’ll explain how it works in the configuration time and runtime authentication execution. Let’s do it!!!!

Configuration Flow

Let’s understand how the Citadel component distributes digital certificates for each pod present in the Data Plane.

The following steps describe these interactions:

  • Citadel watches the Kubernetes API server, creates a SPIFFE certificate and key pair for each of the existing and new service accounts. Citadel stores the certificate and key pairs as Kubernetes secrets.
  • When you create a pod, Kubernetes mounts the certificate and key pair to the pod according to its service account via Kubernetes secret volume.
  • Citadel watches the lifetime of each certificate and automatically rotates the certificates by rewriting the Kubernetes secrets.
  • Pilot generates secure naming information, which defines what service account or accounts can run a certain service. The pilot then passes the secure naming information to the sidecar Envoy.

As we can see in the steps above, the digital certificates are fully managed by Citadel component in the Istio Infrastructure.

That is very important because it makes de digital certificates easy to management and a centralized point to act in the case is something wrong with certificates.

Authentication Flow in Data Plane

The service-to-service authorization flow follows the steps below:

  • Istio re-routes the outbound traffic from a client to the client’s local sidecar Envoy.
  • The client-side Envoy starts a mutual TLS handshake with the server-side Envoy. During the handshake, the client-side Envoy also does a secure naming check to verify that the service account presented in the server certificate is authorized to run the target service.
  • The client-side Envoy and the server-side Envoy establish a mutual TLS connection, and Istio forwards the traffic from the client-side Envoy to the server-side Envoy.
  • After authorization, the server-side Envoy forwards the traffic to the server service through local TCP connections.

As we can see the flow is strongly based in envoy (sidecar) features.

Conclusions

In this post, I tried to explain a little bit about microservices authentication with Istio.

As we can see it makes our security configuration in a centralized point, I mean in a couple of files, but the authentication happens in a distributed way en envoys or data plane.

In the next post, we will create the yamls and apply them in a real cluster to be able to see the behaviors.

See you there!!!!

Authentication & Authorization for microservices in Service Mesh World

Motivation

I’ve been studying Service Mesh infrastructure in the last year. There are many exciting features like how to achieve observability with minor changes in the code.

Or how to use the right deployment strategy to deliver the real value about microservices architecture for our customers, the business.
Also, people talk about how to handle network issues with Mesh, which one is very easy and very helpful as well.

I’ve been working with Enterprise Systems, which one in most of the cases this company has problems with security in the microservices architecture.

There are two main complains about this topic.

The first one is about different ways to implement security in microservices. Different frameworks and languages have mixed thoughts about security.

And the last one is about how we can provide security in the platform layer. It means remove security concerns from developers, in general, because there is a department that defines the security patterns for the company. This department has specific requirements to attend business requirements, as well.

That is the main reason that I decided to study security in the Service Mesh context, and then I’ve found the different ways to solve the problems described above, and I’ll try to explain how to achieve it using Istio.

Blog Post Series

This blog post series will cover the full authentication and authorization features present in ISTIO.

The series will have four posts and the main idea is to cover best practices regarding security for microservices architecture using the service mesh, we will use ISTIO for that.

The first post will cover the Authentication concepts present in ISTIO. We will explain how it works in detail to understand the right use cases for that.

The second post will cover the Authentication in ISTIO but in a practical way, in this post, we will have a lot of yaml and examples.

The third post will cover the Authorization concepts implemented in ISTIO, it is very important to understand

In the last post, we will create the Authorization stuff with yamls, this is the practical part for the Authorization part.

Now our context is very clear. Let’s start it right now !!!!!

Use-case for this Blog Series

The idea about this blog series is about how to use Istio to enable Authentication & Authorization in the microservices world but, to achieve that we need a use-case to show how it works in real.

We will configure a simple bet solution, it will enable users to create bets in our systems. The solution is composed of four microservices bet, matches, championship and players.

The bet microservice will reach the other one’s matches, championships and players to validate the data, it means the championship date and so on.

This is not a real use-case is something to use to clarify the ideas about security in the microservices world and get benefits from Service Mesh infrastructure.

Let’s see our simple solution diagram:

As we can see there are different profiles in our solution. The manager will manage the championship data, match data and users who will manage their profile.

In the next posts, we will cover all details about how Istio can help us to deliver security, authentication, and authorization in a centralized way.

See you there!!!

What is Service Mesh and Why you should consider it

Brief about Software Architecture History

Before to start the explanations about Service Mesh infrastructure, let’s understand a little bit about what we have created before, as software architects and developers.

I think it is essential to know why Service Mesh might be useful for you.

We’ll talk a little bit about Software Architecture History. I promise it will be rapid, but it will be worth it.

Let’s analyze the image below

There are different architectures models in the Timeline. The MVC Pattern which one is present in our architecture today.

SOA and EDA were popularized in 2000 and 2003, respectively; things started to be distributed. We started at that time to break things into small pieces of software, for several reasons.

And finally Microservices and Serverless, in 2013 and 2015 respectively, and different approaches about software development were coming.

Conway’s law and Inverse Conway Maneuver sprung up to the scene to explain how to work with Software Architecture in terms of business and Teams.

There is typical behavior if we look at this Timeline, we are trying to divide our software pieces into small and smaller parts, as small as we can.

But, what is it important or related to Service Mesh Infrastructure???

Microservices are distributed systems, and distributed systems means handle network problems.

That is exactly what Service Mesh Infrastructure can help us. Abstracts network issues from developers.

Service Mesh

In a nutshell.

Service Mesh can be defined as a dedicated infrastructure to handle a high volume of traffic based in IPC (inter-process communication). In a microservices architecture, usually called East-West Traffic.

In a few words, service mesh can be considered a “layer” to abstract network for services communications.

These abstractions solve the most part of the network handlings like Load Balancing, Circuit Breakers, Retries, Timeout, Smart Routing which can enable advanced deployment techniques like Canary Releases, Dark Launches, and others.

Then, we can take off these responsibilities from our application code. Also, we can remove these roles from developers, and it is very important because developers should code for the business, not for infrastructure requirements.

Another important characteristic of Service Mesh is Telemetry, some implementations integrate with Jaeger and Prometheus easily.

Famous libraries in the Java ecosystem related to network handlings like Netflix Ribbon, Hystrix and Eureka can be replaced for the Service Mesh implementations like ISTIO.

Service Mesh & Microservices Architecture

In general, in the Microservices Architecture, service-to-service communication is quite complex.

Usually involves different communications patterns like REST and gRPC over HTTP or AMQP for asynchronous and durable communications.

As we can see, microservices are distributed systems, that is the reason why Service Mesh Infrastructure fits very well.

Practical example

Let’s look in a simple and pretty standard Microservices Architecture

Standard Microservices Architecture

There are some important things to look here.

North & South Traffic

North & South traffic usually happens between different networks look at the image Network A and Network B. This kind of traffic comes from outside our infrastructure, our clients, and this traffic is not trusted because the external network is out of our control.

We need heavy security here, that’s our Gateway to protect our applications.

Usually, we have an API Platform to manage our external APIs. API Management techniques and processes can help us with this task.

East & West Traffic

On the other hand, the East-West traffic happens in general on the same network, as we saw before, normally it is called service-to-service communication or IPC.

That is the place where Service Mesh lives.

gRPC is a very interesting framework if you are looking for high throughput applications or service-to-service communications.

Conclusions

Service Mesh is an interesting thing you are trying to play with Microservices Architecture, but I strongly recommended you to understand a little deeper before adding Service Mesh in your Architecture Stack.

There is no silver bullet when you think about Software Architecture but we as Software Architect, Developers and other need to understand and propose the right solution considering the company context.

Install ISTIO on AZURE AKS

Hello,

During in my learning path to understanding Service Mesh and ISTIO. I decided to use some different cloud vendors. I choose Azure and Google.

I’ve started with Google Kubernetes Engine (GKE). It was my first experience with Google Cloud Platform components and was amazing. The command line is well documented and easy to interact with Kubernetes APIs.

Today I will explain how to install Istio components in Azure Cloud (Azure Kubernetes Service or AKS) which one offers managed kubernetes in Azure Infrastructure. On this post, I will use HELM to install Istio on kubernetes.

Let’s start with some requirements:

  • HELM Client ( installation instructions can be found here )
  • Azure CLI  (installation instructions can be found here )
  • kubectl ( installation instructions can be found here )

Creating the AKS Cluster and Preparing HELM

To create the AKS Cluster we can use the following statement:

Some considerations about this command:

  • I strongly recommend creating your own resource group
  • The –enable-rbac is mandatory to deploy ISTIO.

Then we need to configure our kubectl on Azure we can do it using the az command line, like this:

Now our kubectl is fully configured, we can start to install ISTIO in our AKS cluster.

Let’s start downloading the Istio Release. The zip can be found here. We are using the 0.8.0 version which one is the stable version. You need to choose the target OS, in the cluster.

Go to the ISTIO root folder and then we need to create a service account for HELM, it can be done using the following command:

Good, you should see the following output:

Awesome our service account is ready.

Let’s deploy our tiller deploy. Run the command above:

Then we can see, the following output:

Awesome, our HELM client is ready to start to deploy Istio.

Installing ISTIO

Go to the ISTIO root folder and then we can deploy install ISTIO in our Kubernetes cluster. It can be achieved with this command

After we can check the ISTIO components using the following command:

All the pods need to stay in Running state like in the image below:

Well done, our ISTIO is installed in our cluster and ready to receive some microservices.

On next week I will explain how to interact with our cluster, creating some microservices and manage the cluster monitoring tools like Grafana, Jaeger and other.

References:

Install ISTIO: https://istio.io/docs/setup/kubernetes/helm-install/

Create a cluster in AKS: https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough