UncategorizedгаджетыНовостиразработчиктехнология

Slack подробно описывает свою новую архитектуру управления ролями

Slack недавно опубликовал подробное описание программной архитектуры своей новой системы управления ролями. Slack нужно было создать систему, которая была бы более гибкой, чем та, которая была у нее раньше. Он создал настраиваемую контейнерную службу разрешений на основе Go, которая интегрируется с существующими системами через gRPC. В результате администраторы клиентов теперь могут иметь детальный контроль над тем, что могут делать их пользователи.

Инженеры Slack Джейк Байман, Айш Радж Дахал и Хосе М. Медина объясняют мотивацию создания новой системы управления ролями:

Стандартные типы ролей, которые мы предлагали клиентам, были слишком широкими, и делегирование общей роли администратора может предоставить кому-то слишком большие полномочия – что, если вы хотите, чтобы только конкретный пользователь мог управлять определенными каналами? Когда вы сделаете их администраторами, они смогут выполнять самые разные действия, выходящие за рамки намеченной цели. (…) Нам нужно было создать систему, которая была бы более гибкой и позволяла детализированные разрешения.

Slack решил создать систему управления доступом на основе ролей (RBAC), в которой администраторы определяют роли, которые представляют собой набор разрешений для действий в системе. Затем они предоставляют пользователям одну или несколько из этих ролей в определенном контексте или сущности (организации, рабочей области и т. Д.). Slack всегда выполняет авторитетную проверку с помощью службы разрешений, когда пользователь предпринимает действия, чтобы убедиться, что пользователь может выполнить это действие.

С другой стороны, отображение в клиенте Slack основано на неавторизованной копии набора разрешений. Бэкэнд поддерживает этот набор разрешений в пограничном кэше Slack Flannel и обновляет его почти в реальном времени. Клиент считывает информацию о разрешениях из этого кеша, чтобы оптимизировать время задержки.

Источник: https://slack.engineering/role-management-at-slack/

Обратная совместимость была важным фактором для слабых инженеров. Чтобы снизить риск развертывания системы разрешений таким образом, чтобы это мешало работе пользователей, инженеры Slack выбрали схему поэтапного развертывания. Во-первых, они создали петлевую службу gRPC, которая находилась внутри веб-приложения Slack. Они внедрили это изменение в свое внутреннее рабочее пространство, а затем для пилотных клиентов.

Как только они установили, что это изменение было безопасным, они начали читать фактическую внешнюю службу в «темном режиме». В этом режиме они считывают результат проверки разрешений как новой службы, так и существующего веб-приложения, но без использования результата новой службы. Если результаты не совпадают, они поднимут тревогу для дальнейшего расследования. Когда они были достаточно уверены в новой услуге, они переключились на чтение из нее в «легком режиме», используя исключительно ее результаты как источник истины.

Информация о ролях сохраняется в хранилище данных Vitess. Инженеры Slack заявляют, что они «предпочли, чтобы наша служба разрешений считывала и записывала из того же хранилища Vitess, которое используется нашим монолитом веб-приложений». Они приняли это проектное решение, чтобы иметь единое централизованное хранилище данных и избежать дрейфа данных. База данных Vitess действует как источник истины для всей системы.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button