Администрирование RBAC

На этой странице:

• Введение
• Пользователи
• Роли
• Права доступа
  • Ресурсно-ограниченные права
  • Ограничение доступа к данным по сервисам, хостам и группам сервисов
    • Три измерения области видимости
    • Как комбинируются измерения: объединение (ИЛИ)
    • Разворачивание групп сервисов
    • Как фильтр применяется к источникам данных
    • Объединение прав из нескольких ролей
• Внешние группы
  • Привязка групп LDAP/OIDC
• Журнал аудита

Введение

Администрирование RBAC — раздел платформы Proto Observability для расширенного управления доступом на основе ролей (Role-Based Access Control). Раздел предоставляет единый интерфейс для:

• Управления пользователями — приглашение, активация/деактивация, назначение ролей, сброс пароля
• Управления ролями — создание пользовательских ролей, редактирование существующих
• Настройки прав доступа — матрица разрешений по типам ресурсов и действиям
• Привязки внешних групп — сопоставление групп из внешних провайдеров (LDAP/OIDC) с ролями платформы
• Аудита — просмотр журнала всех действий, связанных с управлением доступом

Как открыть: перейдите в раздел Администрирование RBAC в основном меню навигации платформы.

Пользователи

Вкладка «Пользователи» отображает таблицу всех зарегистрированных пользователей платформы.

Столбцы таблицы:

Возможности:

• Поиск — фильтрация списка по имени или email
• Фильтр по роли — отображение только пользователей с выбранной ролью
• Пригласить пользователя — кнопка для отправки приглашения новому пользователю

Операции с пользователем (доступны через столбец действий):

Роли

Вкладка «Роли» содержит список всех ролей, доступных в платформе.

Роли делятся на два типа:

• Системные роли — предустановленные роли платформы (например, «Администратор», «Пользователь»). Системные роли отмечены специальным индикатором и не могут быть удалены.
• Пользовательские роли — созданные администратором роли для специфических сценариев доступа.

Доступные операции:

• Создание роли — укажите имя и описание для новой роли
• Редактирование роли — изменение имени и описания существующей роли
• Просмотр деталей — подробная информация о роли и связанных разрешениях

Права доступа

Вкладка «Права доступа» отображает матрицу разрешений — какие действия разрешены каждой роли для каждого типа ресурсов.

Структура матрицы:

• Строки — типы ресурсов платформы (дашборды, алерты, сервисы, настройки и другие)
• Столбцы — роли
• Ячейки — действия, разрешенные для данной комбинации роли и типа ресурса (просмотр, создание, редактирование, удаление, администрирование)

Администратор может настроить разрешения для пользовательских ролей, изменяя значения в ячейках матрицы.

Ресурсно-ограниченные права

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

Поддерживаемые типы ресурсов для ограничения по экземпляру:

Как настроить:

1. Откройте редактирование роли на вкладке Роли.
2. В секции прав доступа выберите тип ресурса и действия (просмотр, редактирование и т.д.).
3. Вместо подстановочного значения * (все ресурсы) укажите идентификаторы или имена конкретных ресурсов.
4. Сохраните изменения.

Пользователи с этой ролью получат доступ только к указанным экземплярам. Если для типа ресурса не задано ни одного ограничения, применяется правило «нет доступа».

Ограничение доступа к данным по сервисам, хостам и группам сервисов

Права на типы ресурсов service, host и service_group автоматически применяются ко всем запросам данных, которые выполняет пользователь в интерфейсе платформы. Платформа прозрачно добавляет фильтр по разрешённой области видимости, поэтому любой виджет на дашборде, Traces Explorer, Logs Explorer, Браузер метрик, разделы Инфраструктура → Хосты, Бизнес-приложения и SLO показывают пользователю только разрешённые данные — даже если сам запрос написан без явного фильтра.

Три измерения области видимости

Область видимости складывается из трёх независимых измерений. Каждое измерение можно оставить открытым (доступ ко всем), задать явным списком или не настраивать вовсе:

Для каждого измерения возможны три состояния:

• Доступ ко всем (в интерфейсе — переключатель «Предоставить доступ ко всем …», в правах — ключ *). Снимает ограничение по данным полностью — см. оговорку об объединении ниже.
• Список конкретных значений — доступ только к выбранным сервисам / хостам / группам.
• Не настроено (для роли нет ни одной записи данного типа) — измерение не участвует в фильтрации.

Сопоставление строгое: запись данных без соответствующей метки (например, метрика без метки host) не попадает в выборку по этому измерению.

Как комбинируются измерения: объединение (ИЛИ)

Если у роли настроено несколько измерений, они объединяются по правилу ИЛИ (объединение): пользователь видит данные, которые попадают хотя бы под одно настроенное измерение.

Пример. Роль даёт доступ к сервисам cart, catalogue и к хосту backend-04. Пользователь увидит:

• данные сервисов cart и catalogue — на любом хосте, где эти сервисы работают;
• плюс любые данные хоста backend-04.

Это важно учитывать на страницах, сгруппированных по одному измерению. Например, в Logs Explorer при такой роли будут видны и логи хоста backend-04, и логи сервисов cart/catalogue — даже если эти сервисы работают на другом хосте. Это не сбой фильтрации, а следствие объединения: логи разрешённых сервисов видны везде, где эти сервисы запущены.

Разворачивание групп сервисов

Грант на конкретную группу сервисов (service_group) при загрузке прав разворачивается в набор её сервисов-участников (по данным за последние 30 дней). Благодаря этому группа корректно отображается везде, где данные разделяются по сервисам, а не по группе, — в списке сервисов Traces Explorer, в фильтрах и в проверках доступа к трассам. Открытый грант (service_group = *) не разворачивается — он и так снимает ограничение.

Как фильтр применяется к источникам данных

Поведение для разных категорий пользователей:

• Администраторы (правило {admin, *, *}) и роли с открытым измерением (*) — видят все данные, фильтр не добавляется.
• Пользователи с ограниченной областью видимости — видят объединение (ИЛИ) настроенных измерений.
• Пользователи без прав на область видимости (нет ни одной записи service/host/service_group) — фильтр по данным не добавляется; доступ по-прежнему ограничивается правами на сам раздел (например, право view на logs).

Объединение прав из нескольких ролей

Права в RBAC аддитивны: эффективный доступ пользователя — это объединение всех его ролей, назначенных как напрямую, так и через внешние группы. Ограничивающая роль не может «вычесть» доступ, выданный другой ролью.

Практическое следствие: если пользователю, помимо роли с ограниченной областью видимости, назначена роль с доступом на чтение ко всем ресурсам (например, системная роль «Пользователь» / Viewer с правилом {view, *, *}), то открытое измерение этой роли снимает ограничение — пользователь увидит все данные.

Внешние группы

Вкладка «Внешние группы» позволяет настроить автоматическое назначение ролей платформы на основе групп из внешних провайдеров учетных записей (LDAP, OpenID Connect).

Принцип работы:

При входе пользователя через SSO (LDAP или OIDC) платформа определяет его группы во внешнем провайдере. Если для этих групп настроено сопоставление, пользователю автоматически назначаются соответствующие роли платформы.

Доступные операции:

• Просмотр сопоставлений — таблица существующих привязок «внешняя группа — роль платформы»
• Добавить сопоставление — диалоговое окно для создания новой привязки: укажите имя внешней группы и выберите роль платформы

Привязка групп LDAP/OIDC

В таблице сопоставлений каждая запись имеет источник (source_type), который определяет, откуда ожидается имя группы:

Настраиваемое имя claim для OIDC

По умолчанию платформа ожидает, что OIDC-провайдер передаёт список групп пользователя в claim groups. Если ваш провайдер использует другое имя (например, roles, ldap_groups, cognito:groups), его можно указать в настройках Keycloak — платформа корректно извлечёт группы из произвольного claim.

Журнал аудита

Вкладка «Журнал аудита» предоставляет хронологический лог всех действий, связанных с управлением доступом в платформе.

Информация о каждом событии:

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