Microservices Evolution and Adoption
The conventional monolithic framework is long dead. In fact, prayers of its last rites were said more than two decades ago when cloud-computing started getting mainstream. Since then, the solution to shortcomings of a monolith was addressed through an evolved Microservices Architecture that was based upon a Service Oriented Architecture (SOA). While some industry experts believe Microservices are nothing new but a rebranded approach to SOA, the subject is certainly debatable.
A Microservice Architecture was conceived to break-down an entire application into multiple loosely-coupled, autonomous services. This allowed the design and development of applications to be broken down into multiple smaller applications (known as Services), which aided faster development, easy maintenance, and efficient scaling.
Monolithic vs. Microservices Architecture
Faster times to market, reusable code, focused & minimized dependencies are some of the proven reasons organizations adopt a Microservice framework. Consider this to the fact that Microservices are considered to be an efficient enabler of adopting a DevOps culture. This gives additional credence to Microservices’ growing adoption rate among businesses that are looking to break away from organizational silos.
With the given benefits the framework brings, there are also known complexities and vulnerabilities that an organization faces in its quest for successful adoption. Let us take a closer look at some of the vulnerabilities and security practices that enable successful implementation and maintenance of a Microservices Architecture.
Vulnerabilities within a Microservice Framework
Agile teams use a Microservice framework to develop applications, where all services are treated as projects of their own that collectively enable a successful service implementation. This practice achieves service isolation, requires minimal development time and easy maintenance. However, security remains a primary concern as the majority of the effort is focused on the scalability and resiliency of the services. More so, due to their distributed nature, Microservices are considered four-times more susceptible to attack vectors.
What could go wrong?
1. API Exposure
Microservices communicate using APIs that are designed to be publicly accessible. This exposes a lot of sensitive information that is exchanged, and if not properly managed, the data is susceptible to unauthorized attack vectors. Such attack vectors usually target a single API service as an entry point to exploit and potentially bring down the services’ whole framework.
2. Container-based Security
Most microservices are developed and deployed on containers to achieve the goal of lightweight communication, faster scaling, and resilience in times of failure. However, containers that run on an outdated registry, images, or runtimes expose a wider attack surface. A recent research by Palo Alto Networks also highlighted the importance of container configuration while identifying 117 out of 941 audited Docker registries were exposed publicly without authentication.
3. Host-based Security
As an OS Kernel forms the lowest layer within a virtualized stack of containers, a single breach can allow attackers to gain root-level access to the host. Besides, loosely configured hosts that are publicly accessible over default ports remain perpetually exposed to security threats.
A quick scan (Dated 11th Feb 2021) on Shodan found 1,719 Docker hosts that are exposed publicly over Port 2375 – Dated 11th Feb 2021.
4. Open-Source Tool Vulnerabilities
Organizations commonly use a wide variety of open-source tools for developing and maintaining applications. This practice of using open-source is particularly risky since source code components and libraries are publicly available for hackers to exploit. According to an Open-Source Security report by Snyx, the vulnerability trends in the open-source ecosystem have been increasing year-on-year, with Node.js and Java leading the pile of being the most attacked platforms.
Microservices Security Best Practices
What is proven to work?
1. Access & Authentication
To process information requested by only authorized users and processes, organizations must follow secure authentication standards, such as OAuth. While doing so, users and processes should be authorized to access only resources that are part of their access scope. Additionally, adopt a Zero-Trust strategy that administers short-lived access secrets to pass on the right level of access to users. To help with this, third-party vault solutions, such as Vault by Hashicorp, offer out-of-box solutions for storing and administering microservices’ secrets dynamically.
2. Adopting DevSecOps Model
As a best practice, it is strongly recommended that organizations should embrace Security within the Development and Operations phases of an SDLC. This essentially starts with a change of mindset that considers Security to be as crucial as Development and Operations. Besides, microservice applications should be developed following a Twelve-Factor App Methodology that aids the development of scalable, secure, and resilient applications. This means that applications should follow a standard set of procedures for critical activities such as code revisions, configuration changes, administrative privileges, etc.
3. Build Secure API Gateways
Service calls of an API Gateway are prominently targeted by attack vectors to gain access into a microservice framework. Such a setup is particularly vulnerable when service calls act as the single entry point of authentication to the framework. To avoid such a single point of failure, it is recommended to distribute the API workload through multiple service calls, while implementing a robust Security Information and Event Management (SIEM) approach to secure API Gateways. Organizations can also leverage cloud-based API Management Platforms that help with managing the full lifespan of an API while safeguarding it from evolving security threats.
4. Securing Containers
Container registries are the first point of development frameworks that are exploited to inject malware into container images. It’s a good practice to integrate vulnerability scanners with CI/CD pipelines to identify potential image vulnerabilities while clearing out stale images that expose vulnerable points. Tools such as Docker Bench for Security, GCR, and ACR mitigate known security risks associated with container registries by performing robust vulnerability analysis, scanning images, and security profiling.
Components of an Azure Security Center (Image Source: https://docs.microsoft.com/)
5. Securing Container Hosts
Design the host framework that functions on a lean model, and utilizes only tools and resources that are required to keep it functioning. To do so, it is recommended that organizations leverage container-focused operating systems, such as RancherOS and CoreOS. Such platforms do the groundwork of keeping container images updated, removing unnecessary libraries and services while reducing regular patching overheads. Additionally, system security policies, such as SELinux, should undergo thorough testing to establish a standard security baseline for how OS resources and resource quotas are accessed.
Microservices architecture is steadily gaining popularity among organizations as the default standard for building and deploying software applications. While this adoption has its varying benefits, with it comes new and unique security challenges. As a result, it is imperative to equally adopt advanced approaches that ensure a seamless yet secure implementation. The best practices combined with continuous learning and adaptation help organizations embrace a microservices’ security baseline. While these are in place, organizations should also be mindful of the evolving nature of security challenges and note that securing a framework is a continuous process, rather than a one time task.