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.