Управление доступом (RBAC)
Role Binding — механизм управления рольями с параметрами их области действия
Обзор
Доступ к API управления и веб-интерфейсу Meridian выдаётся привязками ролей (Role Binding). Привязка связывает пользователя со встроенной ролью в определённой области: на весь шлюз, внутри заказчика, команды или пользователя.
Одному пользователю можно выдать несколько привязок. Например, администрировать одного заказчика и только просматривать данные другого. Права всех привязок пользователя складываются.
Что это даёт:
- Делегирование администрирования. Заказчик сам управляет своими командами, виртуальными ключами и бюджетами, не получая доступа к настройкам всего шлюза.
- Наследование прав. Роль, выданная заказчику, действует на все его команды и их виртуальные ключи.
- Разделение обязанностей. Отдельные роли для просмотра, управления пользователями и управления бюджетами.
- Интеграция с каталогом. Привязки можно получать из групп и атрибутов LDAP.
Привязки ролей управляют доступом к API управления и веб-интерфейсу. Запросы к моделям по-прежнему авторизуются виртуальным ключом.
Ключевые понятия
| Понятие | Что это |
|---|---|
| Роль | Встроенный набор разрешений, например s.admin. Роли заданы в продукте и не редактируются. Собственные роли создать нельзя. |
| Область действия | Где действует роль: весь шлюз (global), заказчик (customer), команда (team) или пользователь (user). |
| Привязка роли | Запись «пользователь + роль + область». Привязку нельзя изменить: чтобы сменить роль или область, удалите привязку и создайте новую. |
| Наследование | Привязка действует в своей области и во всём, что в неё входит. |
Области действия и наследование
Области образуют иерархию: весь шлюз → заказчик → команда. Виртуальный ключ принадлежит команде, заказчику или никому.
| Область | Где действует привязка |
|---|---|
global | Весь шлюз. |
customer | Заказчик, все его команды и их виртуальные ключи. |
team | Команда и её виртуальные ключи. |
user | Только профиль пользователя. Не распространяется на виртуальные ключи, бюджеты, лимиты и правила маршрутизации. |
Некоторые разрешения действуют только на определённых уровнях:
- Создание команд доступно на уровне всего шлюза и заказчика, но не команды.
- Удалить можно только нижестоящую область. Администратор заказчика не может удалить своего заказчика — это может сделать только тот, у кого права выше.
- Чтение шире изменения. Администратор команды видит правило маршрутизации родительского заказчика, но не может его изменить. Глобальные правила маршрутизации и лимиты моделей видны всем пользователям.
Встроенные роли
Каталог ролей — Governance → Roles. Строка раскрывается и показывает разрешения роли на каждом уровне.
Глобальные роли
Выдаются только на весь шлюз.
| Роль | Назначение | Что может |
|---|---|---|
g.admin | Глобальный администратор | Всё: кластер, провайдеры и ключи, плагины, MCP, наблюдаемость, LDAP, каталог моделей, аудит, привязки ролей. |
g.viewer | Просмотр всего шлюза | Чтение всех разделов, кроме административных, включая кластер, провайдеров, аудитные логи и привязки ролей. |
g.user-manager | Управление пользователями и governance | Просмотр всего шлюза, а также управление заказчиками, командами, пользователями и виртуальными ключами. |
g.budget-manager | Управление бюджетами | Просмотр всего шлюза, а также изменение бюджетов и rate limit'ов. |
Роли в области
Выдаются внутри заказчика, команды или пользователя.
| Роль | Области | Что может |
|---|---|---|
s.admin | заказчик, команда, пользователь | Администрирование области: команды, виртуальные ключи, бюджеты, rate limit'ы, правила маршрутизации, просмотр логов, привязки ролей внутри области. |
s.user-manager | заказчик, команда | Просмотр области, а также управление командами и пользователями. |
s.budget-manager | заказчик, команда | Просмотр области, а также изменение бюджетов и rate limit'ов. |
s.viewer | заказчик, команда, пользователь | Просмотр области: заказчик, команды, виртуальные ключи, бюджеты, лимиты, правила маршрутизации, логи. |
На уровне команды у s.admin нет прав на заказчика и на создание и удаление команд. На уровне пользователя роль позволяет в основном управлять привязками этого пользователя.
Создание пользователей, изменение их данных и старых ролей, а также лимиты моделей требуют прав на весь шлюз. Роли в области эти операции не открывают.
Кто может выдавать привязки
Создавать и удалять привязки может администратор — g.admin или s.admin — в целевой области или выше неё.
| Роль вызывающего | Где может управлять привязками |
|---|---|
g.admin | В любой области, включая глобальные роли. |
s.admin у заказчика | У этого заказчика и в его командах. |
s.admin у команды | Только в этой команде. |
s.admin у пользователя | Только в области этого пользователя. |
Следствия:
- Глобальные роли выдаёт только глобальный администратор.
- Роли не ранжируются внутри области. Администратор заказчика может выдать
s.adminдругому пользователю у своего заказчика. - Администратор заказчика не управляет областью пользователя. Привязки в области
userвыдаёт глобальный администратор илиs.adminэтого пользователя. - Нельзя отозвать собственную административную привязку, если только она даёт вам права администратора в этой области. Её удаляет другой администратор.
- Глобальную привязку
g.adminпользователяadminудалить нельзя.
Управление привязками
Привязки управляются на странице Governance → Role Bindings. Список фильтруется по области, заказчику, команде, пользователю и роли. Пользователь видит только привязки в доступных ему областях.
Выдать роль:
- В блоке Add Role Binding выберите пользователя в поле User.
- В поле Role выберите роль.
- В поле Scope Type выберите область: Global, Customer, Team или User.
- В поле Scope Entity выберите заказчика, команду или пользователя. Для Global поле не заполняется.
- Нажмите Add Binding.
Если роль нельзя выдать в выбранной области, форма сообщит об этом до отправки.
Отозвать роль: наведите курсор на строку, нажмите значок удаления и подтвердите удаление.
На страницах заказчика и команды блок Members показывает выданные в этой области роли: роль, пользователя, кто и когда выдал. Блок только для просмотра.
Выдать роль:
curl -X POST http://localhost:8080/api/auth/rbac/bindings \
-H "Content-Type: application/json" \
-d '{
"user_id": "550e8400-e29b-41d4-a716-446655440000",
"role_name": "s.admin",
"scope_type": "customer",
"scope_id": "customer-acme"
}'Для области global поле scope_id оставляется пустым. Ответ 201 содержит привязку. Если у пользователя есть старая глобальная роль, в ответе будет поле warning — см. Старые глобальные роли.
Список привязок:
curl "http://localhost:8080/api/auth/rbac/bindings?customer_id=customer-acme&role_name=s.admin&limit=50"| Параметр | Описание |
|---|---|
user_id, role_name, customer_id, team_id, source | Фильтры. Можно передать несколько значений. |
scope_type | Типы областей через запятую. |
scope_id | Идентификатор области. |
offset, limit | Пагинация. По умолчанию limit — 50, максимум — 500. |
Ответ: { "items": [...], "total": N, "offset": 0, "limit": 50 }. Результат ограничен областями, доступными вызывающему.
Отозвать роль:
curl -X DELETE http://localhost:8080/api/auth/rbac/bindings/{binding_id}Каталог ролей и свои права:
| Эндпоинт | Назначение |
|---|---|
GET /api/auth/rbac/roles | Встроенные роли, их области и разрешения на каждом уровне. |
GET /api/auth/rbac/me | Свой профиль: старая роль и привязки с разрешениями. |
GET /api/auth/rbac/visible-scopes | Доступные вызывающему области и тип доступа: администратор или просмотр. |
Ошибки:
| Код | Причина |
|---|---|
400 | Неизвестная роль, роль нельзя выдать в этой области, неизвестный заказчик, команда или пользователь, scope_id не соответствует области. |
403 | Нет прав администратора в целевой области; попытка отозвать собственную административную привязку; попытка удалить защищённую привязку g.admin. |
409 | У пользователя уже есть эта роль в той же или охватывающей области. |
Старые глобальные роли
До появления привязок каждому пользователю назначалась одна глобальная роль. Эти роли сохранены для совместимости и соответствуют глобальным привязкам:
| Старая роль | Соответствует |
|---|---|
admin | g.admin |
auditor | g.viewer |
user_manager | g.user-manager |
none | Нет глобальных прав: доступ только через привязки ролей |
Права старой роли складываются с привязками. Привязка в области не ограничивает пользователя со старой ролью admin, auditor или user_manager: он сохраняет глобальный доступ.
Чтобы пользователь работал только в своей области, установите ему роль None (scoped access via role bindings). При создании привязки для пользователя со старой глобальной ролью веб-интерфейс и API показывают предупреждение.
Старая роль задаётся при создании пользователя и меняется на странице Governance → Roles & Permissions. В форме создания пользователя по умолчанию выбрана роль None. Изменение старой роли:
- требует глобального права на изменение пользователей, а назначение ролей
admin,auditorиuser_manager— прав глобального администратора; - сбрасывает все сессии пользователя;
- недоступно для собственной учётной записи;
- не может оставить шлюз без администратора.
Управление бюджетами в областях
Параметр authz.budget_management_mode определяет, могут ли области менять свои бюджеты сами:
{
"authz": {
"budget_management_mode": "self-management"
}
}| Режим | Кто может менять бюджет своей области |
|---|---|
self-management | Заказчик, команда и пользователь. Значение по умолчанию. |
self-management-team-level | Заказчик и команда. |
self-management-customer-level | Только заказчик. |
pull-down-only | Никто: бюджет задаёт только вышестоящая область. |
Ограничение действует, когда роль выдана в той же области, что и бюджет. Вышестоящая область может менять бюджеты нижестоящих всегда. Изменение режима требует перезапуска.
Привязки из LDAP
При синхронизации с LDAP-каталогом привязки создаются автоматически из групп пользователя и из его атрибута со значениями вида global:<роль>, customer:<псевдоним>:<роль> или team:<псевдоним>:<роль>.
Синхронизация управляет только своими привязками и не трогает выданные вручную. Привязку из LDAP, удалённую вручную, следующая синхронизация восстановит: отзывайте такие роли в каталоге. Подробнее — LDAP-каталог.
Применение изменений
- Изменение привязок применяется почти сразу на всех узлах кластера. Если сигнал об изменении потерян, права обновятся не позже чем через 5 минут.
- Изменение привязок не завершает сессии пользователя. Изменение старой роли завершает.
- Решения о доступе можно записывать в журнал. Подробнее — Аудитные логи.
Пример: делегирование администрирования заказчику
Задача: сотрудник заказчика Acme управляет командами, ключами и бюджетами Acme, а финансовый аналитик только просматривает команду acme-research.
Создайте пользователей со старой ролью None.
На странице Role Bindings выдайте сотруднику роль s.admin в области Customer → Acme.
Выдайте аналитику роль s.viewer в области Team → acme-research.
Сотрудник Acme видит только своего заказчика, может создавать его команды и виртуальные ключи, менять бюджеты и сам выдавать роли внутри Acme. Аналитик видит только команду acme-research и её виртуальные ключи, без права изменений.
Дальше
- Виртуальные ключи — заказчики, команды и ключи, к которым применяются роли.
- Бюджеты и лимиты — бюджеты, которыми управляют роли в областях.
- LDAP-каталог — автоматическая выдача привязок из каталога.
- Аудитные логи — журнал решений о доступе.
Телеметрия
Полноценный мониторинг шлюза Meridian на основе Prometheus с кастомными метриками и метками. Автоматический сбор HTTP-метрик и метрик upstream-провайдеров без влияния на латентность запросов.
LDAP-каталог
Вход по учётным записям корпоративного каталога и автоматическая синхронизация ролей Meridian с группами и атрибутами LDAP. Настройка подключения в config.json, правила сопоставления и журнал синхронизаций в панели управления.