As popular as the microservices movement has been, it has taken a long time for security to get the attention it deserves. But that attention was inevitable. More and more organizations are adopting microservices, including those companies for whom privacy and access control are first class concerns. When working with one large financial services company, my colleague Rob Wilson and I recognized that little comprehensive guidance existed even in the specific area of security for web APIs in a microservice architecture. With that in mind, we joined forces with noted API security expert Scott Morrison to document a general approach to securing microservice APIs. The result is this new book from O'Reilly.
Rather than attempt to define "the one true solution" for microservice API security, we have instead tried to create a framework that can be applied in any context with a variety of technologies. Defining a microservice API security approach required us to examine API security best practices through the lens of microservice architecture. Here are some key characteristics we flagged that are required in a solid access control solution for microservice APIs:
Amenable to independently deployable, ephemeral services
Automatable configuration
Decentralized administration, low latency, and highly scalability
Developer friendly
With those properties in mind, we then did a survey of the current solutions being used to secure APIs by microservice implementers. We found a variety of approaches that borrowed from web API and distributed application security practices, as well as some emerging techniques based on popular microservice platforms.
The most basic form of API access control is network-based. These controls can range from restricting communication to localhost processes only to isolating segments on a large network. The result is straightforward: either messages can be sent between processes or they can't. There are a number of open source projects that provide access control through network overlays, including Romana, OpenContrail, Calico, and Cilium. Network controls can be taken a step further by using TLS and certificate-based trust in order to assert identities. The SPIFFE project aims to solve specific challenges with certificate management in a microservice context.
On the web, such network-based mechanisms are not useful since there is no single administrative entity to manage them. Like the web, large networks of microservices may exceed the span of one organization's control, so other techniques are needed. Borrowing from web API access control, API keys are being used in microservice architectures to identify service consumers, and standards like OAuth 2.0 and OpenID Connect are being used to provide a robust, token-based authorization framework. JSON Web Tokens (JWT's) are a popular "by-value" token format being used for asserting authorization claims within microservice implementations, either as the token format for OAuth 2.0 or on their own.
From an implementation perspective, API gateways and service proxies-possibly as part of a service mesh-are popular choices for enforcing microservice API access control policies. Also, the most popular microservice platforms like Kubernetes, Cloud Foundry, and AWS, all have security features that can be used to control access to APIs. These platform-based options can be very helpful if all microservices are being implemented on a single platform, but that is not the reality for most large organizations.
Having completed due diligence on these current approaches, we felt that in spite of the tremendous choices, there was still no consensus on how to handle API access control in a multi-cloud microservice architecture. To fill this gap, we defined our own model: "Domain Hierarchy Access Regulation for Microservice Architecture", or "DHARMA" for short. In part 2 of this blog series, I'll explain DHARMA in detail. Stay tuned!
