Securing Microservice APIs

Chapter 1. Microservice Architecture

The term “microservices” gained popularity following a blog post from James Lewis and Martin Fowler published in early 2014 in which they described a new style of software architecture consisting of small, interconnected components assembled to form distributed applications. Individual microservices within a microservice architecture generally display the following characteristics:

Service orientation

An individual microservice typically implements a single functional responsibility and may be consumed by other software components at any “layer” or “tier” of the system.

Independent deployability and manageability

An individual microservice should be able to be deployed, managed, and scaled on its own without the need to coordinate with other components in the system.

Ephemerality and elasticity

Individual microservice instances are frequently short-lived, and multiple instances of a microservice are often run and then shut down in order to meet the dynamic performance needs of the system.

In addition to these characteristics, microservices often use the following standard technologies:

Web API communication

Microservices often publish their business functions through HTTP-based web APIs encoded using JSON or other related media types.

Container-based deployments

Microservices often use Linux containers—frequently Docker containers—as their unit of deployment, allowing for a smooth transition from development to operations in a range of frameworks and platforms.

Collectively, these microservice characteristics and common technologies must be factored into any solution for microservice API access control.

The Microservice API Landscape

Some key concepts are needed in order to define a universal model for microservice API security. We start with the service (aka microservice), 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 gateways and service proxies are common API intermediaries. An API endpoint may be implemented on an API intermediary.

Figure 1-1 shows an example of these concepts working together in a microservice architecture:

Figure 1-1. Sample API requests in a microservice architecture

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 intermediaries. 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.

Microservice Architecture Qualities

In addition to the specific functional requirements for microservice API access control, it is important to note the nonfunctional requirements. Whereas the functional requirements describe what the solution needs to do, the nonfunctional requirements define how the solution should be implemented and operated. This is especially important in a microservice architecture, since there are a number of qualities that will determine whether a solution will be amenable to organizations adopting microservices.

Manageability/Operability

Microservice architectures typically feature a high degree of automation for all functions. In order for an access control solution to be viable in a microservice architecture, it must expose machine accessible interfaces for management automation.

Performance

Due to the distributed nature of microservice architectures, the processing latency of each component has the potential to degrade the performance of the overall system. As such, an access control solution within a microservice architecture should avoid adding latency as much as possible.

Usability

The rise in popularity of microservice architecture has been driven by developers. Tools that have gained popularity in the microservices movement have usually featured strong usability, marked by reduced friction in the developer experience. Therefore, it is important for a microservice API access control solution not to impede a developer’s tasks.

With the combination of the functional access control framework and its optimal characteristics, we may now evaluate the variety of current approaches to API access control in a microservice architecture.

¹ API endpoints are often listed in service registries like Consul, Eureka, or etcd.