リソースグループによる組織の高度なアクセス制御

この機能は、Team & Enterprise プランの一部です。

Hugging Face の組織では、Resource Groups を使用して、特定のリポジトリへのアクセス権を持つメンバーを制御できます。

仕組みは？

Resource Groups は、組織管理者が関連するリポジトリをグループ化できるようにし、組織内の異なるチームが独立したリポジトリのセットで作業できるようにします。

• リソース: グループのリポジトリとコレクション。各リソースは1つのリソースグループにのみ属し、適切な権限を持つメンバーによってグループ間で移動できます。
• メンバー: 組織のメンバーは、リポジトリにアクセスするために Resource Group に追加される必要があります。メンバーは 複数の Resource Group に属すことができます。

メンバーには、リソースグループごとにロールが割り当てられ、そのグループのリポジトリに対する権限が決定されます。リソースグループには、4つの異なるロールが存在します。

• read: リソースグループ内のリポジトリへの読み取りアクセスを付与します。
• contributor: ユーザーが作成したリポジトリに限定された書き込み権限を提供します（つまり、ユーザーはリポジトリを作成し、その後そのリポジトリのみを変更できます）。「Write」ロールと同様ですが、ユーザーが作成したリポジトリに限定されます。
• write: リソースグループ内のすべてのリポジトリへの書き込みアクセスを提供します。ユーザーは、リソースグループ内の任意のリポジトリを作成、削除、または名前を変更できます。
• admin: リポジトリへの書き込み権限に加えて、admin メンバーは リソースグループを管理 できます。他のメンバーのロールの追加、削除、変更が可能です。また、リソースグループ内の既存のリポジトリを管理することもできます。
• inherit: リソースグループにおけるメンバーの役割は、そのメンバーの組織の役割と同じです。例えば、writeの組織の役割を持つメンバーがinheritのグループに追加された場合、そのグループ内でwriteアクセス権限を取得します。

さらに、Organizationの管理者は、組織内のすべてのリソースグループを管理できます。これには、リポジトリを任意のリソースグループに移動したり、リソースグループから移動したりすることが含まれます。

Resource Groupsは、組織内のプライベートリポジトリの可視性にも影響します。

• リソースグループの一部であるprivateリポジトリは、そのリソースグループのメンバーにのみ表示されます。
• Public リポジトリは、組織内外のすべての人に公開されます。
• リソースグループに属するプライベートなコレクションにも、同じ可視性ルールが適用されます。

はじめる

Organization の設定画面に移動し、左側のメニューから「Resource Groups」の項目を選択してください。ページは2つのタブに分かれています。Resource Groupsタブではグループの一覧表示と管理を行い、Access settingsタブでは Organization の管理者が、Resource Groups を作成できるユーザーや、特定の Organization 機能を利用できるメンバーを設定します。

Organizationの管理者は、そのページからResource Groupsを作成および管理できます。Organizationの設定によっては、より低いロールを持つメンバーもResource Groupsの作成を許可される場合があります（Resource Groupsを作成できるユーザーを参照）。

Resource Group を作成し、意味のある名前を付けた後、そのグループのページに移動します。ページは4つのタブで構成されています。

• 概要: グループ（リポジトリの種類、メンバーのロール、自動インクルードの状態、支出上限）の概要と、そのリソースとユーザーのプレビュー。
• リソース: グループのリポジトリとコレクションの完全なリスト、およびグループに請求されるJobs。検索、並べ替え、ページネーションに対応しています。ここでグループにリソースを追加します。
• ユーザー: グループのメンバーとその役割。検索と並べ替えに対応しています。ここでユーザーを追加し、役割を管理します。
• 設定: グループの自動インクルードと支出上限の設定。

ResourcesタブとUsersタブから、グループにリポジトリとユーザーを追加し始めることができます。

Resource Groupにユーザーを追加する際、ユーザーが組織固有のメールアドレス（例: [email protected]）を持っており、それが組織のメールドメインと一致している場合は、メールアドレスで検索できます。

リポジトリは1つのResource Groupにのみ属する可能性があることを覚えておいてください。別のResource Groupに既に属しているリポジトリを追加しようとした場合、警告が表示されます。

自動参加

Auto-joinは、指定されたロールで組織メンバーをリソースグループに自動的に追加します。対象は、Auto-joinを有効にした時点で組織に所属している既存メンバーと、今後参加する新規メンバーの両方です。

これは、手動でのメンバーシップ管理を必要とせずに組織全体からアクセスできる必要がある Resource Groups に便利です。

自動参加の有効化

• UI経由: リソースグループの設定タブを開き、組織メンバーの自動含み込みセクション内の組織の全メンバーを自動的に含めるオプションにチェックを入れ、割り当てるロールを選択します。ユーザータブからもそこにリンクしており、自動含み込みがオンかオフかが表示されます。
• API経由: APIによる自動参加の構成を参照してください。

既存のリソースグループで自動参加が有効化されると、選択されたスコープに一致する現在の組織メンバーは、設定されたロールで即座に追加されます（バックフィル）。

自動参加スコープ

Auto-joinは、以下に適用できます:

• すべての組織メンバー(デフォルト):no_access メンバーを含めるのチェックを外すと、no_access組織ロールを持つメンバーが除外されます。
• no_access を含むすべての組織メンバー: no_access 組織ロールを持つメンバーを含むすべてのメンバーを対象にするには、no_access メンバーを含める をチェックしてください。

no_access メンバーが、手動または別のプロビジョニングフローによって追加された特定の Resource Group へのアクセスのみを保持する必要がある場合、Read+ members only を使用してください。

自動参加とSCIM

Auto-joinとSCIM管理は、同じResource Groupに対しては相互に排他的です。Auto-joinは組織メンバーを自動的に追加しますが、SCIM管理ではメンバーシップをIdPのみが制御します。これらの2つの動作は競合するため、以下のようになります。

• SCIMグループにリンクされているResource Groupでは、auto-joinを有効にできません。
• 自動参加が有効になっているリソースグループにSCIMグループをリンクすることはできません。

Resource Groupを自動参加からSCIM管理（またはその逆）に切り替える場合は、まず現在の設定を無効にしてください。

外部からの招待

Resource Groups は、組織外ユーザーと共有できます。組織管理者は、Resource Groups 設定ページの Access settings タブにある External invitations 設定でこれを有効にします。デフォルトでは無効になっており、managed users を使用している組織では利用できません。

招待されたユーザーは外部コラボレーターとして参加します:

• デフォルトでは、no_access組織ロールが割り当てられるため、そのリソースグループのリソースのみが表示されます。
• リソースグループでreadまたはwriteロールで招待できます。
• 組織のSSOでサインインする必要はありません。

誰かを招待するには、リソースグループのUsersタブを開き、ユーザー名で追加します。組織のメンバーは即座にグループに参加し、外部のユーザーには招待が届きます。保留中の招待は、グループのユーザーの下に「Pending」バッジ付きで表示され、再送信や取り消しを行うことができます。Externalフィルターを使用して、外部の共同作業者のみをリスト表示できます。

外部の共同作業者とリポジトリを共有する

リソースグループの管理者は、SettingsページのShare with external collaboratorsセクションから、プライベートリポジトリを共有することもできます。このセクションには、リポジトリのリソースグループに既に所属しているメンバーがリスト表示され、外部のコラボレーターを招待できます。ここで追加したユーザーは、そのリポジトリだけでなく、リソースグループ内のすべてのリソースにアクセスできるようになります。

リポジトリがまだリソースグループに属していない場合、リソースグループを作成できるメンバーは、そのセクションからリソースグループを作成し、同時にコラボレーターを招待できます。自動含めるはデフォルトで有効です。これにより、組織のメンバー（no_accessロールのメンバーを除く）が、inheritロールで自動参加する新しいグループに追加され、リポジトリへの現在のアクセス権を維持します。これを無効にすると、リソースグループに追加したユーザーと組織管理者のみがリポジトリを表示できます。

API を通じて外部招待を管理することもできます: API を使用して外部コラボレーターを招待する。

リソースグループを作成できるユーザー

デフォルトでは、新しいResource Groupを作成できるのは組織の管理者のみです。組織の管理者は、Resource Groupの設定ページのAccess settingsタブで、Resource Groupの作成に必要な最低限のメンバーロールを設定することで、この設定を変更できます。

利用可能なオプションは以下の通りです：

• 管理者のみ（デフォルト）：組織の管理者のみがリソースグループを作成できます。
• Write+: WriteロールまたはAdminロールのメンバーは、リソースグループを作成できます。
• Contributor+: Contributor、Write、または Admin ロールを持つメンバーは、リソースグループを作成できます。
• Read+: no_access組織ロールを持つメンバーを除き、すべての組織メンバーがリソースグループを作成できます。

非管理者メンバーが UI 経由で Resource Group を作成すると、そのメンバーは自動的に新規作成されたグループの admin として追加されます。API を通じた場合は、呼び出し元が他のユーザーに代わってグループを作成する可能性があるため、この処理は自動では行われません。非管理者の API 呼び出し元は、グループの初期メンバーリストに admin ロールを持つユーザーを少なくとも 1 人含める必要があります。

詳細な機能へのアクセス

この機能は、Enterprise プラン以上でご利用いただけます。

Org管理者は、リポジトリへのアクセスとは別に、特定の組織機能の使用を許可するユーザーを制御することもできます。この設定は、Resource Groups設定ページのAccess settingsタブにあります。

以下の機能を制限できます:

• ブログ: 組織のブログ記事の作成と公開。
• コレクション: 組織のコレクションの作成と編集。
• Jobs: 組織に請求される Jobs の実行と表示。
• Inference Endpoints: 組織が所有する Inference Endpoints の作成、管理、呼び出し。
• Inference Providers: 組織に請求されるInference Providersのリクエスト。

それぞれについて、アクセス権限を持つユーザーを選択できます。

• Everyone（デフォルト）：組織のロールに応じて、組織のすべてのメンバー。
• 組織管理者のみ：組織管理者のみがアクセスを保持します。
• 特定のリソースグループ: グループ内での役割に応じて、選択したリソースグループのメンバーのみ。

組織管理者は、選択されたオプションに関わらず、常にすべての機能へのアクセス権を保持します。

特定のリソースグループに機能を制限すると、その機能を使用できる対象者が制御され、使用場所は制御されません。選択されたグループのメンバーは、組織内のどこでも（リソースグループに属さないコレクションを作成するなど）その機能を使い続けることができますが、その他のメンバーは完全にその機能へのアクセスを失います。この制限は追加の権限を付与しません。メンバーが実行できる操作は、依然としてその組織ロールによって決定されます。

アクセス権限のないメンバーは、組織のコンテキストにおいて、APIおよびUIの両方からその機能を使用できなくなります。APIリクエストには認証エラーが返されます。個人のアカウントや他の組織では、何も変更されません。

コストの帰属

この機能は、Enterprise プラン以上でご利用いただけます。

Resource Groups は、コンピューティングサービスのコスト帰属単位としても機能します。コンピューティングがリソースグループに請求されると、コストはグループごとに個別に追跡されるため、チーム間の支出を把握しやすくなります。

• Spaces: コストは、その Space が属するリソースグループに自動的に帰属されます。
• Jobs: namespace を所有組織に設定し、Python では resource_group_id、CLI では --resource-group-id、HTTP リクエストボディでは resourceGroupId を使用してリソースグループの ID を渡します。リソースグループへの請求を参照してください。
• Inference Providers: リソースグループの ID を X-HF-Bill-To ヘッダー（または SDK における bill_to パラメーター）で渡します。チームおよびエンタープライズ組織の請求を参照してください。
• Inference Endpoints: コストは、モデルリポジトリが属するリソースグループに自動的に帰属されます。組み込みの Inference Endpoints カタログから直接インスタンス化されたエンドポイントは、現時点ではサポートされていません。

リソースグループのコスト帰属データを取得するには、専用のAPIエンドポイントを使用できます。

支出の上限

この機能は、Enterprise プラン以上でご利用いただけます。

コストの追跡に加えて、コストに上限を設けることもできます。組織管理者とリソースグループ管理者は、グループのSettingsタブ内のSpend limitsセクションで、月間の支出上限を設定できます。

利用可能な制限は2種類あり、いずれもUSDで表されます:

• 合計（全プロダクト）: グループ全体の計算リソースの支出を上限設定します。
• 総額に加えて、Inference Providers、Spaces、Jobs、Inference Endpointsそれぞれに個別の上限が設定されています。

制限を設けない場合は、フィールドを空にしてください。合計制限と製品ごとの制限の両方が適用される場合、より厳しい方の制限が優先されます。

制限は、そのグループに帰属する現在の暦月における支出に適用されるため、制限に達したグループは、翌月の初めまたは管理者が制限を引き上げた時点でブロックが解除されます。

制限に達したとき

リソースグループに請求される新しい使用量は、認可エラーで拒否されます:

• Inference Providers: グループに請求されるリクエストは拒否されます。
• Jobs: グループ内のジョブの作成、再送信、再開は拒否されます。スケジュール済みのジョブも含まれます。
• Spaces: グループ内の Space を有料ハードウェアにアップグレードする試みは拒否されます。
• Inference Endpoints: グループにコストが発生するエンドポイントへのリクエストは拒否されます。

グループ内で既に実行されているワークロードも、制限に達した直後に停止されます:

• 有料のSpacesは一時停止されます。無料のハードウェアで動作しているSpacesや、ハードウェア助成で動作しているSpacesはそのまま維持されます。
• Jobsはキャンセルされ、停止理由としてResource group spend limit reachedが設定されます。

上限の引き上げ、または新しい月の開始により、メンバーは再び新しいワークロードを開始できます。停止されたSpacesとJobsは自動的に再開されません。

支出上限はプログラムでも設定できます。API 経由で支出上限を設定するを参照してください。

リソースグループAPI

Hub API を使用して、リソースグループの一覧表示や、ユーザーの追加（またはメンバーの組織ロールおよびリソースグループ割り当ての変更）を行うことができます。完全なリファレンス、例、およびバッチワークフローについては、Programmatic User Access Control Managementガイドを参照してください。

Update on GitHub