Управление доступом

Planeon разделяет два разных вопроса: кто может администрировать платформу (RBAC — пользователи, группы, роли, права) и кто может пользоваться конкретным пулом рабочих столов (доступ/entitlement). Оба управляются из одного места — страницы Пользователи и доступ (/users), — но независимы друг от друга: конечный пользователь может иметь доступ к нескольким пулам, вообще не имея прав администратора, а права администратора сами по себе не дают доступа к рабочим столам ни одного пула.

Модель: пользователи, группы, роли и права

У Planeon нет локального хранилища паролей. Каждый пользователь — это проекция личности из вашего OIDC-провайдера идентификации (см. Провайдеры идентификации) — ничего не нужно создавать вручную, прежде чем кто-то сможет войти. На странице Пользователи и доступ четыре вкладки:

• Пользователи — локальные проекции людей, которые уже входили через вашего провайдера идентификации, доступные только для чтения.
• Группы — локальные группы, которые вы создаёте, плюс встроенные группы, описанные ниже. Выбор Управлять доступом на группе открывает один диалог, где сразу задаются и её роли, и её участники. Фактические участники группы включают и тех, кого вы добавили напрямую, и всех, кто синхронизирован через OIDC-привязку — последние показаны с неактивными флажками, поскольку источник их членства — claim провайдера идентификации, а не этот экран.
• Роли и права — пользовательские роли, которые вы собираете из встроенного списка прав ниже. Встроенные роли доступны только для чтения как стандартные значения продукта.
• OIDC-привязки — отображение claim'ов групп вашего провайдера идентификации на локальные группы; см. OIDC-привязки групп.

Planeon поставляется с четырьмя встроенными ролями: platform_admin (полный доступ к платформе, авторизации и настройкам), platform_operator (доступ к повседневным операциям, без управления авторизацией и настройками), platform_viewer (доступ на чтение по всей платформе) и end_user (вообще без прав администратора — доступ к рабочим столам для этой роли целиком идёт через доступ к пулу, а не через RBAC. Пользователь только с ролью end_user не видит навигации администратора и сразу попадает в портал пользователя). Также поставляются три встроенные группы — builtin:platform-admins, builtin:platform-operators и builtin:platform-readers — каждая уже привязана к соответствующей встроенной роли.

Встроенные права

Это ключи прав, из которых собираются пользовательские роли — список доступен на вкладке Роли и права → Системные права:

Право	Что даёт
platform:read	Чтение метаданных и состояния здоровья платформы.
platform:admin	Административный override для всех возможностей платформы — глобальная выдача этого права обходит любую другую проверку.
auth:read	Чтение пользователей, групп, ролей и привязок.
auth:manage	Управление пользователями, группами, ролями и OIDC-привязками групп.
settings:read	Чтение настроек платформы.
settings:manage	Управление настройками платформы.
pve:read	Чтение состояния интеграции с Proxmox.
pve:manage	Управление настройками и действиями интеграции с Proxmox.
pools:read	Чтение пулов рабочих столов.
pools:manage	Управление пулами рабочих столов.
vms:read	Чтение виртуальных машин.
vms:manage	Управление виртуальными машинами.
sessions:read	Чтение сессий.
sessions:manage	Управление сессиями.
templates:read	Чтение шаблонов.
templates:manage	Управление шаблонами.
jobs:read	Чтение фоновых заданий.
jobs:manage	Управление фоновыми заданиями (например, повтор сбойного задания).
audit:read	Чтение журнала аудита.

Каждая привязка роли, которую вы создаёте сегодня, действует на всю платформу: назначение роли группе или пользователю выдаёт права этой роли глобально. Модель авторизации заложена с расчётом на сужение выдачи до отдельного кластера или пула, но такие ограниченные выдачи зарезервированы для будущих версий — создать их из консоли сегодня нельзя.

OIDC-привязки групп

Claim группы от вашего провайдера идентификации сам по себе не является авторизацией — доступ появляется только после того, как вы привяжете его значение к локальной группе на вкладке OIDC-привязки. Каждая привязка сопоставляет одно значение claim'а одной локальной группе: например, привязка имени claim'а groups, значения claim'а corp-vdi-admins к локальной группе builtin:platform-admins означает, что любой пользователь, в токене которого в claim'е groups есть значение corp-vdi-admins, начиная со следующего входа считается участником builtin:platform-admins — и наследует роли этой группы. Привязки редактируются как черновой список с явным действием Сохранить привязки, поскольку сохранение заменяет весь набор привязок целиком.

Членство, синхронизированное таким образом, актуализируется при каждом входе: если значение claim'а позже пропадает из токена пользователя, соответствующее OIDC-членство в группе снимается при следующем аутентифицированном запросе. Локальные членства, назначенные вами напрямую на вкладке Группы, этой синхронизацией никогда не затрагиваются.

Доступ к пулу для группы

Возможность администрировать платформу и возможность пользоваться рабочими столами пула — разные права. Чтобы дать группе конечных пользователей право запрашивать рабочие столы из пула, откройте Пулы рабочих столов, выберите Доступ к пулу на строке нужного пула, затем Добавить доступ и выберите пользователя или группу из вашего каталога. Каждый участник группы, которой предоставлен доступ, — включая тех, кто синхронизирован через OIDC-привязку, — получает право запросить рабочий стол из этого пула. Именно так быстрый старт даёт вашей первой группе доступ, и это никак не связано с ролями RBAC: группа вообще без прав администратора всё равно может иметь доступ к пулу — это обычная форма для ваших реальных пользователей рабочих столов.

Первый администратор

Прежде чем всё вышеописанное появится, кто-то должен получить возможность войти и это настроить. Этот шаг bootstrap описан в разделе «Первый вход» руководства по установке — смотрите его там, а не здесь, поскольку это часть первичного разворачивания, а не текущая задача управления доступом.