Платформенное управление и системный администратор
Системный администратор отвечает за глобальные настройки всего развёртывания aihelpme.ru, очередь задач, платформенные API Key и межпространственный аудит. Owner пространства отвечает за отдельное рабочее пространство; обе роли назначаются раздельно. Описание ролей пространства см. в Тенанты, пользователи и авторизация.
Области управления обеих ролей следующие:
| Owner пространства | Системный администратор | |
|---|---|---|
| Область действия | Отдельное рабочее пространство | Всё развёртывание |
| Способ назначения | Получается при создании пространства или передаётся прежним Owner | Назначается существующим системным администратором; первый администратор задаётся через переменную окружения |
| Что администрирует | Участники пространства, модели, базы знаний, интеграции, аудит пространства | Глобальные системные настройки, очередь задач, платформенные API Key, межпространственный аудит, сброс паролей пользователей |
| Автоматически совмещается | — | Нет: быть Owner в некотором пространстве не означает быть системным администратором, и наоборот |
Межпространственный доступ к данным управляется отдельно через CanAccessAllTenants. Статус системного администратора не даёт автоматического права доступа к содержимому баз знаний других пространств.
Настройка первого системного администратора
При новом развёртывании сначала нужно настроить первого системного администратора:
- Сначала зарегистрируйте учётную запись обычным способом;
- Задайте для сервиса app
WEKNORA_BOOTSTRAP_SYSTEM_ADMIN_EMAIL=<email этой учётной записи>и перезапустите; - При запуске, только если в развёртывании ещё нет системного администратора, пользователь с этим email становится системным администратором.
Процесс начальной настройки только повышает права уже существующей учётной записи. Если email ещё не зарегистрирован, записывается предупреждение, и проверка повторяется при следующем перезапуске; ошибка конфигурации не блокирует запуск сервиса. Если в развёртывании уже есть системный администратор, эта переменная больше не выдаёт права.
В дальнейшем системных администраторов можно добавлять и снимать через интерфейс. Нельзя снять себя или последнего системного администратора. Соответствующие интерфейсы — POST /system/admin/promote и /revoke; повторное снятие с пользователя, не являющегося администратором, возвращает 200, а запись аудита с changed=false указывает, что изменения прав не произошло.
Использование платформенной консоли
Системный администратор может просматривать в боковой панели «Настройки» следующие разделы управления:
| Раздел | Назначение | Интерфейс |
|---|---|---|
| Системные настройки | Глобальные переключатели среды выполнения (режим регистрации, политика пространств, параллелизм, белый список SSRF и т. д.), применяются согласно правилам вступления в силу, см. таблицу настроек ниже | GET/PUT/DELETE /system/admin/settings[/:key] |
| Каталог моделей | Просмотр моделей каталога и их источников, редактирование, добавление моделей или массовое изменение через JSON (вступает в силу при сохранении), восстановление по истории версий; подробнее см. Управление каталогом моделей | /system/admin/model-catalog* |
| Очередь задач | Просмотр текущего накопления очередей asynq, повторов/архивирования/удаления по каждой задаче, массовая очистка архивных задач; в режиме Lite возвращает available=false | /system/admin/runtime/queues* |
| Платформенные API Key | Ключи области platform для автоматизации контрольной плоскости; возможности включают system_tenants_read/manage, system_settings_read/manage, system_runtime_read/manage, system_audit_read | /system/admin/api-keys |
| Системный журнал аудита | События уровня платформы с tenant_id = 0 (изменение настроек, повышение/снятие администратора, операции с очередями и т. п.). Интерфейс аудита уровня пространства фильтрует по tenant и не показывает эти строки | GET /system/admin/audit-log |
Системный администратор также может выполнять следующие действия:
- Сброс пароля пользователя (
POST /system/admin/users/reset-password): заменяет локальный пароль целевого пользователя и отзывает все его сессии. Нельзя сбросить пароль себе — самостоятельная смена пароля по-прежнему требует указания старого пароля; - Массовое применение квоты хранения по умолчанию (
POST /system/admin/tenants/apply-default-storage-quota): записывает текущую квоту по умолчанию во все существующие пространства. Эта операция обновляет данные квот уже существующих пространств.
Управление пользователями платформы
Раздел «Настройки → Системные настройки → Управление пользователями» сводит воедино пользователей всего развёртывания: здесь можно создавать учётные записи, включать и отключать их, сбрасывать пароли, а также выдавать и отзывать статус системного администратора. Отключение учётной записи немедленно отзывает её сессию входа; нельзя отключить себя или последнего всё ещё включённого системного администратора. Список пользователей не содержит паролей или их хешей.
Режим регистрации бывает трёх видов: открытая регистрация, регистрация только по приглашению и запрет регистрации; invite_only соответствует запрету регистрации, а для создания учётной записи по приглашению выбирается invite_register. OIDC и создание учётных записей администратором не ограничены режимом регистрации по паролю.
Создание пользователя
Начиная с v0.8.2 системный администратор может в «Настройки → Системные настройки → Управление пользователями» нажать «Создать пользователя», чтобы завести локальную учётную запись: укажите имя пользователя (2–50 символов) и email, оставьте включённым «Автоматически генерировать случайный пароль» или отключите его и введите вручную пароль, соответствующий политике паролей. Подходит для сценариев, когда после отключения публичной регистрации администратор заводит учётные записи централизованно. Распределение пространств следует auth.default_tenant_mode: create_personal создаёт личное пространство, tenantless ожидает присоединения пользователя к пространству.
Автоматически сгенерированный пароль отображается только в результате данного создания — полные данные учётной записи следует скопировать сразу же; до подтверждения диалог нельзя закрыть, а после закрытия открытый текст больше не запрашивается. Каждое создание записывается в системный журнал аудита (system.user_created). При дублировании идентичности возвращается существующий пользователь без смены пароля; если email и имя пользователя указывают на разных пользователей, создание отклоняется. Интерфейс см. в Системном API.
Создание пользователя и начальная настройка первого администратора — разные операции: bootstrap по-прежнему только повышает права существующего пользователя и не создаёт учётную запись.
Справочник по настройкам среды выполнения
Поддерживаемые настройки среды выполнения можно изменять в консоли. Значения настроек в базе данных имеют приоритет над переменными окружения, и большинство вступают в силу немедленно; для настроек, влияющих на новые ресурсы или требующих пересоздания среды выполнения, руководствуйтесь пояснениями в таблице.
| Ключ | Тип | По умолчанию | Когда вступает в силу |
|---|---|---|---|
auth.registration_mode | self_serve / invite_register / invite_only | self_serve | немедленно |
auth.default_tenant_mode | create_personal / tenantless | create_personal | влияет только на новых пользователей, регистрируемых позже |
tenant.self_service_creation_enabled | bool | true | немедленно |
tenant.max_owned_per_user | int | 10 (0 = использовать встроенное значение по умолчанию, отрицательное = отключить лимит) | считывается при каждом создании пространства |
tenant.default_storage_quota_gb | int | 10 | считывается только при создании пространства, не записывается обратно в существующие пространства |
tenant.auto_create_api_key | bool | false | считывается при каждом создании пространства |
ssrf.whitelist | список строк | пусто | немедленно (SSRF_WHITELIST_EXTRA по-прежнему поддерживается только стороной развёртывания и здесь не переопределяется) |
asynq.core/postprocess/enrichment/maintenance/shared/wiki_concurrency | int | см. Систему асинхронных задач | пересборка соответствующих worker pool |
model.max_concurrency | int | 32 | немедленно |
Следующие переключатели также следуют правилу приоритета базы данных:
| Ключ | По умолчанию | Назначение |
|---|---|---|
auth.complex_password_enabled | false | новые регистрации/новые пароли требуют букв в обоих регистрах, цифр и специальных символов |
tenant.auto_accept_invitation | false | при приглашении уже зарегистрированного пользователя по email членство записывается напрямую |
sandbox.docker_enabled | false | открывает конфигурацию Docker-песочницы и создание экземпляров |
tenant.auto_create_api_key по умолчанию отключён. Интеграции, зависящие от ответа регистрации старой версии, могут включить этот переключатель совместимости, чтобы новое пространство автоматически создавало full-access Key и возвращало его в открытом виде.
Сброс настроек среды выполнения
После сохранения настройки в консоли изменение соответствующей переменной окружения не перезапишет значение в базе данных. Если конфигурация не вступает в силу, сначала проверьте настройки среды выполнения; сброс (DELETE /system/admin/settings/:key) удаляет переопределяющее значение в базе данных и восстанавливает использование переменной окружения или встроенного значения по умолчанию.
Связанные документы
- Четыре уровня ролей в пространстве и API Key: Тенанты, пользователи и авторизация
- Топология очередей и worker pool: Система асинхронных задач
- Журнал аудита и трассировка: Наблюдаемость и аудит
- Список интерфейсов: API системы и платформенного управления
Справочник по реализации
cmd/server/bootstrap.go: начальная настройка первого системного администратора.frontend/src/config/settingsAccess.ts: разделы платформенных настроек.internal/application/service/system_setting.go: реестр настроек среды выполнения.