nobeastsofierce - Fotolia
As containers continue to explode in popularity, adapting apps to run as microservices in the cloud is the obvious next step for many companies that want to run lean and mean IT operations. Before you containerize your app and deploy it, however, you should make sure your app is also secure. Cloud-hosted microservices pose security challenges that do not always apply in the context of traditional apps, and these challenges must be addressed to avoid major security vulnerabilities.
What makes microservices different
Traditionally, programmers built "monolithic" apps. That meant that the entire software stack on which the app relied was incorporated into a single deliverable. For example, your team might have built a web app by writing the front-end code for the app itself, integrating it with a MySQL database for data storage and packaging everything into a Linux-based virtual machine image so that it could be deployed on a public cloud service like AWS or Azure.
The microservices approach changes things by breaking apps into modular pieces. They are distributed separately and are generally not dependent on a particular type of operating system to run. That means that the app described above would no longer be distributed as a virtual machine image. Instead, the front-end code would be packaged into a container image. The database would run in a separate container. All of these containers would run on top of Docker or another container platform, with the result that the underlying operating system or cloud environment that hosts them would be irrelevant to the containers themselves.
Microservices and security
Microservices obviate some of the security challenges associated with monolithic apps. They make app environments more consistent, which simplifies security monitoring. They also increase the isolation between the various parts of an app, mitigating the risk that a breach in one part of the app will allow attackers to compromise the entire stack. And they can help provide resilience against distributed-denial-of-service attacks because containers allow more flexibility and scalability, and can therefore better resist attempts to overwhelm infrastructure by sending too many requests to servers.
Yet there are challenges when securing microservices architectures. They include:
- More attack surfaces. Having more moving pieces means there are more potential vulnerabilities for attackers to exploit. For instance, monolithic software stacks might not rely on the network to send information between a front-end app and a database, whereas containers usually do that over the network. That introduces a new potential attack vector.
- Less internal consistency. One of the benefits of microservices is that they allow developers to change between development languages and frameworks easily. If you currently develop your app in PHP but want to switch to Go, for example, it's easy to do that when the app front end is detached from the rest of the stack. But the fact that the app internals could change frequently according to developers' wishes also means there is less consistency. Whenever something changes, there is a chance that a new security vulnerability could emerge.
- Existing tools don't address securing microservices. Most of the tried-and-true security tools available today were designed before the microservices revolution. Newer options are emerging, but for now the simple fact remains that a lot of vulnerability scanners don't work well with containers or other microservice-based apps.
- New trust relationships. One of the advantages of containerized infrastructure is that you can quickly download and deploy container images for free from public repositories. Want to fire up a MySQL database or an Ubuntu Linux server? A simple docker --pull command will grab the container image you need in seconds. The drawback is that those container images come from public registries. That doesn't necessarily make them insecure, but it does mean that by using the images, you are incorporating third-party software into your stack. You can't guarantee the security of code that you don't control.
Steps to securing microservices
With the right strategies, you can mitigate the security risks associated with running apps on a microservices architecture in the cloud. The following steps can be particularly effective:
- Secure your internal environment. While microservices involve more moving parts, you can reduce security risks by assuring that the environment that hosts your microservices is as secure as possible. If you run a Docker environment in the cloud, that means making sure that no one but you has access to your cloud host, and that your Docker containers are configured to prevent public internet connections except where necessary.
- Use security scanners. Again, most traditional security tools are still in the process of adapting to microservices. But there are some useful tools already available, such as Docker Security Scanning and Clair from CoreOS. These tools help you to find and fix security vulnerabilities inside containers.
- Use access control. You can apply access-control limitations at several levels of the software stack to mitigate security risks. For instance, at the management level, you should make sure that only user accounts that can run Docker commands have permission to execute the Docker CLI tool on Unix systems. You can also configure access permissions in most container registries to prevent public access if desired.
- Assure communication. Make sure all members of the team responsible for building and deploying your organization's software communicate constantly, rather than operating in silos. That ensures that all parts of the operation are aware of changes made upstream or downstream -- and their possible security implications.
As more organizations migrate to DevOps-based workflows and technologies such as containers continue to grow in popularity, it's likely that security for microservices will become easier to manage. At present, however, the lack of ready-made security tools for microservices means that companies need to be especially proactive in securing software that they convert to run under a microservices architecture.
Will microservices be your new best friend?
Making DevOps more secure
Why microservices keep some security pros up at night
How to handle microservices performance management issues