Microservices: Simple servers, complex security
You need to keep in mind more than a few details before you rip the wrapping off the shiny new app containers. Instead of securing one monolithic app or a couple, you're now responsible for perhaps dozens of smaller services, all capable of interacting with each other in a number of ways. What's more, you're trying to secure those services from outside attack and internal misuse, deliberate or not.
Yesterday's monolithic apps were big and inflexible, and the service-oriented architectures created to replace them had their own complexities. Replacing these stacks with loosely coupled applications deployed via immutable containers seems like a step in the right direction, and it is. But it also means several key breakaways from tradition, many of which affect security.
As Eric Knorr put it in his discussion of winning with microservices, these sea changes mean developers end up shouldering responsibilities once held by operations. Security inside of and between microservices falls into that category. A good argument could be had about who has the better understanding of security -- dev or ops -- but remember that developers own the APIs that govern how services interact with other services and with the outside world. That is, much of the security burden falls to them.
For the ops folks, securing microservices means discarding assumptions about even what tools can be used. Owen Garrett, head of products at Nginx, said in an email, "Much of the technology that has been developed to manage traditional Web-based applications … will not map directly to microservices applications." This includes security, not only Web application firewalls, "but internal IDS processes too."
Another reason microservices make security tougher: There are many more moving parts to attack.
As Garrett explained, "The attack surface of a microservices app can be much greater [than a traditional monolithic application]." With older apps, "the attack surface is very linear -- traffic hits the load balancer, then the Web (presentation tier), and then the application and data tiers."
But with microservices, Garrett noted the flow is entirely different: "It's generally necessary to expose a large number of different services so that external applications can address them directly, leading to a much greater attack surface."
"If you break up your application into smaller services," said Kelsey Hightower, product manager and chief advocate for CoreOS, "you'll need a more robust authentication/authorization solution between each service. This can be a challenge for many organizations since they only implement this level of security between users and their products."
Then there's securing access to data. Jonah Kowall, VP of market development and insights at AppDynamics, has looked at the way Netflix, an influential microservices user, has approached data storage. "Netflix recommends keeping data storage for each service self-contained," he said in a phone conversation. This reduces the interdependencies among services, but increases the number of data stores.
Instead of residing in a single, central repository (such as the RDBMS of a traditional monolithic app), the data in a microservices architecture is highly distributed. Typically, it will even be divided among multiple types of data stores (Cassandra and Riak, in the case of Netflix).
"That becomes a major security issue," Kowall pointed out, "because then you don't even have a centralized way to determine if bad things are happening. It creates a lot of issues around where you would go for a single source of truth for validating compliance, or validating any type of check or rule that you're trying to implement for security control."
The challenges created by the panoply of technology in the data tier extend to the microservices themselves. Because microservices can be composed independently of each other, the developers often have free rein to implement different languages, frameworks, middleware, and so on. Thus, each microservice could involve a completely different set of security considerations.
As Garrett put it: "The problems are compounded when each microservice is developed independently of the others, with its own choice of language and development framework, and perhaps no universal security standards."
With container-composed microservices, it gets even stickier when you find out containers have a bad reputation for being opaque. Some solutions are coming to market: Twistlock, for instance, markets a security system intended to help developers get a better grip on what's happening inside containers. But a single consistent solution isn't likely to come along until standards in the container world settle down.
Best practices exist for microservices creators, including those trying to address security issues. Among the best so far is Graham Lea's list ofquestions you should be asking about microservices security. It's a long and potentially daunting catalog , but it underscores the difficulty in getting security right -- not always because of technical reasons. In the end, if you’re building anything truly new with microservices, you’re on your own -- but that goes with any other cutting-edge technology, too.