I’m looking to build a distributed Access Control system for a microservice platform. I’m considering using Mongodb as my database technology. My system design objectives are as follows:
- Policy Enforcement should be distributed - If any given Policy Enforcement Point (PEP) experiences downtime, only the application that the PEP serves should be affected.
- Policy Decisions should be distributed - We don’t want the whole platform to experience downtime because a central Policy Decision Point (PDP) is experiencing downtime. We only want it to affect the application that it serves.
- Policy Administration should be centralized - Creating a centralized policy administration interface provides the ability for any system (including a UI) to understand what rights an individual has, and by establishing a common interface it allows us to more easily audit changes to access across a whole platform.
- Policy Information (context) is distributed - We don’t get to choose this if we are building a distributed microservice platform. We can centralize the retrieval of additional context by aggregating data that is needed to make access control decisions into a single place, but the data sources are still distributed.
I’m considering building a system like the one shown below. The idea is that Access Policies are administered by a central Policy Admin API. This API manages Policies that are persisted to a mongodb cluster with a 3 member replica set backing it. I would like other APIs in the platform to have a dedicated policy-query-api (Policy Decision Point) that is deployed along side it to make Access Control decisions pertinent to the API. The idea is that if any one of the policy-query-apis goes down, only the API that it serves will be affected.
I want changes to Policies to be governed by the Policy Admin API and I would like the changes to be replicated across each mongo instance that is used by each of the policy-query-apis.I don’t want the mongo replicas for each policy-query-api to affect a write to the primaries.
I also don’t need immediate data consistency (less than 5 sec latency), but I would like the data replication to be handled at the database layer if possible. The technology is already built to handle this and I don’t want to reinvent the wheel at the application layer if possible.
I’ve looked at the documentation on Replica Set Members and I’ve pretty thoroughly reviewed the documentation on Replica Sets in Mongo. It seems like having a Hidden Member or Delayed Member would be a good fit for my use case. Do you agree? Also, I’m concerned about the 50 member replica set limit. Since each one of these replicas would serve an API in my platform, if there exceeded more than 50 microservices (which is quite likely) how would I manage replication like this?
