Wondering how to secure the Microservices you are working on?

Ironically, few characteristics of a Microservices architecture which consider as its benefits can also contribute to its disadvantages. While Microservices provide greater flexibility in overall application development and management, it also increases the complexity of the same actions due to the need for more coordination and communication for deploying Microservices. This also creates an impact on the performance of the application. A monolith is a single, self-contained codebase so application performance considerations essentially confine for development, whereas Microservices require greater demand from the network for each Microservice to communicate and work towards a common objective. These are only a handful of the pros and cons to consider when deciding between Microservices or monolith, but performance, deployability and scalability are going to be at the top of the list.

A common driver to switch to Microservices maintaining a monolithic codebase is incredibly inefficient and makes the organizational pursuit of business agility difficult. This does not mean that transitioning to Microservices is going to be smooth. Before starting a transition initiative, identify the biggest pain points and boundaries in the monolithic codebase and decouple them into separate services. It’s much more important to make sure these services can continue to handle their specific business logic within the boundary. When it comes to Microservices it can be common for developers and architects to focus too much on the size of code, blocks of services decoupled from the monolithic codebase. But the reality is that these services will be as big as they need to handle their specific business logic. Too much decoupling, and you may end up with too many moving parts, there is always going to be time in the future to decouple services even further as you study the pain points of building and operating under this new architecture. Another important consideration to keep in mind is that as you begin to transition to Microservices, your existing business will still be running and growing on the monolith. Therefore, “shared responsibilities” can win the day with the development efforts split into two, smaller teams- one that maintains the old codebase, while the other one works on the new codebase.

When you make the decision to go ahead with Microservices architecture to build all your critical business operations, security is of topmost importance. It could result in many unpleasant outcomes, from losing customer confidence to bankruptcy. Emphasis on security today is higher than at any time in the past. Microservices are becoming key enablers of digital transformation, so Microservices security must consciously plan, design, and implement.

1. Security between Microservices:

Security between Microservices should enforce with mutual TLS to make sure that unauthorized clients within the architecture won’t be able to consume them. Logging should be enabled across the board to observe and monitor how the Microservices are behaving.

An Oauth2 based security service could act as a point of authentication for users and authorization across resources in your larger application context.

Oauth2 has a few grant types – authorization code grant, implicit grant, resource owner password credentials grant and client credentials grant.  These dictate how authorization flow happens between the various parties involved.

It is advisable to choose a relevant grant type based on the context of application security.  For example, when a user logs in through mobile and accesses resources provided by a Microservice.

1. Use an API Gateway before reaching Microservices

An API gateway is an architectural pattern where all API requests sent to a single gateway then routes it to the appropriate service.  This gateway could also perform authentication and authorization by making use of the security in the microservices prescribed above.

1. Restrict Service Access with Firewalls and Tokens

Along with API gateway, it is also important to restrict access to Microservices with firewalls and/or tokens. Generally, the approach differs based on the type of client too.

• If the service is accessible from a mobile app, have a key/secret token by which the app identifies first and then allows access.
• If it’s a web application, whitelist IP addresses in a firewall to prevent unauthorized use. This should only enable other microservices or the API gateway present within the internal network, thereby preventing an outsider from directly accessing it.

1. Secure your middleware

Many microservices use a middleware component to pass messages across. But such middleware software come with a default credential or no credential at all.  For example, a RabbitMQ installation which doesn’t have a default password could be prone to attack if the server’s IP is not whitelisted or an attacker gains access to that server through IP spoofing.  So, any middleware software installed as part of your overall application should be setup with proper credentials.

1. Automate Security Testing

Security is tough. As much as one plans to close all loopholes in a system, there will always be motivated attackers trying to gain access. To reduce mishaps, automate the testing of your security implementation in your Microservices deployment.  A tool like OWASP Zed Attack Proxy (ZAP) will be a good addition to your arsenal in your fight against security threats.

As more companies begin to adopt the DevOps methodology, they are also adopting Microservices. Among them are Amazon, Netflix, Spotify, Uber, and Walmart – just to name a few. The transition of architecture from monolithic to Microservice introduces complexity, but it also paves the way for automated processes. In the end, if you are adopting DevOps, using Microservices is a faster, more efficient way to provide your clients with what they need. Techcello’s approach to Microservices is more suitable and diverted to making your IT future-ready. It makes your SaaS migration simple and smooth.