Securing Microservices: A Brief Look at Different Technologies
Securing Microservices: A Brief Look at Different Technologies
In this article, the author describes common technologies for protecting microservices and explains the pros and cons of each.
Join the DZone community and get the full member experience.
Join For FreeIn 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.
Authentication at Service |
Risk to User Credential Exposure |
Enduser Authentication Authorization |
External IdP |
|
Perimeter Security |
No |
Not Applicable |
No |
No |
Username and password |
Yes |
Very High |
Yes |
No |
2-Way SSL |
Yes |
Not Applicable |
Yes |
No |
OAuth2.0 and OIDC |
Yes |
Low |
Yes |
Yes; issues access tokens |
Self-contained JWT |
Yes |
Low |
Yes |
Yes; issues JWT tokens |
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}