# Расширенный контроль доступа в организациях с группами ресурсов

> [!WARNING]
> Эта функция входит в планы Team & Enterprise.

В вашей организации Hugging Face вы можете использовать Resource Groups для управления доступом членов к конкретным репозиториям.

## Как это работает?

Группы ресурсов позволяют администраторам организации **группировать связанные репозитории**, что даёт разным командам в вашей организации возможность работать с независимыми наборами репозиториев.

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

Участникам назначается **роль** в каждой группе ресурсов, которая определяет их права доступа к репозиториям группы. Для групп ресурсов существуют четыре различные роли:

- `read`: предоставляет **доступ на чтение** к репозиториям в группе ресурсов.
- `contributor`: предоставляет **права на запись, ограниченные репозиториями, созданными пользователем** (то есть пользователи могут создавать репозитории и затем изменять только эти репозитории). Аналогично роли «Write», но ограничено репозиториями, созданными пользователем.
- `write`: предоставляет **право на запись во все репозитории** в группе ресурсов. Пользователи могут создавать, удалять или переименовывать любой репозиторий в группе ресурсов.
- `admin`: Помимо прав на запись в репозиториях, участники с ролью admin могут **управлять Resource Group**: добавлять и удалять участников, а также изменять их роли. Они также могут управлять уже существующими репозиториями в Resource Group.
- `inherit`: роль участника в группе ресурсов совпадает с его **ролью в организации**. Например, участник с ролью организации `write`, добавленный в группу с `inherit`, получает доступ `write` в этой группе

Кроме того, администраторы организации могут управлять **всеми группами ресурсов** внутри организации. Это включает перемещение репозиториев в любую группу ресурсов и из неё.

Группы ресурсов также влияют на видимость частных репозиториев внутри организации:

- Репозиторий с **приватным** доступом, входящий в состав группы ресурсов, виден только **участникам этой группы ресурсов**.
- Репозитории **Public** видны **всем**, как внутри организации, так и за её пределами.
- Те же правила видимости применяются к частным **коллекциям**, которые принадлежат группе ресурсов.

## Начало работы

Перейдите в настройки вашей организации, затем выберите пункт «Resource Groups» в меню слева. Страница разделена на две вкладки: **Resource Groups**, где перечислены и управляются сами группы, и **Access settings**, где администраторы организации настраивают, кто может создавать Resource Groups и какие участники могут использовать конкретные функции организации.

    
    

Администраторы организации могут создавать и управлять группами ресурсов (Resource Groups) на этой странице. В зависимости от настроек организации, создание групп ресурсов может быть разрешено и членам с более низкими ролями (см. [Кто может создавать группы ресурсов](#who-can-create-resource-groups) ниже).

После создания группы ресурсов и присвоения ей осмысленного имени вы попадаете на страницу группы. Она организована в четыре вкладки:

- **Обзор**: сводка по группе (типы репозиториев, роли участников, состояние авто-включения и лимит расходов), а также предпросмотр её ресурсов и пользователей.
- **Ресурсы**: полный список репозиториев и коллекций группы, а также Jobs, тарифицируемых для группы, с поиском, сортировкой и пагинацией. Именно здесь вы добавляете ресурсы в группу.
- **Пользователи**: участники группы и их роли, с поиском и сортировкой. Здесь вы добавляете пользователей и управляете их ролями.
- **Настройки**: конфигурация автоматического включения и лимитов расходов для группы.

    
    

Вы можете начать добавлять репозитории и пользователей в группу на вкладках **Resources** и **Users**.

    
    

> [!TIP]
> При добавлении пользователей в группу ресурсов можно искать по адресу электронной почты, если у пользователя есть корпоративный адрес (например, `user@your-company.com`), соответствующий домену электронной почты вашей организации.

Помните, что репозиторий может входить только в одну Resource Group. При попытке добавить репозиторий, который уже принадлежит другой Resource Group, вы получите предупреждение.

## Автоприсоединение

Auto-join автоматически добавляет **участников организации** в группу ресурсов с указанной ролью: как тех, кто уже состоит в организации на момент включения auto-join, так и всех новых участников, которые присоединятся в будущем.

Это полезно для групп ресурсов, которые должны быть доступны всей вашей организации без необходимости ручного управления членством.

### Включение авто-join

- **Через интерфейс**: откройте вкладку **Settings** группы ресурсов и отметьте опцию **Automatically include all org members** в разделе **Auto-include org members**, затем выберите роль для назначения. Вкладка Users также содержит ссылку на этот раздел, где отображается, включена ли автодобавка или нет.
- **Через API**: см. [Настройка автоприсоединения через API](./programmatic-user-access-control#configure-auto-join-via-api).

    
    

Если автоприсоединение включено для существующей группы ресурсов, текущие участники организации, соответствующие выбранному диапазону, **немедленно добавляются** в группу с назначенной ролью (backfill).

### Область автоприсоединения

Auto-join может применяться к:

- **Все участники организации** (по умолчанию): снимите отметку с **Включать участников с no_access**, чтобы исключить участников с ролью организации `no_access`.
- **Все участники организации, включая no_access**: отметьте **Включить участников no_access**, чтобы включить всех участников, в том числе тех, у которых роль организации `no_access`.

Используйте **только участников Read+**, если участники `no_access` должны сохранять доступ только к тем конкретным группам ресурсов, в которые они добавлены вручную или через другой процесс развёртывания.

### Auto-join и SCIM

Автоприсоединение и управление через SCIM являются **взаимоисключающими** в рамках одной группы ресурсов. Автоприсоединение автоматически добавляет участников организации, тогда как управление через SCIM означает, что доступом к членству управляет только IdP. Эти два поведения конфликтуют, поэтому:

- Невозможно включить автоматическое присоединение в группе ресурсов, связанной с группой SCIM.
- Нельзя связать группу SCIM с группой ресурсов, для которой включено автоматическое присоединение.

Чтобы переключить группу ресурсов с автоматического присоединения на управление через SCIM (или наоборот), сначала отключите текущий параметр.

## Внешние приглашения

Вы можете делиться группами ресурсов с пользователями из других организаций. Администраторы организации включают эту возможность с помощью настройки **External invitations** на вкладке **Access settings** страницы настроек группы ресурсов. По умолчанию эта настройка отключена и недоступна для организаций с [managed users](./enterprise-advanced-sso).

Приглашенные пользователи присоединяются как [внешние соавторы](./security-sso-user-management#external-collaborators):

- По умолчанию им назначается роль организации `no_access`, поэтому они видят только ресурсы этой группы ресурсов.
- Вы можете пригласить их в группу ресурсов с ролью `read` или `write`.
- Им не обязательно входить в систему с помощью SSO вашей организации.

Чтобы пригласить кого-либо, откройте вкладку **Users** в группе ресурсов и добавьте пользователя по имени. Члены организации присоединяются к группе сразу, а внешние участники получают приглашение. Ожидающие приглашения отображаются в списке пользователей группы с меткой «Pending», их можно отправить повторно или отозвать. Используйте фильтр **External**, чтобы отобразить только внешних соавторов.

### Общий доступ к репозиторию для внешних участников

Администраторы групп ресурсов также могут поделиться частным репозиторием со страницы **Settings**, в разделе **Share with external collaborators**. В этом разделе перечислены участники, уже входящие в группу ресурсов репозитория, и можно пригласить внешних соавторов. Каждый приглашенный получает доступ ко всем ресурсам в группе ресурсов, а не только к этому репозиторию.

    
    

Если репозиторий ещё не входит в Resource Group, участники, имеющие право [создавать Resource Groups](#who-can-create-resource-groups), могут создать одну из этого раздела и одновременно пригласить соавторов. **Auto-include** включён по умолчанию: он добавляет участников организации (кроме тех, у кого роль `no_access`) в новую группу через [auto-join](#auto-join) с ролью `inherit`, чтобы они сохранили текущий доступ к репозиторию. Если отключить эту функцию, репозиторий смогут видеть только пользователи, которых вы добавите в Resource Group, а также администраторы организации.

Вы также можете управлять внешними приглашениями через API: [Пригласить внешних соавторов через API](./programmatic-user-access-control#invite-external-collaborators-via-api).

## Кто может создавать группы ресурсов

По умолчанию новые группы ресурсов могут создавать только администраторы организации. Администраторы организации могут изменить это, задав **минимальную роль участника, необходимую для создания групп ресурсов** на вкладке **Настройки доступа** страницы настроек групп ресурсов.

Доступные варианты:
- **Только администраторы** (по умолчанию): создавать группы ресурсов могут только администраторы организации.
- **Write+**: участники с ролью Write или Admin могут создавать группы ресурсов.
- **Contributor+**: участники с ролью Contributor, Write или Admin могут создавать группы ресурсов.
- **Read+**: любой участник организации может создавать группы ресурсов, за исключением участников с ролью организации `no_access`.

Когда пользователь без прав администратора создаёт группу ресурсов через интерфейс, он автоматически назначается **администратором** этой новой группы. Через API это не происходит автоматически, поскольку вызовы API могут выполняться от имени других пользователей. Пользователи API без прав администратора должны включать в начальный список участников группы хотя бы одного пользователя с ролью администратора.

## Детальный доступ к функциям

> [!WARNING]
> Эта функция входит в тарифный план Enterprise и выше.

Администраторы организации также могут управлять тем, кто имеет право использовать конкретную функцию организации, независимо от доступа к репозиторию. Настройка находится на вкладке **Access settings** страницы настроек групп ресурсов.

    
    

Следующие функции можно ограничить:

- **Блог**: написание и публикация [статий блога](./enterprise-blog-articles) организации.
- **Коллекции**: создание и редактирование [коллекций](./collections) организации.
- **Задания**: запуск и просмотр [заданий](./jobs), тарифицируемых для организации.
- **Точки вывода**: создание, управление и вызов точек вывода, принадлежащих организации.
- **Поставщики инференса**: запросы [Поставщиков инференса](/docs/inference-providers), тарифицируемые для организации.

Для каждого из них можно выбрать, у кого есть доступ:

- **Все** (по умолчанию): каждый член организации в зависимости от его роли в организации.
- **Только администраторы организации**: доступ сохраняется только у администраторов организации.
- **Конкретные группы ресурсов**: только участники выбранных групп ресурсов в зависимости от их роли в группе.

Администраторы организации всегда сохраняют доступ ко всем функциям, независимо от выбранного варианта.

Ограничение функции для конкретных групп ресурсов управляет тем, **кто** может использовать функцию, а не тем, **где**. Члены выбранных групп могут продолжать использовать функцию в любом месте организации (например, создавать коллекцию, не принадлежащую ни одной группе ресурсов), в то время как другие члены полностью теряют доступ к функции. Ограничение никогда не предоставляет дополнительных разрешений: то, что может сделать член, по-прежнему определяется его ролью в организации.

Члены без доступа больше не могут использовать эту функцию в контексте организации, как через API, так и в интерфейсе. Запросы к API возвращают ошибку авторизации. В их личном аккаунте или в другой организации ничего не меняется.

## Атрибуция затрат

> [!WARNING]
> Эта функция входит в тарифный план Enterprise и выше.

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

- **Spaces**: стоимость автоматически списывается на группу ресурсов, к которой принадлежит Space.
- **Jobs**: установите `namespace` в значение организации-владельца и передайте идентификатор группы ресурсов с помощью `resource_group_id` в Python, `--resource-group-id` в CLI или `resourceGroupId` в теле HTTP-запроса. См. [Оплата через группу ресурсов](./jobs-pricing#bill-to-a-resource-group).
- **Поставщики инференса**: передайте идентификатор группы ресурсов в заголовке `X-HF-Bill-To` (или параметре `bill_to` в SDK). См. [Тарификация для командных и корпоративных организаций](/docs/inference-providers/pricing#billing-for-team-and-enterprise-organizations).
- **Точки вывода**: стоимость автоматически списывается на группу ресурсов, к которой принадлежит репозиторий модели. На данный момент не поддерживаются точки вывода, создаваемые напрямую из встроенного каталога точек вывода.

Вы можете использовать специальный API-эндпоинт для получения данных об отнесении затрат к группам ресурсов.

## Лимиты расходов

> [!WARNING]
> Эта функция входит в тарифный план Enterprise и выше.

Помимо отслеживания расходов, вы можете ограничивать их. Администраторы организации и администраторы групп ресурсов могут установить ежемесячные лимиты расходов на вкладке **Settings** группы, в разделе **Spend limits**.

    
    

Доступны два типа лимитов, оба выражены в долларах США:

- **Всего (все продукты)**: ограничивает совокупные вычислительные расходы группы.
- Ограничение на продукт для **Inference Providers**, **Spaces**, **Jobs** и **Inference Endpoints** сверх общего лимита.

Оставьте поле пустым, чтобы не устанавливать ограничений. Если действуют как общий лимит, так и лимит на продукт, применяется более строгий из них.

Ограничения применяются к расходам, приписанным к группе за текущий календарный месяц, поэтому группа, достигшая лимита, разблокируется в начале следующего месяца или сразу после того, как администратор повысит лимит.

### Что происходит при достижении лимита

Новое использование, тарифицируемое для группы ресурсов, отклоняется с ошибкой авторизации:

- **Поставщики инференса**: запросы, тарифицируемые для группы, отклоняются.
- **Задания**: создание, повторная отправка или возобновление задания в группе отклоняются, включая запланированные задания.
- **Spaces**: повышение уровня Space в группе до платного оборудования отклоняется.
- **Inference Endpoints**: запросы к конечным точкам, за которые группа несёт расходы, отклоняются.

Задачи, которые уже выполняются в группе, также останавливаются вскоре после достижения лимита:

- Оплата **Spaces** приостановлена. Spaces на бесплатном оборудовании, а также Spaces, работающие по [гранту на оборудование](./spaces-gpus), остаются без изменений.
- **Jobs** отменяются, а причиной их остановки указывается `Resource group spend limit reached`.

Повышение лимита или наступление нового месяца позволяет участникам снова запускать новые рабочие нагрузки. Spaces и Jobs, которые были остановлены, не перезапускаются автоматически.

Вы также можете устанавливать лимиты расходов программно, см. [Установка лимитов расходов через API](./programmatic-user-access-control#set-spend-limits-via-api).

## API групп ресурсов

Вы можете получить список групп ресурсов и добавлять в них пользователей (или изменять роль участника в организации и его назначение в группы ресурсов) через Hub API. Полное справочное руководство, примеры и пакетные рабочие процессы описаны в руководстве [Programmatic User Access Control Management](./programmatic-user-access-control).