Я хочу построить распределенную систему контроля доступа для микросервисной платформы. Я рассматриваю возможность использования Mongodb в качестве технологии базы данных. Мои цели проектирования системы таковы:
Обеспечение соблюдения политики следует распространять - если какой-либо конкретный пункт применения политики (PEP) испытывает простои, то только приложение, которое PEP должны быть затронуты.
Решения о политике * следует распространять - Мы не хотим, чтобы вся платформа испытывала простои, потому что центральная точка принятия решения о политике (PDP) испытываете простои. Мы только хотим, чтобы это влияло на приложение, которое оно обслуживает.
Администрирование политики должно быть централизованным - Создание централизованного интерфейса администрирования политики предоставляет возможность для любой системы (включая пользовательский интерфейс), чтобы понять, какими правами обладает индивид, и, установив общий интерфейс, он позволяет нам легче проводить аудит изменений для доступа по всей платформе.
Информация о политике ( context) распространяется - Мы не можем выбрать это, если создаем платформу распределенного микросервиса. Мы можем централизовать поиск дополнительного контекста путем объединения данных, необходимых для принятия решений по управлению доступом, в одном месте, но источники данных по-прежнему распределены.
Я рассмотреть возможность создания системы, подобной той, которая показана ниже. Идея заключается в том, что политики доступа управляются центральным API-интерфейсом администратора политик. Этот API-интерфейс управляет политиками, которые сохраняются в кластере mongodb с поддержкой реплики из трех участников. Мне бы хотелось, чтобы другие API в платформе имели выделенный API-интерфейс policy-query (Point Decision Point), который развернут вдоль него для принятия решений по управлению доступом, относящихся к API. Идея состоит в том, что если какой-либо из параметров policy-query-apis выйдет из строя, это повлияет только на тот API, который он обслуживает.
Я хочу, чтобы изменения в политиках регулировались API администратора политик, и я бы хотел изменения, которые будут реплицированы для каждого экземпляра mon go, который используется каждым из API-адресов policy-query. Я не хочу, чтобы реплики mon go для каждого API-элемента policy-query влияли на запись в первичные файлы .
Мне также не нужна немедленная согласованность данных (менее 5 с c задержка), но я бы хотел, чтобы репликация данных обрабатывалась на уровне базы данных, если это возможно. Технология уже создана, чтобы справиться с этим, и я не хочу заново изобретать колесо на прикладном уровне, если это возможно.
Я просмотрел документацию по членам набора реплик и довольно подробно рассмотрел документация на наборы реплик в пн go. Похоже, что наличие скрытого или отложенного члена вполне подойдет для моего варианта использования. Ты согласен? Кроме того, меня беспокоит ограничение на набор реплик из 50 членов. Поскольку каждая из этих реплик будет служить API на моей платформе, если бы было превышено более 50 микросервисов (что весьма вероятно), как бы я управлял репликацией, как это?
