Microservices Considerations: Security

This article is part of the series on Microservices Architecture.

It goes without saying, security is of utmost importance in any application. And there are many best practices and ways to secure the application at various points. Covering all security measures is out of scope of this article, so we are going to leave out the common practices that are followed such as –

Secure communication (HTTPS, XSS and CSRF protection)
Securing data at rest
Key management
Intrusion Detection and Prevention
Logging
… and many others

Rather, we will focus on looking at some practices that need to be given a close consideration in microservices architecture. Just to state the obvious, based on security requirements all or many of these measure have to be taken to ensure security.

Authentication and authorization:

Authentication is process of validating and identifying the user based on credentials presented. Authorization is function of specifying and verifying permission to access certain resources for an authenticated user.

There are various ways of implementing authentication and authorization in microservices architecture, however there are 2 common approaches especially if one is not relying on a 3rd party identity management system such as OpenId or AWS IAM.

Using gateway for authentication and authorization:

For applications using an API Gateway instead of simple proxy or router as an interface to APIs, it is possible to configure the gateway to handle authentication as well as authorization. Many gateways support OAuth, Basic/Digest, token based authentication as well as integrations with 3rd parties such as LDAP or Amazon IAM.

A typical workflow with this approach:

This approach although simple to implement, has some limitations:

• Services rely on Gateway for authentication and authorization. this no longer keeps services independent and isolated. Exposing a service separately without gateway, may be through a different proxy would not be as seamless.
• Some services might want to implement a specific authorization mechanism, although it might be possible for gateway to be configured to pass fine grained service specific roles, it goes against the basic principal of separation of concerns.

 

Custom OAuth to handle service level authorization:

Note: OAuth 2.0 henceforth is referred to as OAuth for simplification. Although OAuth 1.0 can be used to implement the workflows described here, however, OAuth 2.0 specification brings many concepts that go well hand in hand with services architecture for e.g. separation of Authorization server role from resource server role

The other approach is to build a custom OAuth for communication between various entities. A separate authentication and authorization service can perform responsibility of token management ( OAuth2.0 Authorization server role) while the other services can act as resource servers (OAuth 2.0 Resource Server role). The gateway acts as pass-through for tokens.

Workflow:

 

Different OAuth workflows can be used for communication with different clients

• The application Inter-service communication can happen using Client Credentials workflow aka 2 legged workflow (RFC 1.3.4)

OAuth Client Credentials Workflow

• In house Browser and mobile apps can use OAuth implicit workflow(RFC 1.3.2) or even Username-Password flow (RFC 1.3.3)

• Third party applications intending to access application services can allowed access using OAuth Authorization Code workflow (RFC 1.3.1)
• Third party servers can be allowed to communicate with the application services using OAuth 2.0 Client Credentials workflow aka 2 legged workflow similar to inter-service communication. The servers have to register for access to application services in exchange for Client Id and secret which can be then used for OAuth workflow.

For more details on Oauth2.0 workflows refer to this article

 

Minimizing attack surface area

Perimeter Fencing

Perimeter Fencing is a technique of isolating network areas at various levels so that a part of the network of resources and services are only accessible from other part that is configured to be trusted, for e.g. all services can be part of an internal private network exposing API may only be accessible from Gateway, while the Gateway itself is publicly accessible or exposed to trusted 3rd parties, similarly, the database server can only be made accessible to services which depend on it and is part of an internal network.

Firewalls

Firewalls can be used for reducing the number of entry points allowing access to the application. Firewall rules can be defined based on packet layer to application layer to control access to and from specific ports, protocols or applications.

The next post covers Database Scalability as a consideration