Система управления на основе распределенной политики - PullRequest
0 голосов
/ 22 апреля 2020

Я пытаюсь придумать архитектуру авторизации для распределенной микросервисной платформы. Мои цели разработки заключаются в следующем:

  • Обеспечение применения политики должно распространяться - причина этого в том, что если какой-либо конкретный пункт применения политики (PEP) испытывает простои, то должно быть затронуто только приложение, которое обслуживает PEP. , Централизованный PEP (например, такой, который запрашивается шлюзом API) может привести к полному времени простоя системы, если он выйдет из строя. Если целью платформы является дезагрегирование и распределение с надежностью и отказоустойчивостью, централизованный PEP противоречит этой общей цели системы.
  • Политические решения должны распространяться - причина этого аналогична приведенной выше. Опять же, мы не хотим, чтобы вся платформа переживала простои, потому что центральная точка принятия решений (PDP) переживает простои. Мы только хотим, чтобы это влияло на приложение, которое оно обслуживает.
  • Администрирование политики должно быть централизованным. Создание централизованного интерфейса администрирования политики дает возможность любой системе (включая пользовательский интерфейс) понять, какими правами обладает человек, а установление общего интерфейса позволяет нам легче проводить аудит изменения для доступа через всю платформу.
  • Информация о политике (контекст) распространяется. Мы не можем выбрать ее, если создаем платформу распределенного микросервиса. Мы можем централизовать извлечение дополнительного контекста, объединяя данные, необходимые для принятия решений по управлению доступом, в одном месте, но источники данных по-прежнему распределены.

Если администрирование политик централизовано, но Решения и принудительное применение политики распространяются, а это означает, что для репликации информации о политике в PDP необходимо выполнить репликацию политики. Если мы используем pubsub в качестве шаблона для сообщения об изменениях в политиках, то мы получим только изменения / дельты. Если новый PDP подключается к сети (например, новый модуль запускается в Кубернетесе), он не будет иметь историческую нагрузку от событий политики, которые произошли в прошлом. Я ищу идеи о том, как управлять репликацией данных приложения, как это. Когда новый PDP выходит в онлайн, мне нужно, чтобы на него реплицировались данные (например, снимок + потоки изменений). Мне интересно, что люди сделали в этом пространстве? Или кто-нибудь еще сталкивался с подобной проблемой и как вы ее решили?

...