Last week I wrote about how containers are becoming popular attack targets both inside and outside of a public cloud. This week let’s drill down on a common byproduct of containers: microservices.
Microservices is both an architecture and a way of deploying applications. Indeed, microservices is a term used to describe the practice of breaking up an application, within a container or not, into a series of smaller specialized parts. Each microservice is able to communicate with one another across a common interface, such as APIs and RESTful interfaces.
Many consider this approach new, but back in the days of service-oriented architecture, we called them fine-grained services. You may build your own microservices or they may be built by others and leveraged as services. Indeed, SaaS providers offer their own catalog of microservices that can be integrated into local or cloud-hosted applications.
The addition of microservices means that we need to test them properly, as well as integrate them with our container-based and traditional service-oriented applications. They come with a few core challenges in terms of security testing and operations:
- Microservices are challenging to test, including security testing. They must be tested independently, considering that each is a separate API. You can use tools that are specific to microservices and containers, but any command line testing tool will work fine.
- Microservices can change frequently. Any cybersecurity expert will tell you that change brings vulnerabilities. Microservices are often changed by their remote hosts. For instance, a microservice that calculates international shipping costs and tariffs will change often for both business and technical reasons in a single year. Those operating microservices need to come up with way to introduce the new services so as not to stop production or introduce security problems.
- Microservices add a new dimension to security operations. When operating microservices, including tracking changes, you need to pay special attention to security issues. Indeed, they need to go through automated security testing, as well as testing with the integrated composite application. Some applications may utilize more than a hundred microservices, and all must be tested independently and as a holistic application.
How do you take on microservices security and operations effectively? The short answer is planning, including change management, operational monitoring at the microservices layers, as well as API and service-based governance. All that is hard, but worth it if you can avoid one breach.
As a cloud deployment becomes more complex, it becomes more vulnerable. We need to be aware of what’s changing and ensure that we’re ahead of security and operational issues. What do you think?