October 21, 2020 By Gavin Kenny 5 min read

The use of microservices-based architecture to realize complex, evolving solutions is growing in popularity. Microservices make it much easier to replace or upgrade components mid-flight. It also allows multiple developers to work on different aspects of the overall solution without affecting each other. 

However, microservices architecture comes with its own security challenges. Someone who might want to use it must carefully examine these challenges from the start to ensure data is private and secure, and that the system remains up when needed.

What is Microservices-Based Architecture?

Microservices are small, containerized application services that perform a single task or a small group of related tasks, unlike traditional, monolithic applications that handle a broad range of tasks. It is, therefore, vital to use container security tools that have been developed just for the microservices architecture environment.

Microservices architecture has several unique vulnerabilities as a direct result of its modular nature. Applications developed using microservices architecture are complicated and open. They have a much larger attack surface area than more traditional application models.

Microservices communicate via application programming interfaces (APIs) that are independent of machine architecture and even programming language. As a result, they have more exposed surface than traditional subroutines or functionalities of a large application, which only interact with other parts of the same application. Therefore, more potential attacks apply to them.

Due to the rapid development cycle and the continuous integration/continuous delivery (CI/CD) approach to microservices architecture, developers do not do code testing as a single event at the end of development, but rather in an ongoing process. They must manage this testing properly.

Finally, a unique set of threats can target the container-based solution in which microservices are implemented. These can stem from the integrity of the container images themselves, how they are managed, the level of isolation between containers, the vulnerabilities within the containers, such as bundled libraries, and the security of the operating system (OS) that hosts the containers.

Figure 1: Containers have their own threats, which traditional security tools cannot manage.

Microservices Architecture Best Practices for Security

The first step to a secure solution based on microservices is to ensure security is included in the design. Some fundamental tenets for all designs are:

  • Encrypt all communications (using https or transport layer security).
  • Authenticate all access requests.
  • Do not hard code certificates, passwords or any form of secrets within the code.
  • Use DevSecOps tools designed for microservice architecture environments to scan code as it is developed.
  • Define the APIs and strictly make sure all communications comply.

Security measures require these precautions at the code level, but someone considering this type of architecture should also think about the following factors as part of the implementation.


Isolation is a core principle of the microservices architecture concept. Each service must be an autonomous piece of the overall application puzzle. A microservice needs to be able to be deployed, maintained, modified, scaled and retired without affecting any of the other microservices around it.

Isolation also extends to those support functions beneath it, such as at the database level. If done correctly, one microservice will not be able to access the data of another and, if compromised, will not enable an attacker to move laterally.

Another area where isolation is vital to the microservices architecture concept is in failure mode. If a particular microservice fails, it should not bring down others, as well. 

API Security

Microservices should only communicate with each other using well-defined and secure APIs. A secure API is one that can guarantee the information it processes will be secret by making it visible only to the users, apps and servers that are authorized to consume it. It must only process the data from related clients and servers if it knows that that data has not been modified by a third party. The ability to identify the calling systems and their end-users is critical. This also applies to calls the API makes to third-party servers. An API must always be available to handle requests and process them reliably.

One way of helping to secure APIs and deal with authentication of users and processes is to use an API gateway. The makers of API gateways design them to scale. They manage much of the authentication overhead, using protocols like OAuth to check entities that try to access a microservice API.

Another advantage of using API gateways is that they can provide governance for API access, which provides an extra layer of security for the microservices architecture. An API gateway can manage how outside commands call services, which provides fail-over and other load balancing services. The gateway can also provide logging, allowing a security information and event management/security operations center (SIEM/SOC) service to monitor applications and identify unexpected behavior.

Container Security Solutions for Microservices Architecture

The container security on which a microservices architecture depends has its own sets of threat vectors. 

Container security risks can be either a compromise of a container image or container as a whole, or misuse of a container to attack other containers, the host OS or other hosts.

Through the image, registry, orchestrator, containers and host OS, new threat vectors can appear as follows.


Application images are one of the key vulnerable areas in a container environment. Images can be a mix of specially written and third party developed, including open source. We present a number of risks here, including outdated images, insecure versions of the software, applications carrying bugs and poorly configured images. The secure-by-design concept helps to address many of these risks, but it is important that developers remember to extend it to third-party containers or services they use. They need to have the right policies in place to make sure that they are reviewing and refreshing images on a regular basis. 


When using a poorly configured registry, access should happen through encrypted and authenticated connections. Also, the registry should undergo continuous monitoring to ensure all stale images that may be risks are cleared. 


It is vital to maintain control of what images you are using and how they communicate. Therefore, keep tight access control on cluster-wide administrative accounts through effective authentication methods, such as multifactor authentication. Segmenting containers by purpose, sensitivity and threat posture provides additional defense-in-depth. Overall, configure orchestrator platforms to use features that create a secure environment for all apps they run. 


The most common security issue in microservices architecture occurs when container runtimes that manage containers have vulnerabilities. A vulnerable runtime can expose all containers it runs, as well as the host OS, to potential security risks. Given the flexibility that containers enjoy through dynamic IPs over the network, developers need to identify network anomalies. Conduct regular vulnerability scans of containers, especially long-lived ones. You should also monitor them, feeding alerts into a tool that can correlate different events. This can then raise alerts to inform someone capable of solving potential problems. 

Another set of useful tools looks at how the user configured the containers and compares them to security policies. The tool can then raise an alert, shut the container down or remediate the configuration problem.

Host OS

Finally, the host OS is key to a successful container environment. Because it lies at the lowest level of the container architecture, it is a critical target for attackers. A compromise of the host OS can lead to the compromise of all containers running on it. Scan the host OS constantly for vulnerabilities, and apply any required updates right away. This is not just at the level of container runtime; it should also be done to the lower-level components, such as the kernel, which are key to secure container operations.

Proper configuration is also important to the security of the host OS. Run it as an immutable infrastructure with no data and application-level dependencies. This makes the host OS highly reliable and effective in functioning. Designers have created a growing number of host OSes specifically to run container environments. These only use the minimum services required to run containers, which have the advantage of improved performance but also a reduced attack area.

Luckily, there are a number of solutions and services available in the marketplace that can help mitigate these security challenges.

More from Network

Databases beware: Abusing Microsoft SQL Server with SQLRecon

20 min read - Over the course of my career, I’ve had the privileged opportunity to peek behind the veil of some of the largest organizations in the world. In my experience, most industry verticals rely on enterprise Windows networks. In fact, I can count on one hand the number of times I have seen a decentralized zero-trust network, enterprise Linux, macOS network, or Active Directory alternative (FreeIPA). As I navigate my way through these large and often complex enterprise networks, it is common…

Easy configuration fixes can protect your server from attack

4 min read - In March 2023, data on more than 56,000 people — including Social Security numbers and other personal information — was stolen in the D.C. Health Benefit Exchange Authority breach. The online health insurance marketplace hack exposed the personal details of Congress members, their families, staff and tens of thousands of other Washington-area residents. It appears the D.C. breach was due to “human error”, according to a recent report. Apparently, a computer server was misconfigured to allow access to data without proper…

X-Force identifies vulnerability in IoT platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today