This post is the fourth in a multipart series on exploring the basics of microservices. Check back each Monday for additional installments.
If you are reading this, then you probably know by now how microservices can serve as an elegant way to break the shackles of monolithic architectures when building or deploying applications. But aside from pioneers such as Netflix, which began exploring this territory a few years ago, chances are microservices are something relatively new for your organization. Protection against cyber attacks represents an even bigger unknown for many.
Microservices offer advantages and disadvantages security-wise. With their individual APIs, microservices can be reconfigured and updated separately, without interrupting the application that might rely on many microservices to run. However, microservices also come with many separate APIs and ports per app, of course, thus representing numerous doors for intruders to try to access within an application. While their isolated and stand-alone structure within applications makes them easier to defend (more about why this is the case below), microservices bring with them their own separate security challenges.
“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,” said John Morello, chief technology officer at Twistlock “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.”
We gathered insights from leading microservices and security experts about what to keep in mind when thinking about cybersecurity, whether you are already in the middle of a major microservices conversion project or are just getting your feet wet.
Container Confusion and Power
Microservices and container security are sometimes incorrectly referred to interchangeably, even though they are two different things. This may be due, in part, to how most enterprises run microservices on containers. According to an Enterprise Management Associates study, for example, 63 percent of enterprises surveyed run microservices on containers, while an additional 30 percent are planning to do so in the next 12 months. At the same time, of course, microservices can be confined to a virtual server, for example, just as they can be in a container.
The confusion between containers and microservices might also have a lot to do with how container security protocols can help to protect against potential vulnerabilities of microservices within containers.
Indeed, since microservices very often run in containers, they can benefit from some of their architectural advantages, says Twistlock’s Morello. “Containers are declarative, predictable, and minimal relative to traditional systems,” said Morello. “This means that modern security platforms can automatically learn this mesh and enforce it, such that even though there is a larger number of interconnections, they’re more compartmentalized and controlled with less human involvement.”
According to analyst firm McKinsey, a full 78 percent of more than 100 firms recently surveyed are not reconfiguring their security tools when migrating to the cloud.
The ability to measure and compare observed network behavior to a predictive model for a microservice is a key advantage that containerized architectures provide, said Morello. “While it’s theoretically possible to create a reference model for traditional, non-containerized services, this is almost impossible to do at scale in practice,” Morello said. “Few developers truly understand all the network dependencies in a complex app and fewer still have the time to manually codify these interactions into external systems and maintain those definitions over time as the app evolves. The fact that containers make machine learning about these network flows practical and effective is a fundamental security advantage that enables more tightly defined, application-tailored network policies to be used at scale.”
The stateless qualities that can add agility to how microservices are deployed and administrated can also be applied to microservices security in container environments, said Suzy Visvanathan, director, product management, for MapR. “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.”
Containerizing microservices and managing them through Kubernetes is one such way of providing this, Visvanathan said. “Each microservice is guaranteed secure access, and regardless of where that microservices execute, the access method and security is consistent,” Visvanathan said.
Containers can serve as an excellent security perimeter for microservices, thanks to 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. “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.”
The Microservices Services Checklist
Considering how the underlying configurations of applications running on microservices are very different than those of monolithic architectures, standard cybersecurity practices will be, of course, inadequate. However, it may be a while before security practices catch up to microservices’ deployment on an industry-wide scale. Cloud deployments may serve as an example of why this will likely be the case.
According to analyst firm McKinsey, a full 78 percent of more than 100 firms recently surveyed are not reconfiguring their security tools when migrating to the cloud. Similarly, most security standards in place among the enterprises listed in the survey are non-sustainable for cloud networks. While data about microservices projects was not provided in the report, it can thus be inferred that at least a relative percentage of firms are not revamping their on-premise security practices and protocols for microservices.
“Where a traditionally monolithic application can be delivered in a large container model, moving an application from a traditional monolithic architecture to microservices requires complete refactoring,” said Carson Sweet, CTO of CloudPassage. “And as many enterprises learned when they tried to build private clouds, just because a new technology is hot doesn’t mean there’s enough engineering talent to go around. In the case of microservices, there’s a need for developers, QA engineers, and infrastructure architects who actually understand microservices.”
Microservices thus involve a major change in how applications are delivered, deployed — and protected, Rani Osnat, vice president, product marketing, for Aqua Security, said. Key security considerations include:
- Dynamic code delivery and updates: By automating testing, code must be vetted to ensure that it represents an acceptable risk in terms of vulnerabilities, malware, hard-coded secrets, etc. “The old way of gating a version, stopping to test it for an extended time, etc. will simply not fly,” said Osnat.
- Tooling: This is especially critical when deploying microservices apps with a new set of management tools, such as Kubernetes. “There’s a knowledge gap around these tools that leads to mistakes around authentication, authorization, hardening, and other best practices,” said Osnat. “We’re talking about basic hygiene here.”
- Abstraction from a host environment: Since existing endpoint and server security tools don’t have the required access and granularity to adequately monitor microservices, visibility and control become issues. “Since microservices can be scaled up and down rapidly, and across different types of infrastructures; it’s a challenge to track them,” Osnat said. “Infrastructure-based approach is doomed to fail, and you have to find a way to secure microservices in advance of their deployment.”
- Networking: Microservices represent the best of both worlds when seeking to secure networking vulnerabilities, since, microservices essentially expose networking deeper inside the application. “The opportunity is that you can secure the application at the microservice level, which would prevent an attack from spreading much sooner (in a much smaller radius) than was ever possible before,” Osnat said. “On the other hand, microservices networking is more complex and dynamic, once again rendering traditional network security tools inadequate.”
One might assume overzealous security practices can create bottlenecks, as the sharing of microservices among applications is needlessly blocked. However, microservices can never be too tight, especially as compliance regulations and governmental security mandates become stricter, according to Dave Nielsen, head of ecosystem programs, at Redis Labs. One example of why this is the case is how the European Union’s soon-to-take-effect General Data Protection Regulation (GDPR) that will impose much stricter data sharing limitation within the European Union trading block.
As mentioned above, microservices security, in many ways, represents many unique and especially difficult challenges. DevOps and security teams, for example, must be especially vigilant against unauthenticated access to data and insecure client-side connections leading to man-in-the-middle leakage and attacks, Nielsen said.
“With that said, tight security during the dev/test phase seems like overkill,” Nielsen said. “But in production, security can never be tight enough.”