Как лучше организовать управление доступом в микросервисной архитектуре?

Question

[Дмитрий Степанов]

Всем привет, возник у нас небольшой холивар на работе как лучше реализовать управление ролями и правами доступа в микросервисной архитектуре. Суть в следующем:
1. подразумевается взаимодействие сервисов через Kafka
2. для аутентификации есть Keycloak
3. хотим сделать централизованной управление ролями и пермишенами в отдельном securityManager
4. у каждого сервиса есть свой набор пермишенов, который хранится в самом сервисе
5. пользователи, роли и группы ролей хранятся в keycloak (так же дублируются в сервисы)
6. связь роли и пермишена хранится в каждом сервисе отдельно

вопрос как лучше реализовать сценарий создания роли если роль должна попасть в сервис и keycloak, а также надо привязать пермишены к роли. Накидал 4 варианта выполнения сценария, но у каждого есть свои плюсы и минусы.



Хотелось бы услышать ваши мысли на тему разных вариантов, их плюсы-минусы. Может кто-то знает как это сделать правильнее или подкинет статей толковых на эту тему?

Comments

[Vladislav]

5. Что значит "дублируются" ? Должно "синхронизироваться" с источником, а источник истины обычно один, особенно в случае когда нужно обновить настройки ролей. поменять права и т.д.

Answer 1

[Вадим]

Сам только учусь - исходя из того что есть в нашем проекте и нашел на инете...

Сделайте так, чтобы Keycloak создавал JWT для авторизации. Т.е. в Keycloak будет не только аутентификация, но и роли\группы хранится. Таким образом Security Manager будет создавать роли в Keycloak (а пермишины? не уверен - может их создавать в базе отдельно), а все последущие коммуникации между сервисами будут включать JWT полученный после аутентификации юзера в Keycloak, т.о. сервисы будут вытаксивать авторизацию из переданного JWT перед выполнением какого-то действия.

Пермишаны наверное можешь хранить отдельно от ролей в какой-то базе - можешь кешировать ее для скорости, т.к. запросов к ней от микросервисов будет много, может даже Redis подойдет.

И да, не совсем понимаю, зачем всегда использовать Кафку - у нас микросервисы некоторые общаются и напрямую по HTTP, можно также и через Grpc. Если в Кубере можешь поставить изоляции - network policies.

Comments

[Вадим]

Дмитрий Степанов ^^^

[Дмитрий Степанов]

Все правильно описано. Тут скорее вопрос в том, как доставлять роль до кейклока (синхронно или нет) и что должно являться мастер-системой для хранения ролей. Нам не надо чтоб каждый сервис видел все роли, значит мы приделаем к нему признак сервиса в кейклоке. Тогда каждый сервис сможет получить список релевантных для него ролей и назначить им пермишены.

Но в этом случае и возникает вопрос, можно создавать роли напрямую в каждом сервисе и отправлять в кейклок для назначения пользователям и группировки. В этом сценарии мы не сможем назначать роли пользователям пока они не придут в кейклок.

Еще можно пойти в обратную сторону: создать роль в кейклоке и ждать, пока они дойдут до сервиса, чтоб назначать пермишены.

[Дмитрий Степанов]

Собственно самые интересные варианты получаются красный и желтый. У каждого есть свои плюсы и минусы. Вот и хочется узнать, может кто-то уже попробовал оба и знает больше подводных камней. Накидал тут схемку последовательности действий в обоих сценариях на коленке (сорян если плохо интерпретируется). Левый сценарий для желтого варианта, правый - для красного.

[Вадим]

Дмитрий Степанов,

а мне кажется "Нам не надо чтоб каждый сервис видел все роли, значит мы приделаем к нему признак сервиса в кейклоке" - это плохое решение. Зачем запись в кейклоке должна зависеть от сервиса - вообще привязывать авторизацию к зависимости от сервиса - неправильно. Авторизация должна быть по ролям и разрешениям. Сделайте отдельно сервис авторизации - как отдельный сервис (svc) в кубернетесе. Все запросы будут проходить черезе него.

[Вадим]

https://authguidance.com/api-authorization-design/