Book Excerpt: Securing Microservice APIs
How to build a secure microservice architecture.
This is excerpt from Securing Microservice APIs, a new book from O’Reilly written by Matt McLarty, Rob Wilson & Scott Morrison.
Some key concepts are needed in order to define a universal model for microservice API security. We start with the service (aka micro‐ service), a logical component that provides functionality to service consumers through an interface. A service instance is implemented through one or more runtime components, often a set of containers in a microservice architecture. The service interface is often a web API, a programmatic interface accessible via HTTP(s). A service’s API is accessed through an API endpoint, a network-addressable location within the runtime environment. A service’s API may have more than one endpoint.
An API request is a message sent to an API endpoint that triggers the service’s execution, and an API response is a message sent in return to communicate the result of the service’s execution. A component that sends an API request takes the role of API consumer, while the service that receives the API request and sends the API response back to the consumer takes the role of API provider. A service may play the role of both API consumer and API provider, depending on the message context. Both roles may also be played by components other than services. An API intermediary is a component that sits in the API request path from API consumer to API provider. API gate‐ ways and service proxies are common API intermediaries. An API endpoint may be implemented on an API intermediary.
API Access Control for Microservices
Speed of delivery has typically been the motivating factor for organizations moving to a microservice architecture, security being a secondary consideration. This book addresses access control for web APIs within a microservice architecture. The “IAAA” access control framework—identification, authentication, authorization, and accountability (alternatively accounting, or auditing)—provides a useful basis for describing web API access control in the context of microservices.
Identification: Messages may be triggered by end user activity or automated events and may be distributed and transformed through several interme‐ diaries. Service consumers and intermediaries must be able to send API request messages that include multiple identities along with optional attributes that detail those identities, and they must be able to accept API requests that include multiple identities and their attributes.
Authentication: API requests may be authenticated through included credentials, asserted claims (e.g., a token), trust relationships, or a combination of these methods. Services must be able to either perform the authentication themselves or delegate authentication to a trusted component.
Authorization: Any application component—service or intermediary—that authenticates an identity may make an authorization decision based on the combination of the identity, its attributes, and the request context. In a distributed microservice architecture, a single request may go through multiple authorization decisions as it is passed from component to component.
Accountability: It is important to audit system activity affected by API requests in order to provide forensic details for intentional or unintended system breaches. Accounting for an API message can happen at any point in the request’s or response’s path. It is valuable to capture as much of the message’s context as possible, given the potentially wide range of identities, attributes, and processing components involved.