Applying and Extending DHARMA

This article shares concepts from the O'Reilly book Securing Microservice APIs.

In my last post on API Security for Microservices, I introduced the DHARMA (Domain Hierarchy Access Regulation for Microservice Architecture) model for API access control. This model presents a way of abstracting access patterns within distributed systems and is particularly useful when dealing with microservices. Perhaps the best way to understand the usefulness of DHARMA is to see how it can be applied.

DHARMA for System Design

As discussed in the previous post, one of the main goals of introducing DHARMA is to incent thinking about security and system concerns as early as possible in the microservice development lifecycle. Too often, security is an afterthought in the design of distributed systems. When breaking down a complex software system into discrete business domains through service boundaries, it makes sense to consider what the right boundaries are from an access perspective. It could be that the security and business domains match, there could be other factors--such as runtime placement or data sensitivity--that they would not align. In the book, we outline the following simple methodology for designing a microservice system's API security using DHARMA:

1. Identify the trust domains that comprise the system, including overlaps and hierarchies
2. Define the access and trust mechanisms for each domain
3. For the APIs in each domain, identify the interior and boundary endpoints
4. Based on these steps, determine the right implementation platform for each API and each domain

Using this simple approach will help sequence the thinking so that technology choices are made with the right inputs and without constraining the design.

Some DHARMA Implementation Examples

One of our design points for DHARMA was to ensure it would support multi-cloud deployment. We have found that most large organizations moving to a microservice architecture are running their microservices and legacy APIs on multiple platforms — proprietary data centers, legacy platforms, virtual private clouds — at least in transition. That means that although platform-specific security solutions can be a part of their solutions, they inevitably need an option to oversee the entire environment.

In the book, we give a DHARMA implementation example that is completely agnostic of the underlying platform. Here is a summary of that solution: * Two domain hierarchy: An outer domain for servicing external API requests, and an inner domain for servicing private API requests * The outer domain would use OAuth 2.0 with opaque tokens for its access mechanism and JWT's signed with a corporate-issued certificate as its trust mechanism * The signed JWT's would be used as the access mechanism for the inner domain, with network isolation used for the trust mechanism * To make this work, the implementing organization would need to have a certificate management capability, a token management capability, and API intermediaries to enforce the access control policies at the domain boundaries

The same outer/inner domain approach could be implemented entirely inside a Kubernetes cluster, using an Ingress Controller to protect the outer domain boundary, a sidecar service proxy to protect the inner domain boundaries, and native Kubernetes network isolation to enforce trust between inner domain services. For an AWS-only implementation, a public API Gateway could expose the outer domain's boundary endpoints, while the inner domain could publish private endpoints and restrict intra-domain communication via VPC.

Certainly, there are many more examples of how DHARMA can be applied. In addition to these applications, we hope that the thinking behind DHARMA can be applied to help in other areas of microservice architecture beyond web API security.

Non-Functional Domains

In the world of monolithic applications, it was a given that software systems would be run on the platform of choice for each monolith. As software systems become more distributed through microservice architecture, those platform constraints are lifted and system designers have the option of theoretically selecting the platform service by service. In practice, many organizations are still defaulting to a single platform and toolset, thus missing out on potential benefits of the new approach. So what is the right way of determining service placement when it comes to platform and tools?

Assuming an organization takes a domain-driven approach to designing their system, they will have a set of business-aligned domains that could be a starting point for grouping services in a runtime context. However, platform considerations are usually non-functional, such as availability, scalability, security and reliability. Business alignment can be an indicator for how much communication there is between services, and that is tied to performance. DHARMA provides another view that can help determine service disposition at runtime. Enumerating the domains of a system based on other dimensions--such as performance tiers, availability tiers, and data sensitivity--could help system designers optimize their service platform(s) selection.

Event-based Communication

Web APIs are typically implemented using the request-reply pattern. Request-reply can be utilzed for queries and commands, and can be extended by techniques such as webhooks to handle event notifications. However, microservice implementers also use of purely asynchronous protocols like Apache Kafka. Asynchronous communication inverts some roles in the message exchange, and this has implications when it comes to security. As a next step in the defintion of DHARMA, we will work on adapting the DHARMA concepts to asynchronous messaging.

We are excited to continue exploring the possibilities that DHARMA presents, and look forward to collaborating with others in the industry on its concepts and applications.