Securing Microservices: A Brief Look at Different Technologies

In a microservices architecture, a set of fine-grained services interact which each other to build an application or fulfill a business functionality. Each finely grained service implements a single function or a few related functions accessible over a network. This leads to an increased attack surface, making the security of a microservices architecture very important.

A typical application developed using microservices architecture look as follows.

Figure 1: Microservices Architecture

There are different technologies for protecting microservices, but in general, some technologies are more suitable for protecting microservices than others. However, all generalizations have exceptions. 

How to Protect Microservices

Some of the common technologies for protecting microservices are the following:

• Perimeter security.
• Username and password.
• Two-way SSL.
• OAuth 2.0 and OpenID Connect.
• Self-contained JWT tokens.

Let's dig deeper into each one of these to understand the pros and cons. 

Perimeter Security

Enforcing perimeter security is a very traditional approach for securing microservices. This means that individual microservices are not secured; the layer that accesses the microservices is trusted.

For example, access to a web app is secured and the web app freely calls the microservices layer. Individual microservices freely interact with each other (see Figure 2 below).

Figure 2: Perimeter Security for Microservices

There are some characteristics and requirements related to microservices that make perimeter security insufficient.

• When authentication or authorization should be performed at each service due to various reason.

• Each fine-grained service is a responsibility of a small team. This could mean the security of the data is also their responsibility.

Username and Password

In this approach, each microservice will be secured with BasicAuthentication. There are a couple of ways to implement this.

• End-user credentials. In this case, the end user's username and password are required by each microservice to perform authentication or authorization. When the application is calling the microservice or when a microservice is calling another microservice, it has to pass the username and password of the end-user. This approach has a lot of security risks.

• Every microservice should have access to the end-user credential store.

• The username and password must be stored in memory or session by each service so that it can be used when one microservice is calling another microservice.

• Trusted subsystem credentials. The username and password is for the trusted subsystem (for example, each entity in the system have a credential set). The drawback of this approach is that the end-user is not known, so authorizations cannot be performed. What happens if one entity updates the credential? If the credentials are kept in a file, then this file should be updated at each instance.

Two-Way SSL

In this security mechanism, each entity in the system has a certificate (public and private) keypair and communicate with each other using two-way SSL. In the normal SSL scenario, the server is authenticated by the client, but in two-way SSL, both parties authenticate to each other. This is a better approach compared to the end-user username and password approach, as risks are minimal. However, some cons of this approach are given below.

• Each microservice requires a certificate, so when certificates are updated, the update needs to happen in all instances.
• The end-user cannot be authorized or authenticated in this pattern.

It has similar advantages and disadvantages as the trusted subsystem pattern.

OAuth 2.0 and OpenID Connect

Microservices can use OAuth 2.0 along with OpenID connect to authenticate and authorize users. There is an IdP providing OAuth 2.0 tokens to the requested parties. For example, the application obtains an OAuth 2.0 access token and this access token is used to invoke all the services in the MSA. It can also be used for communication between microservices. Using short lifetime access, tokens simplifies and improves the security of the overall system. Using OpenID connect, the identity of the end user can be retrieved allowing microservices to perform the authorization itself.

Figure 3: OAuth 2.0 for Microservices

However, this approach has the disadvantage of additional calls to the IdP.

Self-Contained JWT Token

Self-contained JWT tokens have the authorization information within the token itself, i.e., the token is signed by the issuer and all parties can verify the validity of the token. This means that the microservice does not need to call an external party to validate the access token and obtain the JWT token. The additional call to validate the access token and obtain a bearer token is eliminated. It has all the advantages of OAuth2.0 but has the downside of not having short-living tokens.

Summary

As a summary, the pros and cons of each technology are highlighted below. Each has its own set of characteristics.