Basics of Securing Microservices

The Popularity of Microservices

Microservices has become a highly popular way to build software, as opposed to the traditional monolithic, tiered approach. Problems that arise by separating the design of software into different modules built by separate teams then combined into a full solution have led to many software firms, including Google, Amazon and Netflix, adopting a microservices approach instead.

There is no widely agreed upon definition for microservices, but there is a shared consensus about their characteristics:

  • each delivers a specific business capability;
  • autonomously developed;
  • Independently deployable;
  • use messaging for communication purposes.

One of the key benefits of microservices is that using a more distributed, component-based architecture enables the separating out of an app’s services into isolated, interoperable containers, which makes it easier to build out a complex application from loosely coupled, reusable parts. IT teams across a business can build new applications for specific purposes or customers. This means that application development and data access to different lines of business and functional business partners can be decentralized and democratized.

Some microservices have their own data stores while others simply process information.

Microservices and Security

There are various security benefits when your app’s components and services are isolated, including:

  • a reduced attack surface area;
  • the potential to be more granular, applying service-specific rules to containers, APIs and firewalls;
  • the chance to be more specific with the use of different rules and layers for different components;
  • access requirements can be similarly tailored – “a model of least privilege” can be applied on a service-by-service basis to tailor what services are able to do;
  • responsibility can be more specifically distributed – each team can define exactly how their component should be interacted with.

While microservices architecture has these benefits and more, there are also various challenges. In the monolithic approach, one can implement a centralized security module, which manages security operations such as authorization and authentication; however, due to the distributed nature of microservices, a centralized security module would compromise efficiency, and undermine its distributed architecture. This also applies to data sharing: monolithic applications share data between different app modules in a centralized database or “in-memory”, but this is not possible with a microservices approach.

“The softest target in most organizations is the app layer and attackers know this. Microservices thus both make this problem harder and easier for the defenders,” John Morello, chief technology officer at Twistlock told The New Stack. “Harder, because as apps are decomposed, the amount of network interdependencies grows and most dev teams themselves don’t fully understand the connectivity mesh of their apps.”

According to a survey run by analyst firm McKinsey, 78% of more than 100 firms are not reconfiguring their security tools upon migration to the cloud. McKinsey recommends that enterprises “rethink how they protect data and applications – and put in place four critical practices”. The four practices they advocate are: (i) developing a cloud-centric cybersecurity model; (ii) redesigning a full set of cybersecurity controls for the public cloud; (iii) clarifying internal responsibilities for cybersecurity, compared to what providers will do; (iv) applying DevOps to cybersecurity.

AWS has discussed another practice, particularly relevant here: DevSecOps. In a talk with WeaveWorks, Abby Fuller, a developer advocate at AWS said, “To switch from a monolithic network to one comprised of synergistically functioning microservices, a company will need to transform both its culture and its system’s architecture. This process will not simply be a matter of atomizing the monolithic system into microservices. Service partnerships will be required to effectively manage the added complexities of testing, deploying and operating multiple microservices.”

Businesses adopting a microservices approach certainly need to build a new security strategy. It is crucial to develop a detailed framework and plan for development, governance, management and securing of microservices. A “defense-in-depth strategy” should be implemented.

Important Security Considerations

Security considerations for microservices that are important to bear in mind include:

  • Tooling – using a new set of management tools can be challenging, so it is important to ensure that training is put in place around areas such as authentication, authorization, hardening, and other such best practices;
  • Access permissions – these must be applied on a component-by-component basis, which involves strict API management, visibility into each component, and a clear roadmap of how it all works together;
  • Visibility – having a detailed map of each service, its dependencies, the other services it communicates with when those interactions happen and to what purpose will provide insight into how to best secure them and authenticate their access;
  • “Defense in depth” – layer your security defenses, going component by component to lock down the most sensitive functions and data with a “defense in depth” approach;
    • Firewalls between services – building fine-grained firewalls between services and containers leads to safe dividers between them, allowing a different set of firewall rules to be applied to each container with host-to-host encryption;
    • Encryption strategy – develop an approach to encryption measures, such as HTTPS transport security, to protect data both in transit and at rest;
    • Principle of “least access” – restrict access to the bare minimum – the less access, the more secure;
  • Keep on top of testing – make testing for vulnerabilities part of the build, update and maintenance program; or set up a monitoring program that looks at the system as a whole, noting any unusual communications between microservices that might suggest a problem.

Possible Security Approaches

Standard cybersecurity practices will be inadequate for microservices, given the underlying configuration of applications. It might take some time for security practices to catch up to the deployment of microservices on an industry-wide scale, however.  

There are a variety of possible best practice security approaches to microservices, including:

Containerizing Microservices

Containerizing microservices and managing them through a service such as Kubernetes is one way to think about security for microservices. Each microservice is ensured secure access, irrespective of where the microservices executes. Containers can offer a highly efficient security perimeter for microservices, as a result of their design.

“Containers enable you to apply security to each individual service — making them ideal for microservices. And no matter the application, putting it in a container provides an added layer of security,” David Lawrence, a senior software engineer at Docker, told The New Stack. “We see a common trend across enterprises is to containerize legacy applications, and as a result, gain the immediate benefit of hardened security — in addition to cost-efficiencies and portability to hybrid cloud environments.”

Many microservices are already run on containers (63% of enterprises surveyed by Enterprise Management Associates said they run microservices on containers; 30% said they were planning to do so within the next year), which allows them to benefit from these architectural advantages with little extra fuss. Compared to traditional systems, containers are declarative, predictive and minimal; which enables modern security platforms to learn automatically from a containerized mesh and enforce security, so that despite there being a larger number of interconnections, they can be more compartmentalized and controlled more easily through containerization than with human involvement.

Suzy Visvanathan, director, product management, for MapR told The New Stack, “Microservices need to be lightweight and execute in a flexible, agile manner depending on business events and the required context. Microservices also need the ability to share data to drive the operations and analytics required for the specific use case,” said Visvanathan. “The most efficient and secure way to support this is through an underlying data fabric that can support the required data access while providing the robust security and access controls.”

Securing Microservices through APIs

An essential principle in regards to securing microservices is to ensure that any microservice is clearly defined, well-documented, and standardized. APIs are often used to create that definition and standardization. APIs are capable of defining the mechanism of accessing any part of the system. With their individual APIs, microservices can be reconfigured and updated separately without the need to interrupt the application. However, microservices come with multiple separate APIs and ports per app, which offers more doors for intruders to attempt to access within an application.

Using an API to Offer a Secure, Well Defined Access Point

For an API to be capable of providing a secure, well-defined access point to a microservice, it needs to offer:

  • confidentiality –  a secure API must guarantee the confidentiality of the information it processes by ensuring it is only available to those users, apps and servers that are authorized to consume it;
  • availability – a secure API must have high availability to handle requests;
  • integrity – a secure API must be able to ensure the integrity of the information clients send it and the servers that it collaborates with;
  • reliability – an API must process requests reliably.

Managing APIs to Secure Microservices

The next step involves the establishment of API management policies to enable visibility and good governance for the functioning of APIs. There are four main principles to using API management for security:

  1. Publish your APIs to ensure that developers have what they need to self-serve their needs and clearly understand the function, scope and interface of each microservice;    
  2. Adapt your APIs through developing policies of logic, which relate to security, quality-of-service, dynamic data filtering, auditing, etc.;
  3. Watch your APIs to allow for the strategizing of scalability in relation to different traffic levels and taking a temperature gauge on the impact of your assets;
  4. Tailor your APIs to the different lines of business, thereby making API management s a decentralized or federated exercise in collaboration between lines of business and central IT.

If you have connected several services and exposed the connections as APIs, those services should now be capable of reuse, the discovery of the connected entity and then connecting it to the next one. As increasing numbers of these systems are built out, as opposed to connecting more connections, you’re rather reusing the ones you have already done. If someone has worked out how to access something, or a system level person has enabled access to a particular system, that access should be capable of being reused the next time you do that same thing. Therefore, there is a single point of governance for access, even though numerous people are making use of that access. Over time, just the right connections can be built i.e. the ones that make business sense, then value after value can be layered atop those.

Used in combination with API management principles, this should mean that there is a well-defined standardized framework through which everyone in the business is able to visualize, manage and control access to central systems. Nonetheless, it is important that every microservice and its API access point should have built-in mechanisms for visibility and security. Security principles need to be spread out across the enterprise and designed into each microservice versus security imposing standards on top of everything, which slows things down.

Conclusion

Securing microservices is not a straightforward matter. However, as seen here, there are various approaches that can be taken to doing so and many benefits to leveraging thereby. Developing a “defense in depth” strategy is an essential first step. Building security into the development, updating and maintenance of microservices are also vital.

Digiprove sealCopyright secured by Digiprove © 2020