"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."
What's inside also counts
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 of questions 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.
Sign up for CIO Asia eNewsletters.