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 → переменные окружения и на Kubernetes §2.6 руководства по развертыванию на Kubernetes). Сохраняйте его одинаковым на всех репликах сервера и не вращайте его небрежно; ротация оставляет каждого пользователя ClickHouse организации без привязки до следующего запуска, который повторно подготовит их.
Запуск CLI
agenteye-orgctl входит в тот же образ, что и сервер (наряду с agenteye-server). Вы не развертываете отдельный под, Job или Deployment для него; вы выполняете его внутри уже работающего пода сервера, поэтому он читает тот же DATABASE_URL, CLICKHOUSE_URL и ORG_CH_SECRET, которые использует сервер.
Kubernetes:
agenteye-orgctl <args> для краткости; добавьте перед каждой одну из двух приведенных выше строк, которая соответствует вашему развертыванию.
Справочник команд
Организации
| Команда | Что она делает |
|---|---|
org create --slug <slug> --name <name> | Создать новую организацию. Отказывает работу, пока ORG_CH_SECRET не установлен или остается встроенным значением по умолчанию разработки (установите свое значение, см. Предварительные требования). Подготавливает пользователя ClickHouse организации только для чтения + политику строк. |
org list | Список всех организаций (слаг, имя и статус жизненного цикла). |
org rename --slug <slug> --name <new name> | Изменить отображаемое имя организации. Слаг (используется в URL и ключах) остается без изменений. |
org delete --slug <slug> | Мягкое удаление организации и удаление её пользователя ClickHouse. Данные сохраняются. Это отзывает доступ и освобождает учетные данные ClickHouse для каждой организации, но не стирает события. Может быть отменено оператором; безопасный первый шаг перед очисткой. |
org purge --slug <slug> | Необратимое стирание данных. Организация должна быть уже deleted. Никогда не разрешено для встроенной организации default. Используйте только если вы уверены, что данные тенанта должны быть уничтожены. |
Участники
| Команда | Что она делает |
|---|---|
member add --org <slug> --email <email> [--set <permission-set>] [--add perm1,perm2] [--remove perm3] [--protected] | Добавить участника в организацию. Опционально начните с встроенного набора разрешений, затем добавьте/удалите отдельные разрешения. --protected закрепляет участника, чтобы дашборд не мог удалить или понизить его в должности (см. ниже). Новый участник получит OTP при первом входе на дашборд. |
member list --org <slug> | Список участников организации. Выходные столбцы: EMAIL, SET (встроенный набор, с которого начал участник, или -), PROT (защищен ли участник), и PERMISSIONS (их эффективные разрешения). Email, показанный с завершающей *, является администратором экземпляра; у них есть доступ к каждой организации. |
member update --org <slug> --email <email> [--set ...] [--add ...] [--remove ...] [--protected | --unprotect] | Изменить разрешения участника и/или флаг защиты. --set заменяет встроенным набором; --add / --remove корректируют отдельные разрешения; --protected / --unprotect переключают защиту. Передача только --protected/--unprotect (без флагов грантов) изменяет только защиту и оставляет существующие разрешения без изменений. |
member remove --org <slug> --email <email> | Удалить участника из организации. Отказывает, если участник защищен; сначала отмените для них --unprotect. (Человек может быть участником нескольких организаций; это влияет только на названную организацию.) |
Защищенные участники (администратор организации, которого нельзя удалить)
Защита гарантирует, что организация никогда случайно не заблокирует себя от самоуправления. По умолчанию администраторы организации могут добавлять и удалять друг друга через страницу пользователей самообслуживания дашборда, поэтому они могут удалить последнего администратора и оставить организацию без возможности управления.
member update --org acme --email owner@acme.example --unprotect, затем удалите или понизьте. Это гарантирует, что каждая организация сохраняет как минимум одного администратора, которого её собственные участники не могут заблокировать, сохраняя контроль над тенантом исключительно оператору. Защита для каждой организации; защита кого-то в одной организации не влияет на их членство в другой.
Встроенные наборы разрешений
--set принимает один из трех встроенных наборов, применяемых для каждой организации:
| Набор | Предназначен для |
|---|---|
admin | Полный доступ в пределах организации, включая управление ключами API и пользователями организации. |
standard | Повседневное использование: чтение + запуск запросов, построение дашбордов, подтверждение инцидентов. |
read-only | Доступ только для просмотра к данным и дашбордам организации. |
--set, затем уточните с помощью --add / --remove используя маркеры отдельных разрешений, указанные в API Keys. Сами маркеры разрешений идентичны используемым для ключей API.
Практический пример
Подготовьте нового тенантаacme, добавьте его первого администратора, позвольте ему создать ключ, затем выведите организацию из строя.
1. Создать организацию (ORG_CH_SECRET должен быть уже установлен на мощное, стабильное значение, не оставлен незаданным или встроенным значением по умолчанию разработки):
/acme/sessions).
3. Создать ключ API для каждой организации (на дашборде):
Оператор не создает ключи данных для каждой организации из CLI. Alice (или любой участник организации с keys:create) создает ключи сборщика/дашборда для организации acme на странице Keys дашборда. Каждый ключ, который она создает, автоматически помечается её организацией и может только когда-либо читать или писать данные acme. См. API Keys.
4. Отрегулировать участника позже:
default):
kubectl -n agenteye exec deploy/server -- на docker compose exec server.
Распределение ответственности
Все, что нужно участнику организации в повседневной работе, является самообслуживанием на дашборде и API, автоматически ограниченное их текущей организацией:- Ключи API для каждой организации создаются и управляются участниками организации на дашборде (или через API ключей с ключом, который содержит
keys:create). CLI не создает ключи данных. См. API Keys. - Переключение организации встроено в дашборд; участники переключаются между организациями, к которым они принадлежат, из переключателя организации, и страницы с областью организации находятся под
/<org-slug>/…. - Дашборды, сохраненные запросы, оповещения и все использование данных происходят полностью в пользовательском интерфейсе и API, ограниченное текущей организацией участника.
agenteye-orgctl, владеет только жизненным циклом организации + участника: создание / переименование / удаление / очистка организации, а также добавление / вывод списка / обновление / удаление участника.
См. также
- Deployment:
ORG_CH_SECRETи остальная часть окружения сервера. - Kubernetes Deployment: §2.6 создает Secret
agenteye-org-ch-secretперед вашей первой организацией multi-tenant. - API Keys: модель ключа для каждой организации и маркеры разрешений, используемые
--add/--remove. - Troubleshooting: проблемы с подготовкой multi-tenant и изоляцией ClickHouse.