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

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.

Images

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. 

Registry

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. 

Orchestration

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. 

Container

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.