Участники и роли

Зачем это нужно

Дать доступ к проекту коллегам или клиентам, не раздавая один логин на всех. Доступ ролевой и ограничен проектом.

Роли ниже описаны по коду, который их и применяет (frontend/lib/rbac.ts): сама консоль нигде не объясняет, что каждая роль умеет.

От самой мощной к самой слабой. Действующая роль человека в проекте — максимум из его роли в организации и роли в конкретном проекте:

Owner — полный контроль: участники, тарифы и всё перечисленное ниже.
Admin — в повседневной работе то же самое, что Owner; разница скорее организационная.
Developer — деплой, перезапуск, переменные окружения, домены, базы, хранилище, мониторинг: всё, что нужно, чтобы выкатывать и эксплуатировать приложение.
Read Only — видит всё, не меняет ничего.

Точнее, видимость и кликабельность определяют три уровня прав:

Изменение (Owner, Admin, Developer) — создать, выкатить, перезапустить, удалить ресурс.
Манифесты, правка YAML и согласования (только Owner и Admin) — смотреть и править compose.yaml и values.yaml, видеть пункт меню Builds, согласовывать заявки на GPU-модели.
Дашборды, метрики и логи видит каждый, у кого есть доступ к проекту.

Откройте Members → Add member (пункт виден только Owner и Admin).
Введите email и выберите роль.
Поставьте галочку Send email invitation, если у человека ещё нет аккаунта — уйдёт настоящее письмо-приглашение. Без галочки существующий пользователь платформы добавится в проект сразу и без письма.
Отправьте форму.

Роль меняется прямо в таблице, выпадающим списком рядом с текущей ролью. Действует сразу, без подтверждения.
Кнопка Remove в строке участника отзывает доступ к проекту; в диалоге подтверждения показан его email.

Организация и проект путаются по-настоящему: роль в организации может давать больше, чем показано в строке проекта, потому что действующая роль — максимум из двух. Если участник с ролью Read Only всё-таки что-то меняет, посмотрите его роль в организации.
Builds и манифесты доступны только Owner и Admin. Developer не увидит пункт Builds и не сможет смотреть и править сырой YAML, хотя деплоить и перезапускать приложения может. Это сделано намеренно.
Сервисные аккаунты видны в таблице участников (столбец Type), но создать их в интерфейсе нельзя — они попадают туда другим путём.

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