DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Practical Microservices Development Patterns: Sync vs. Async
  • Build a Stateless Microservice With GitHub Copilot in VSCode
  • From Prompt to Running Microservice: ServiceBricks Step-By-Step
  • Dropwizard vs. Micronaut: Unpacking the Best Framework for Microservices

Trending

  • Breaking Bottlenecks: Applying the Theory of Constraints to Software Development
  • Hybrid Cloud vs Multi-Cloud: Choosing the Right Strategy for AI Scalability and Security
  • AI’s Role in Everyday Development
  • Streamlining Event Data in Event-Driven Ansible
  1. DZone
  2. Data Engineering
  3. Data
  4. Applying and Extending DHARMA

Applying and Extending DHARMA

Learn about the DHARMA method for API security in a microservice architecture and opportunities for extending the model.

By 
Matt McLarty user avatar
Matt McLarty
·
Jul. 26, 18 · Tutorial
Likes (2)
Comment
Save
Tweet
Share
4.5K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Software system microservice

Published at DZone with permission of Matt McLarty, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Practical Microservices Development Patterns: Sync vs. Async
  • Build a Stateless Microservice With GitHub Copilot in VSCode
  • From Prompt to Running Microservice: ServiceBricks Step-By-Step
  • Dropwizard vs. Micronaut: Unpacking the Best Framework for Microservices

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: