> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Управление тенантами (организации и участники) > Документация по управлению тенантами AgentEye (организации и участники). Единое развертывание AgentEye обслуживает несколько полностью изолированных **организаций** (тенантов), так что один экземпляр может размещать отдельные команды, подразделения или клиентов без утечки данных одного тенанта к другому. Каждая строка данных (события, оценки, сессии, дашборды, сохраненные запросы, оповещения, ключи API и участники) принадлежит ровно одной организации. Первичная изоляция обеспечивается в коде приложения: каждый запрос ограничен своей организацией явными предикатами `org_id`. На ClickHouse — где хранятся большие объемы событий и оценок — это поддерживается строгим принудительным применением на уровне движка: каждая организация получает выделенного пользователя ClickHouse только для чтения с политикой строк для каждой организации, поэтому даже ненадежный аналитический SQL не сможет прочитать строки другого тенанта. На PostgreSQL безопасность на уровне строк добавляет дополнительную защиту на пути только для чтения (`/queries/run`), ограничивая то, что этот путь может видеть, даже если фильтр на уровне приложения когда-то не сработает; собственное подключение для записи на сервере работает от имени владельца таблицы и, таким образом, использует то же ограничение `org_id` на уровне приложения. Жизненный цикл тенанта контролируется оператором, в то время как все, что делают участники в повседневной работе, остается самообслуживанием на дашборде. Организации и их членство создаются и управляются с помощью CLI **`agenteye-orgctl`**, который входит в образ сервера и запускается **внутри существующего пода сервера**. Создание и удаление тенантов намеренно исключены из дашборда и HTTP API: **нет HTTP API и нет кнопки на дашборде** для жизненного цикла тенанта, поэтому это контролируется доступом к оболочке кластера/пода, а не поверхностью приложения. В рамках организации участники работают полностью на дашборде и API: они входят в систему, переключаются между организациями, к которым они принадлежат, управляют своими ключами API, создают дашборды и сохраненные запросы, а также настраивают оповещения для своей организации. Разделение четкое: операторы подготавливают и выводят из строя тенанты и их участников через CLI; участники запускают все внутри тенанта через пользовательский интерфейс. > **Развертыванию с одним тенантом ничего из этого не требуется.** Установка с одним тенантом работает без каких-либо действий оператора. Все данные, пользователи и ключи живут во встроенной организации `default`, которая подготавливается автоматически. Вам нужно это руководство только если вы решите добавить вторую организацию. *** ## Предварительные требования Перед созданием **второй** организации (встроенной организации `default` ничего не требуется): * **PostgreSQL 15+.** Схема членства организации использует внешний ключ с `ON DELETE SET NULL` для списка столбцов, который требует PostgreSQL 15+. Обновите PostgreSQL перед подготовкой второй организации. * **Мощный, стабильный `ORG_CH_SECRET`.** Пароль ClickHouse каждой организации получается как `HMAC(ORG_CH_SECRET, org_id)`, поэтому общеизвестное встроенное значение по умолчанию разработки привело бы к общедоступным учетным данным для каждой организации. `agenteye-orgctl org create` **отказывается работать, пока `ORG_CH_SECRET` не установлен или остается встроенным значением по умолчанию разработки**. Установите свое значение первым (см. [Deployment → переменные окружения](/ru/agenteye/deployment) и на Kubernetes [§2.6 руководства по развертыванию на Kubernetes](/ru/agenteye/kubernetes-deployment#26-multi-tenant-org-isolation-key-optional)). Сохраняйте его одинаковым на всех репликах сервера и не вращайте его небрежно; ротация оставляет каждого пользователя ClickHouse организации без привязки до следующего запуска, который повторно подготовит их. *** ## Запуск CLI `agenteye-orgctl` входит в **тот же образ, что и сервер** (наряду с `agenteye-server`). Вы **не** развертываете отдельный под, Job или Deployment для него; вы выполняете его внутри уже работающего пода сервера, поэтому он читает тот же `DATABASE_URL`, `CLICKHOUSE_URL` и `ORG_CH_SECRET`, которые использует сервер. **Kubernetes:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- agenteye-orgctl ``` **Docker Compose:** ```bash theme={null} docker compose exec server agenteye-orgctl ``` Приведенные ниже примеры показывают простую `agenteye-orgctl ` для краткости; добавьте перед каждой одну из двух приведенных выше строк, которая соответствует вашему развертыванию. *** ## Справочник команд ### Организации | Команда | Что она делает | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `org create --slug --name ` | Создать новую организацию. Отказывает работу, пока `ORG_CH_SECRET` не установлен или остается встроенным значением по умолчанию разработки (установите свое значение, см. Предварительные требования). Подготавливает пользователя ClickHouse организации только для чтения + политику строк. | | `org list` | Список всех организаций (слаг, имя и статус жизненного цикла). | | `org rename --slug --name ` | Изменить отображаемое имя организации. Слаг (используется в URL и ключах) остается без изменений. | | `org delete --slug ` | **Мягкое удаление** организации и удаление её пользователя ClickHouse. Данные **сохраняются**. Это отзывает доступ и освобождает учетные данные ClickHouse для каждой организации, но не стирает события. Может быть отменено оператором; безопасный первый шаг перед очисткой. | | `org purge --slug ` | **Необратимое стирание данных.** Организация должна быть уже `delete`d. Никогда не разрешено для встроенной организации `default`. Используйте только если вы уверены, что данные тенанта должны быть уничтожены. | ### Участники | Команда | Что она делает | | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `member add --org --email [--set ] [--add perm1,perm2] [--remove perm3] [--protected]` | Добавить участника в организацию. Опционально начните с встроенного набора разрешений, затем добавьте/удалите отдельные разрешения. `--protected` закрепляет участника, чтобы дашборд не мог удалить или понизить его в должности (см. ниже). Новый участник получит OTP при первом входе на дашборд. | | `member list --org ` | Список участников организации. Выходные столбцы: `EMAIL`, `SET` (встроенный набор, с которого начал участник, или `-`), `PROT` (защищен ли участник), и `PERMISSIONS` (их эффективные разрешения). Email, показанный с завершающей `*`, является администратором экземпляра; у них есть доступ к каждой организации. | | `member update --org --email [--set ...] [--add ...] [--remove ...] [--protected \| --unprotect]` | Изменить разрешения участника и/или флаг защиты. `--set` заменяет встроенным набором; `--add` / `--remove` корректируют отдельные разрешения; `--protected` / `--unprotect` переключают защиту. Передача только `--protected`/`--unprotect` (без флагов грантов) изменяет только защиту и оставляет существующие разрешения без изменений. | | `member remove --org --email ` | Удалить участника из организации. Отказывает, если участник защищен; сначала отмените для них `--unprotect`. (Человек может быть участником нескольких организаций; это влияет только на названную организацию.) | Человек может быть участником более чем одной организации с **разными** разрешениями в каждой, например администратор в одной организации и только для чтения в другой. Каждое членство администрируется независимо для каждой организации: предоставление или изменение разрешений человека в одной организации не влияет на его членство в какой-либо другой. ### Защищенные участники (администратор организации, которого нельзя удалить) Защита гарантирует, что организация никогда случайно не заблокирует себя от самоуправления. По умолчанию администраторы организации могут добавлять и удалять друг друга через страницу пользователей самообслуживания дашборда, поэтому они могут удалить последнего администратора и оставить организацию без возможности управления. Страница Users: карточка на пользователя дашборда с его адресом электронной почты, предоставленными разрешениями и элементами управления редактирования/отключения Чтобы этого избежать, отметьте одного участника как **защищенного**: ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email owner@acme.example --set admin --protected ``` Защищенного участника **нельзя удалить или понизить в должности через дашборд**; эти действия возвращают ошибку. Только оператор может изменить их, и только через этот CLI: сначала запустите `member update --org acme --email owner@acme.example --unprotect`, затем удалите или понизьте. Это гарантирует, что каждая организация сохраняет как минимум одного администратора, которого её собственные участники не могут заблокировать, сохраняя контроль над тенантом исключительно оператору. Защита **для каждой организации**; защита кого-то в одной организации не влияет на их членство в другой. ### Встроенные наборы разрешений `--set` принимает один из трех встроенных наборов, применяемых для каждой организации: | Набор | Предназначен для | | ----------- | ----------------------------------------------------------------------------------------------------- | | `admin` | Полный доступ в пределах организации, включая управление ключами API и пользователями организации. | | `standard` | Повседневное использование: чтение + запуск запросов, построение дашбордов, подтверждение инцидентов. | | `read-only` | Доступ только для просмотра к данным и дашбордам организации. | Начните с набора с помощью `--set`, затем уточните с помощью `--add` / `--remove` используя маркеры отдельных разрешений, указанные в [API Keys](/ru/agenteye/api-keys). Сами маркеры разрешений идентичны используемым для ключей API. *** ## Практический пример Подготовьте нового тенанта `acme`, добавьте его первого администратора, позвольте ему создать ключ, затем выведите организацию из строя. **1. Создать организацию** (`ORG_CH_SECRET` должен быть уже установлен на мощное, стабильное значение, не оставлен незаданным или встроенным значением по умолчанию разработки): ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org create --slug acme --name "Acme Corp" ``` **2. Добавить первого участника как администратора организации:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email alice@acme.example --set admin ``` Alice получит OTP при первом входе на дашборд. С тех пор она работает полностью в пользовательском интерфейсе под префиксом URL её организации (например, `/acme/sessions`). **3. Создать ключ API для каждой организации (на дашборде):** Оператор **не** создает ключи данных для каждой организации из CLI. Alice (или любой участник организации с `keys:create`) создает ключи сборщика/дашборда для организации `acme` на странице **Keys** дашборда. Каждый ключ, который она создает, автоматически помечается её организацией и может только когда-либо читать или писать данные `acme`. См. [API Keys](/ru/agenteye/api-keys). **4. Отрегулировать участника позже:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member update --org acme --email alice@acme.example --add alerts:write kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member list --org acme ``` **5. Мягко удалить организацию** (отозвать доступ + удалить её пользователя ClickHouse; данные сохранены): ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org delete --slug acme ``` **6. Очистить организацию** (необратимо; только после мягкого удаления; никогда организацию `default`): ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org purge --slug acme ``` На Docker Compose замените каждый префикс `kubectl -n agenteye exec deploy/server --` на `docker compose exec server`. *** ## Распределение ответственности Все, что нужно участнику организации в повседневной работе, является самообслуживанием на дашборде и API, автоматически ограниченное их текущей организацией: * **Ключи API для каждой организации** создаются и управляются участниками организации на дашборде (или через API ключей с ключом, который содержит `keys:create`). CLI **не** создает ключи данных. См. [API Keys](/ru/agenteye/api-keys). * **Переключение организации** встроено в дашборд; участники переключаются между организациями, к которым они принадлежат, из переключателя организации, и страницы с областью организации находятся под `//…`. * **Дашборды, сохраненные запросы, оповещения и все использование данных** происходят полностью в пользовательском интерфейсе и API, ограниченное текущей организацией участника. Оператор, используя `agenteye-orgctl`, владеет только **жизненным циклом** организации + участника: создание / переименование / удаление / очистка организации, а также добавление / вывод списка / обновление / удаление участника. *** ## См. также * [Deployment](/ru/agenteye/deployment): `ORG_CH_SECRET` и остальная часть окружения сервера. * [Kubernetes Deployment](/ru/agenteye/kubernetes-deployment): §2.6 создает Secret `agenteye-org-ch-secret` перед вашей первой организацией multi-tenant. * [API Keys](/ru/agenteye/api-keys): модель ключа для каждой организации и маркеры разрешений, используемые `--add` / `--remove`. * [Troubleshooting](/ru/agenteye/troubleshooting): проблемы с подготовкой multi-tenant и изоляцией ClickHouse.