Control de acceso avanzado en organizaciones con grupos de recursos

Esta función forma parte de los planes Team & Enterprise.

En tu organización de Hugging Face, puedes usar Resource Groups para controlar qué miembros tienen acceso a repositorios específicos.

¿Cómo funciona?

Los grupos de recursos permiten a los administradores de la organización agrupar repositorios relacionados, lo que permite a diferentes equipos de su organización trabajar en conjuntos independientes de repositorios.

• Recursos: los repositorios y colecciones del grupo. Cada recurso puede pertenecer a un solo grupo de recursos y puede moverse entre grupos por miembros con los permisos adecuados.
• Miembros: los miembros de la organización deben añadirse a un Resource Group para acceder a sus repositorios. Un miembro puede pertenecer a varios Resource Groups.

A los miembros se les asigna un rol en cada grupo de recursos que determina sus permisos para los repositorios del grupo. Existen cuatro roles distintos para los grupos de recursos:

• read: Concede acceso de lectura a los repositorios dentro del grupo de recursos.
• contributor: Proporciona permisos de escritura limitados a los repositorios creados por el usuario (es decir, los usuarios pueden crear repositorios y luego modificar solo esos repositorios). Similar al rol ‘Write’, pero limitado a los repositorios creados por el usuario.
• write: Ofrece acceso de escritura a todos los repositorios del Resource Group. Los usuarios pueden crear, eliminar o renombrar cualquier repositorio del Resource Group.
• admin: Además de los permisos de escritura en los repositorios, los miembros con rol de administrador pueden administrar el Resource Group: añadir, eliminar y modificar los roles de otros miembros. También pueden gestionar los repositorios existentes en un Resource Group.
• inherit: El rol del miembro en el grupo de recursos es el mismo que su rol de organización. Por ejemplo, un miembro con el rol de organización write que se añade a un grupo con inherit obtiene acceso write en el grupo

Además, los administradores de la organización pueden gestionar todos los grupos de recursos dentro de la organización. Esto incluye mover repositorios dentro y fuera de cualquier grupo de recursos.

Los grupos de recursos también afectan la visibilidad de los repositorios privados dentro de la organización:

• Un repositorio privado que forma parte de un grupo de recursos solo es visible para los miembros de ese grupo de recursos.
• Los repositorios públicos son visibles para cualquier persona, tanto dentro como fuera de la organización.
• Las mismas reglas de visibilidad se aplican a las colecciones privadas que pertenecen a un grupo de recursos.

Primeros pasos

Ve a la configuración de tu Organización y luego navega hasta la entrada “Resource Groups” en el menú izquierdo. La página se divide en dos pestañas: Resource Groups, donde se listan y gestionan los grupos, y Access settings, donde los administradores de la organización configuran quién puede crear Resource Groups y qué miembros pueden usar funciones específicas de la organización.

Los administradores de la organización pueden crear y gestionar grupos de recursos desde esa página. Dependiendo de la configuración de la organización, los miembros con roles inferiores también pueden tener permiso para crear grupos de recursos (consulte Quién puede crear grupos de recursos a continuación).

Después de crear un Resource Group y asignarle un nombre significativo, se llega a la página del grupo. Está organizada en cuatro pestañas:

• Resumen: un resumen del grupo (tipos de repositorio, roles de los miembros, estado de inclusión automática y límite de gasto) junto con una vista previa de sus recursos y usuarios.
• Recursos: la lista completa de los repositorios y colecciones del grupo, así como los Jobs facturados al grupo, con búsqueda, ordenación y paginación. Aquí es donde se añaden recursos al grupo.
• Usuarios: los miembros del grupo y sus roles, con búsqueda y ordenación. Aquí es donde se añaden usuarios y se gestionan sus roles.
• Configuración: configuración de límites de gasto e inclusión automática del grupo.

Puedes empezar a añadir repositorios y usuarios al grupo desde las pestañas Resources y Users.

Al agregar usuarios a un Resource Group, puede buscar por dirección de correo electrónico si el usuario tiene un correo específico de la organización (por ejemplo, user@your-company.com) que coincida con el dominio de correo de su organización.

Recuerde que un repositorio solo puede formar parte de un único Resource Group. Se le advertirá al intentar agregar un repositorio que ya pertenece a otro Resource Group.

Unirse automáticamente

Auto-join añade automáticamente miembros de la organización a un grupo de recursos con un rol especificado: tanto los miembros que ya están en la organización cuando se habilita auto-join como los nuevos miembros que se unan en el futuro.

Esto es útil para los grupos de recursos que deben ser accesibles para toda su organización sin necesidad de gestionar la membresía manualmente.

Activar la incorporación automática

• A través de la interfaz: abra la pestaña Settings del Resource Group y marque la opción Automatically include all org members en la sección Auto-include org members, y luego seleccione el rol que desea asignar. La pestaña Users también enlaza allí, mostrando si la inclusión automática está activada o desactivada.
• A través de la API: Consulta Configurar la unión automática a través de la API.

Cuando la incorporación automática está habilitada en un grupo de recursos existente, los miembros actuales de la organización que coincidan con el ámbito seleccionado se añaden de inmediato al grupo con el rol configurado (relleno).

Ámbito de auto-uni

Auto-join puede aplicarse a:

• Todos los miembros de la organización (predeterminado): deja sin marcar Incluir miembros con no_access para excluir a los miembros con el rol de organización no_access.
• Todos los miembros de la organización, incluidos los de no_access: marca Incluir miembros de no_access para incluir a todos los miembros, incluidos aquellos con el rol de organización no_access.

Use solo miembros de Read+ cuando los miembros de no_access deben mantener el acceso únicamente a los grupos de recursos específicos en los que se les añade manualmente o a través de otro flujo de aprovisionamiento.

Auto-join y SCIM

La incorporación automática y la gestión mediante SCIM son mutuamente excluyentes en el mismo grupo de recursos. La incorporación automática añade miembros de la organización de forma automática, mientras que la gestión mediante SCIM implica que solo el IdP controla la membresía. Estos dos comportamientos entran en conflicto, por lo que:

• No se puede habilitar la incorporación automática en un grupo de recursos que esté vinculado a un grupo SCIM.
• No se puede vincular un grupo SCIM a un grupo de recursos que tenga la opción de incorporación automática habilitada.

Para cambiar un grupo de recursos de la incorporación automática a la gestión mediante SCIM (o viceversa), primero desactive la configuración actual.

Invitaciones externas

Puedes compartir grupos de recursos con usuarios fuera de tu organización. Los administradores de la organización activan esta opción con la configuración External invitations, en la pestaña Access settings de la página de configuración de grupos de recursos. Está desactivada de forma predeterminada y no está disponible para organizaciones con managed users.

Los usuarios invitados se unen como colaboradores externos:

• Por defecto, obtienen el rol de organización no_access, por lo que solo ven los recursos de ese grupo de recursos.
• Puedes invitarlos con el rol read o write en el grupo de recursos.
• No es necesario que inicien sesión con el SSO de su organización.

Para invitar a alguien, abre la pestaña Users del Resource Group y añádelo por nombre de usuario. Los miembros de la organización se unen al grupo de inmediato; los externos reciben una invitación. Las invitaciones pendientes aparecen con los usuarios del grupo bajo la insignia “Pending”, y puedes reenviarlas o revocarlas. Usa el filtro External para listar solo a los colaboradores externos.

Compartir un repositorio con colaboradores externos

Los administradores de un grupo de recursos también pueden compartir un repositorio privado desde su página Settings, en la sección Share with external collaborators. Esa sección muestra quién ya forma parte del grupo de recursos del repositorio y permite invitar a colaboradores externos. Cualquier persona que se añada allí obtiene acceso a todos los recursos del grupo de recursos, no solo a ese repositorio.

Si el repositorio aún no está en un Resource Group, los miembros que pueden crear Resource Groups pueden crear uno desde esa sección e invitar a colaboradores al mismo tiempo. Auto-include está activado de forma predeterminada: incluye a los miembros de la organización (excepto aquellos con el rol no_access) en el nuevo grupo mediante auto-join con el rol inherit, de modo que conserven su acceso actual al repositorio. Si lo desactiva, solo los usuarios que agregue al Resource Group, además de los administradores de la organización, podrán verlo.

También puedes gestionar invitaciones externas a través de la API: Invitar a colaboradores externos mediante la API.

Quienes pueden crear grupos de recursos

Por defecto, solo los administradores de la organización pueden crear nuevos Resource Groups. Los administradores de la organización pueden cambiar esto configurando el rol de miembro mínimo requerido para crear Resource Groups en la pestaña Access settings de la página de configuración de Resource Groups.

Las opciones disponibles son:

• Solo administradores (predeterminado): solo los administradores de la organización pueden crear grupos de recursos.
• Write+: los miembros con el rol Write o Admin pueden crear grupos de recursos.
• Contributor+: los miembros con el rol de Contributor, Write o Admin pueden crear grupos de recursos.
• Read+: cualquier miembro de la organización puede crear grupos de recursos, excepto los miembros con el rol de organización no_access.

Cuando un miembro no administrador crea un Resource Group a través de la interfaz de usuario, se le añade automáticamente como admin de ese grupo recién creado. A través de la API, esto no ocurre automáticamente, ya que los llamadores de la API pueden estar creando grupos en nombre de otras personas. Los llamadores de la API que no sean administradores deben incluir al menos un usuario con el rol de administrador en la lista inicial de miembros del grupo.

Acceso granular a las características

Esta función forma parte del plan Enterprise y de los planes superiores.

Los administradores de la organización también pueden controlar quién está autorizado a usar una función de organización determinada, de forma independiente al acceso al repositorio. Esta configuración se encuentra en la pestaña Access settings de la página de configuración de Resource Groups.

Las siguientes funciones pueden restringirse:

• Blog: escritura y publicación de artículos de blog de la organización.
• Colecciones: creación y edición de colecciones de la organización.
• Jobs: ejecución y visualización de Jobs facturados a la organización.
• Inference Endpoints: crear, gestionar y llamar a los Inference Endpoints propiedad de la organización.
• Proveedores de inferencia: solicitudes de Proveedores de inferencia facturadas a la organización.

Para cada una, puedes elegir quién tiene acceso:

• Todos (predeterminado): cada miembro de la organización, según su rol en la organización.
• Solo administradores de la organización: solo los administradores de la organización conservan el acceso.
• Grupos de recursos específicos: solo los miembros de los grupos de recursos seleccionados, según su rol en el grupo.

Los administradores de la organización siempre mantienen acceso a todas las funciones, sin importar la opción seleccionada.

Restringir una función a grupos de recursos específicos controla quién puede usar la función, no dónde. Los miembros de los grupos seleccionados pueden seguir usando la función en cualquier parte de la organización (por ejemplo, creando una colección que no pertenezca a ningún grupo de recursos), mientras que otros miembros pierden el acceso a la función por completo. La restricción nunca otorga permisos adicionales: lo que un miembro puede hacer sigue determinado por su rol en la organización.

Los miembros sin acceso ya no pueden usar la función en el contexto de la organización, tanto desde la API como desde la interfaz de usuario. Las solicitudes de API devuelven un error de autorización. No cambia nada para ellos en su cuenta personal ni en otra organización.

Atribución de costos

Esta función forma parte del plan Enterprise y de los planes superiores.

Los grupos de recursos también funcionan como una unidad de atribución de costos para los servicios de cómputo. Cuando el cómputo se factura a un grupo de recursos, los costos se rastrean de forma independiente por grupo, lo que facilita comprender el gasto entre equipos.

• Spaces: el costo se atribuye automáticamente al grupo de recursos al que pertenece el Space.
• Jobs: establezca namespace en la organización propietaria y pase el ID del grupo de recursos usando resource_group_id en Python, --resource-group-id en la CLI o resourceGroupId en el cuerpo de la solicitud HTTP. Consulte Facturar a un grupo de recursos.
• Proveedores de inferencia: pase el ID del grupo de recursos mediante la cabecera X-HF-Bill-To (o el parámetro bill_to en el SDK). Consulte Facturación para organizaciones de equipo y empresa.
• Endpoints de inferencia: el costo se atribuye automáticamente al grupo de recursos al que pertenece el repositorio de modelos. En este momento no se admiten los endpoints instanciados directamente desde el catálogo integrado de Inference Endpoints.

Puede usar el punto de acceso de API dedicado para recuperar los datos de atribución de costos de los grupos de recursos.

Límites de gasto

Esta función forma parte del plan Enterprise y de los planes superiores.

Además de hacer un seguimiento de los costos, puedes establecer un límite. Los administradores de la organización y los administradores del grupo de recursos pueden configurar límites de gasto mensual en la pestaña Settings del grupo, bajo Spend limits.

Están disponibles dos tipos de límites, ambos expresados en USD:

• Total (todos los productos): limita el gasto de cómputo combinado del grupo.
• Un límite por producto para Inference Providers, Spaces, Jobs y Inference Endpoints, además del total.

Deja un campo vacío para no establecer ningún límite. Cuando se aplican tanto un límite total como un límite por producto, prevalece el más estricto de los dos.

Los límites se aplican al gasto atribuido al grupo durante el mes calendario actual, por lo que un grupo que alcanzó su límite se desbloquea al inicio del mes siguiente o tan pronto como un administrador aumente el límite.

Qué sucede cuando se alcanza un límite

El nuevo uso facturado al grupo de recursos se rechaza con un error de autorización:

• Proveedores de inferencia: las solicitudes facturadas al grupo se rechazan.
• Jobs: la creación, el reenvío o la reanudación de un trabajo en el grupo se rechaza, incluidos los trabajos programados.
• Spaces: la actualización de un Space del grupo a hardware de pago se rechaza.
• Inference Endpoints: se rechazan las solicitudes a los puntos finales que generan un costo para el grupo.

Los trabajos que ya están en ejecución en el grupo también se detienen poco después de alcanzar el límite:

• Los Spaces de pago están en pausa. Los Spaces en hardware gratuito se mantienen sin cambios, al igual que los Spaces que se ejecutan con una concesión de hardware.
• Los Jobs se cancelan, con Resource group spend limit reached como motivo de detención.

Aumentar el límite o el inicio de un nuevo mes permite a los miembros volver a iniciar nuevas cargas de trabajo. Los Spaces y Jobs que se detuvieron no se reinician automáticamente.

También puedes establecer límites de gasto de forma programática, consulta Establecer límites de gasto a través de la API.

API de grupos de recursos

Puedes listar grupos de recursos y añadir usuarios a ellos (o cambiar el rol de organización y las asignaciones de grupo de recursos de un miembro) a través de la API de Hub. Para la referencia completa, los ejemplos y los flujos de trabajo por lotes, consulta la guía Programmatic User Access Control Management.

Update on GitHub