Contrôle d'accès avancé dans les organisations avec des groupes de ressources

Cette fonctionnalité fait partie des plans Team & Enterprise.

Dans votre organisation Hugging Face, vous pouvez utiliser les groupes de ressources pour contrôler quels membres ont accès à des dépôts spécifiques.

Comment ça fonctionne ?

Les groupes de ressources permettent aux administrateurs d’organisation de regrouper des dépôts liés, ce qui permet à différentes équipes de votre organisation de travailler sur des ensembles de dépôts indépendants.

• Ressources : les dépôts et collections du groupe. Chaque ressource ne peut appartenir qu'à un seul groupe de ressources et peut être déplacée entre les groupes par les membres disposant des autorisations appropriées.
• Membres : les membres de l'organisation doivent être ajoutés à un Resource Group pour accéder à ses dépôts. Un membre peut appartenir à plusieurs Resource Groups.

Les membres se voient attribuer un rôle dans chaque groupe de ressources, qui détermine leurs autorisations pour les dépôts du groupe. Quatre rôles distincts existent pour les groupes de ressources :

• read : Accorde un accès en lecture aux dépôts au sein du groupe de ressources.
• contributor : Accorde des droits d’écriture limités aux dépôts créés par l’utilisateur (c’est-à-dire que les utilisateurs peuvent créer des dépôts puis ne modifier que ces dépôts). Similaire au rôle « Write », mais limité aux dépôts créés par l’utilisateur.
• write : offre un accès en écriture à tous les dépôts du groupe de ressources. Les utilisateurs peuvent créer, supprimer ou renommer n'importe quel dépôt du groupe de ressources.
• admin : En plus des droits d’écriture sur les dépôts, les membres administrateurs peuvent administrer le groupe de ressources : ajouter, supprimer et modifier les rôles des autres membres. Ils peuvent également gérer les dépôts déjà existants au sein d’un groupe de ressources.
• inherit : le rôle du membre dans le groupe de ressources est identique à son rôle d’organisation. Par exemple, un membre ayant le rôle d’organisation write et ajouté à un groupe avec inherit obtient un accès write dans le groupe

En outre, les administrateurs d’organisation peuvent gérer tous les groupes de ressources au sein de l’organisation. Cela inclut le déplacement de dépôts à l’intérieur et à l’extérieur de n’importe quel groupe de ressources.

Les groupes de ressources affectent également la visibilité des dépôts privés au sein de l’organisation :

• Un dépôt privé faisant partie d'un groupe de ressources n'est visible que par les membres de ce groupe de ressources.
• Les dépôts Public sont visibles par n’importe qui, à l’intérieur comme à l’extérieur de l’organisation.
• Les mêmes règles de visibilité s’appliquent aux collections privées appartenant à un groupe de ressources.

Premiers pas

Accédez aux paramètres de votre Organisation, puis naviguez vers l’entrée « Resource Groups » dans le menu de gauche. La page est divisée en deux onglets : Resource Groups, où les groupes sont listés et gérés, et Access settings, où les administrateurs de l’organisation configurent qui peut créer des Resource Groups et quels membres peuvent utiliser des fonctionnalités spécifiques de l’organisation.

Les administrateurs d’organisation peuvent créer et gérer des Resource Groups depuis cette page. En fonction des paramètres de l’organisation, les membres disposant de rôles inférieurs peuvent également être autorisés à créer des Resource Groups (voir Qui peut créer des Resource Groups ci-dessous).

Après avoir créé un Resource Group et lui avoir attribué un nom significatif, vous arrivez sur la page du groupe. Elle est organisée en quatre onglets :

• Aperçu : un résumé du groupe (types de dépôts, rôles des membres, état d'inclusion automatique et limite de dépense) ainsi qu'un aperçu de ses ressources et utilisateurs.
• Ressources : la liste complète des dépôts et collections du groupe, ainsi que les Jobs facturés au groupe, avec recherche, tri et pagination. C’est ici que vous ajoutez des ressources au groupe.
• Utilisateurs : les membres du groupe et leurs rôles, avec recherche et tri. C’est ici que vous ajoutez des utilisateurs et gérez leurs rôles.
• Paramètres : configuration des limites de dépenses et de l’inclusion automatique du groupe.

Vous pouvez commencer à ajouter des dépôts et des utilisateurs au groupe à partir des onglets Ressources et Utilisateurs.

Lors de l’ajout d’utilisateurs à un Resource Group, vous pouvez rechercher par adresse e-mail si l’utilisateur dispose d’une adresse e-mail spécifique à l’organisation (par exemple, user@your-company.com) correspondant au domaine e-mail de votre organisation.

N’oubliez pas qu’un dépôt ne peut appartenir qu’à un seul Resource Group. Un avertissement s’affichera si vous essayez d’ajouter un dépôt qui appartient déjà à un autre Resource Group.

Auto-rejoindre

Auto-join ajoute automatiquement les membres de l’organisation à un groupe de ressources avec un rôle spécifié : cela concerne à la fois les membres déjà présents dans l’organisation au moment de l’activation d’auto-join et les nouveaux membres qui rejoindront l’organisation à l’avenir.

Ceci est utile pour les groupes de ressources qui doivent être accessibles à votre organisation entière sans nécessiter de gestion manuelle des membres.

Activation de l’auto-join

• Via l’interface : ouvrez l’onglet Paramètres du groupe de ressources et cochez l’option Inclure automatiquement tous les membres de l’organisation dans la section Inclusion automatique des membres de l’organisation, puis sélectionnez le rôle à attribuer. L’onglet Utilisateurs y renvoie également et indique si l’inclusion automatique est activée ou désactivée.
• Via l’API : voir Configurer l’auto-join via l’API.

Lorsque l’auto-ajout est activé sur un groupe de ressources existant, les membres actuels de l’organisation correspondant à la portée sélectionnée sont ajoutés immédiatement au groupe avec le rôle configuré (rétro-remplissage).

Portée d'auto-rejoindre

Auto-join peut s'appliquer à :

• Tous les membres de l’organisation (par défaut) : laissez Inclure les membres no_access non coché pour exclure les membres ayant le rôle d’organisation no_access.
• Tous les membres de l’organisation, y compris no_access : cochez Inclure les membres no_access pour inclure chaque membre, y compris ceux ayant le rôle d’organisation no_access.

Utilisez Read+ members only lorsque les membres no_access doivent conserver l’accès uniquement aux groupes de ressources spécifiques dans lesquels ils sont ajoutés manuellement ou via un autre flux de provisionnement.

Auto-join et SCIM

L’auto-join et la gestion SCIM sont mutuellement exclusifs sur le même Resource Group. L’auto-join ajoute automatiquement les membres de l’organisation, tandis que la gestion SCIM signifie que seul l’IdP contrôle l’adhésion. Ces deux comportements sont en conflit, donc :

• Vous ne pouvez pas activer l'auto-join sur un groupe de ressources lié à un groupe SCIM.
• Vous ne pouvez pas associer un groupe SCIM à un groupe de ressources pour lequel l'adhésion automatique est activée.

Pour passer un groupe de ressources du mode d'adhésion automatique à la gestion par SCIM (ou inversement), désactivez d'abord le paramètre actuel.

Invitations externes

Vous pouvez partager des Resource Groups avec des utilisateurs extérieurs à votre organisation. Les administrateurs d’organisation activent cette fonctionnalité via le paramètre External invitations, situé dans l’onglet Access settings de la page de configuration des Resource Groups. Cette option est désactivée par défaut et n’est pas disponible pour les organisations disposant d’utilisateurs managed users.

Les utilisateurs invités rejoignent en tant que collaborateurs externes :

• Par défaut, ils reçoivent le rôle d’organisation no_access, de sorte qu’ils ne voient que les ressources du groupe de ressources concerné.
• Vous pouvez les inviter avec le rôle read ou write dans le groupe de ressources.
• Ils n’ont pas besoin de se connecter via le SSO de votre organisation.

Pour inviter quelqu’un, ouvrez l’onglet Users du Resource Group et ajoutez la personne par son nom d’utilisateur. Les membres de l’organisation rejoignent le groupe immédiatement ; les personnes extérieures reçoivent une invitation. Les invitations en attente figurent parmi les utilisateurs du groupe, sous un badge « Pending », et vous pouvez les renvoyer ou les révoquer. Utilisez le filtre External pour n’afficher que les collaborateurs externes.

Partager un dépôt avec des collaborateurs externes

Les administrateurs de groupe de ressources peuvent également partager un dépôt privé depuis sa page Paramètres, sous Partager avec des collaborateurs externes. Cette section liste les personnes déjà présentes dans le groupe de ressources du dépôt et permet d’inviter des collaborateurs externes. Toute personne ajoutée y obtient un accès à toutes les ressources du groupe de ressources, et non uniquement à ce dépôt.

Si le dépôt n’est pas encore dans un Resource Group, les membres pouvant créer des Resource Groups peuvent en créer un depuis cette section et inviter des collaborateurs en même temps. Inclusion automatique est activé par défaut : il place les membres de l’organisation (à l’exception de ceux ayant le rôle no_access) dans le nouveau groupe via auto-join avec le rôle inherit, afin qu’ils conservent leur accès actuel au dépôt. Si vous le désactivez, seuls les utilisateurs que vous ajoutez au Resource Group, ainsi que les administrateurs de l’organisation, peuvent le voir.

Vous pouvez également gérer les invitations externes via l’API : Inviter des collaborateurs externes via l’API.

Qui peut créer des groupes de ressources

Par défaut, seuls les administrateurs d’organisation peuvent créer de nouveaux Resource Groups. Les administrateurs d’organisation peuvent modifier ce paramètre en définissant le rôle minimal requis pour créer des Resource Groups dans l’onglet Access settings de la page de configuration des Resource Groups.

Les options disponibles sont :

• Administrateurs uniquement (par défaut) : seuls les administrateurs de l’organisation peuvent créer des groupes de ressources.
• Write+ : les membres disposant du rôle Write ou Admin peuvent créer des groupes de ressources.
• Contributeur+ : les membres ayant le rôle Contributeur, Write ou Admin peuvent créer des groupes de ressources.
• Lecture+ : tout membre de l’organisation peut créer des groupes de ressources, à l’exception des membres ayant le rôle d’organisation no_access.

Lorsqu’un membre non administrateur crée un Resource Group via l’interface utilisateur, il est automatiquement ajouté en tant qu’admin de ce groupe nouvellement créé. Via l’API, cela ne se produit pas automatiquement, car les appelants de l’API peuvent créer des groupes au nom d’autres personnes. Les appelants de l’API non administrateurs doivent inclure au moins un utilisateur avec le rôle admin dans la liste initiale des membres du groupe.

Accès granulaire aux fonctionnalités

Cette fonctionnalité fait partie de l'offre Enterprise et des offres supérieures.

Les administrateurs d’organisation peuvent également contrôler qui est autorisé à utiliser une fonctionnalité d’organisation donnée, indépendamment de l’accès aux dépôts. Ce paramètre se trouve sur l’onglet Access settings de la page de configuration des groupes de ressources.

Les fonctionnalités suivantes peuvent être restreintes :

• Blog : rédaction et publication des articles de blog de l'organisation.
• Collections : création et édition des collections d'organisation.
• Jobs : exécution et consultation des Jobs facturés à l’organisation.
• Endpoints d’inférence : création, gestion et appel des endpoints d’inférence appartenant à l’organisation.
• Fournisseurs d'inférence : les demandes de Fournisseurs d'inférence facturées à l'organisation.

Pour chacun d'entre eux, vous pouvez choisir qui a accès :

• Tout le monde (par défaut) : chaque membre de l'organisation, en fonction de son rôle au sein de l'organisation.
• Administrateurs d’organisation uniquement : seuls les administrateurs d’organisation conservent l’accès.
• Groupes de ressources spécifiques : uniquement les membres des groupes de ressources sélectionnés, en fonction de leur rôle au sein du groupe.

Les administrateurs d'organisation conservent toujours l'accès à toutes les fonctionnalités, quelle que soit l'option sélectionnée.

Restreindre une fonctionnalité à des groupes de ressources spécifiques contrôle qui peut utiliser la fonctionnalité, et non où. Les membres des groupes sélectionnés peuvent continuer à utiliser la fonctionnalité n’importe où dans l’organisation (par exemple, en créant une collection qui n’appartient à aucun groupe de ressources), tandis que les autres membres perdent tout accès à la fonctionnalité. La restriction n’accorde jamais de permissions supplémentaires : ce qu’un membre peut faire est toujours déterminé par son rôle dans l’organisation.

Les membres sans accès ne peuvent plus utiliser la fonctionnalité dans le contexte de l’organisation, que ce soit via l’API ou l’interface utilisateur. Les requêtes API renvoient une erreur d’autorisation. Rien ne change pour eux sous leur compte personnel ou dans une autre organisation.

Attribution des coûts

Cette fonctionnalité fait partie de l'offre Enterprise et des offres supérieures.

Les groupes de ressources servent également d'unité d'attribution des coûts pour les services de calcul. Lorsque le calcul est facturé à un groupe de ressources, les coûts sont suivis séparément par groupe, ce qui facilite la compréhension des dépenses entre les équipes.

• Spaces : le coût est automatiquement imputé au groupe de ressources auquel l’espace appartient.
• Jobs : définissez namespace sur l’organisation propriétaire et passez l’identifiant du groupe de ressources à l’aide de resource_group_id dans Python, --resource-group-id dans l’interface en ligne de commande ou resourceGroupId dans le corps de la requête HTTP. Consultez Facturation à un groupe de ressources.
• Fournisseurs d’inférence : passez l’identifiant du groupe de ressources via l’en-tête X-HF-Bill-To (ou le paramètre bill_to dans le SDK). Consultez Facturation pour les organisations Team et Enterprise.
• Endpoints d’inférence : le coût est automatiquement imputé au groupe de ressources auquel appartient le dépôt de modèles. Les endpoints instanciés directement à partir du catalogue intégré d’Endpoints d’inférence ne sont pas pris en charge pour le moment.

Vous pouvez utiliser le point de terminaison d’API dédié pour récupérer les données d’attribution des coûts des groupes de ressources.

Limites de dépenses

Cette fonctionnalité fait partie de l'offre Enterprise et des offres supérieures.

En plus de suivre les coûts, vous pouvez les plafonner. Les administrateurs d’organisation et les administrateurs de groupe de ressources peuvent définir des limites de dépenses mensuelles dans l’onglet Paramètres du groupe, sous Limites de dépenses.

Deux types de limites sont disponibles, tous deux exprimés en USD :

• Total (tous les produits) : plafonne les dépenses de calcul combinées du groupe.
• Une limite par produit pour Inference Providers, Spaces, Jobs et Inference Endpoints, en plus du total.

Laissez un champ vide pour ne pas définir de limite. Si une limite totale et une limite par produit s’appliquent toutes deux, la plus stricte des deux prévaut.

Des limites s’appliquent aux dépenses attribuées au groupe pour le mois civil en cours. Un groupe ayant atteint sa limite est donc débloqué au début du mois suivant, ou dès qu’un administrateur augmente la limite.

Ce qui se passe lorsqu'une limite est atteinte

La nouvelle utilisation facturée au groupe de ressources est refusée avec une erreur d'autorisation :

• Fournisseurs d'inférence : les facturations adressées au groupe sont rejetées.
• Jobs : la création, la resoumission ou la reprise d'un job au sein du groupe est rejetée, y compris pour les jobs planifiés.
• Spaces : la mise à niveau d’un Space du groupe vers du matériel payant est refusée.
• Endpoints d'inférence : les requêtes vers les endpoints qui engendrent des coûts pour le groupe sont rejetées.

Les charges de travail déjà en cours d’exécution dans le groupe sont également arrêtées, peu de temps après que la limite est atteinte :

• Les Spaces payants sont en pause. Les Spaces sur du matériel gratuit sont laissés tels quels, de même que les Spaces exécutés sur une attribution de matériel.
• Les Jobs sont annulés, avec Resource group spend limit reached comme raison d’arrêt.

L’augmentation de la limite, ou le début d’un nouveau mois, permet aux membres de démarrer à nouveau de nouvelles charges de travail. Les Spaces et Jobs qui ont été arrêtés ne sont pas redémarrés automatiquement.

Vous pouvez également définir des limites de dépenses de manière programmatique, voir Définir des limites de dépenses via l’API.

API des groupes de ressources

Vous pouvez lister les groupes de ressources et y ajouter des utilisateurs (ou modifier le rôle d’organisation et les affectations de groupes de ressources d’un membre) via l’API du Hub. Pour la référence complète, les exemples et les flux de travail par lots, consultez le guide Programmatic User Access Control Management.

Update on GitHub