5 things you should do to secure your microservices
Microservices are fast becoming the defacto architectural style with which applications are being built. Be it a startup or established FinTechs, it is being adopted by everyone at a blistering speed. According to the findings in Sequoia Captial’s Microservices Summit in January 2016, early adopters of microservices have been able to cut development lead time by around 75%! Companies like Airbnb, Disney, Dropbox, GE, Goldman Sachs and Twitter are at the forefront and have already experienced a 75% cut in development lead time! Microservices are the answer to reducing risks associated with Continuous Delivery due to shrinking sizes of deployments.
And security, now more than ever, has become a central point of discussion. All precautions for most security related issues like SQL injection, XSS, CSRF, mass assignment vulnerability and so on are taken care of. Still, extra measures need to be taken when it comes to microservices since they interact with internal or external services. And compromising on security will be a disaster for your business sensitive data. Microservices adoption is not a fashion statement; rather a careful implementation will give you the expected benefits.
Please have second look on your Microservice implementation, they may be bleeding and prone to security threads. The below pointers might help you to do health check and confidence back ”
- Security as a Microservice
Among the many microservices that are being developed, security could itself be written as a microservice. An Oauth2 based security service could act as a point of authentication for users and authorization across resources in your larger application context.
Oauth 2 has a few grant types – authorization code grant, implicit grant, resource owner password credentials grant and client credentials grant. These determine how authorization flow happens between the various parties involved.
A relevant grant type should be chosen based on the context of application security. For example, when a user logs in through mobile and accesses resources provided by a microservice,
- Use an API Gateway before reaching Microservices
An API gateway is an architectural pattern where all API requests are sent to a single gateway that then routes it to the appropriate service. This gateway could also perform authentication and authorization by making use of the security microservice prescribed above.
- 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. Usually, the approach differs based on the type of client too.
- If the service is accessed from a mobile app, have a key/secret token by which the app is identified first and then allowed 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.
- Secure your middleware
Many microservices now-a-days use a middleware component to pass messages across. But most of 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. Therefore any middleware software installed as part of your overall application should be setup with proper credentials.
- Automate Security Testing
Security is tough. As much as one plans to close all loop holes in a system, there will always be motivated attackers trying to gain access. In order to minimize 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.
Microservices could be used for external access i.e. accessible by the public network, or internally i.e. accessible only by other systems and users within a private network. Securing them requires different approaches in both cases. Making a conscious effort to apply the above approaches will help the organization in the long term, and will pay rich dividends in terms of security. Your devops guys will be much happier too for sounder and more peaceful sleep at nights!