Saltar al contenido principal

Consideraciones para configurar IBM Quantum Platform en una organización

En una organización donde los individuos pueden trabajar en varios proyectos, la gobernanza de IBM Quantum Platform puede parecer compleja. Sin embargo, la gestión de accesos permite facilitar la colaboración entre usuarios y restringir la visibilidad de usuarios y proyectos cuando sea necesario. Gestionar el acceso cobra mayor relevancia con los recursos de IBM Quantum Platform que no son gratuitos, es decir, las instancias de servicio que utilizan planes de pago (por los que se factura a las organizaciones).

Descripción general​

nota

IBM Cloud® ofrece diversas formas de implementar los mecanismos descritos en esta guía. Hay varias maneras de alcanzar estos objetivos. Además, la mayoría de los pasos de esta guía son genéricos para IBM Cloud y no específicos de IBM Quantum Platform, excepto los detalles de los roles personalizados.

Personas involucradas​

En esta guía se mencionan varias personas principales:

  • Usuario: Alguien que obtiene acceso a los recursos de IBM Quantum Platform (instancias de servicio) y puede colaborar con otros usuarios en esos recursos. El acceso de los usuarios está controlado por un administrador y no pueden crear ni eliminar instancias de servicio.
  • Administrador de Cloud: Propietario de una cuenta de IBM Cloud que posee los recursos de IBM Quantum Platform y gestiona qué usuarios pueden acceder a ellos. Como dueño de los recursos, el administrador asume los cargos por el uso de cualquier recurso de pago.
  • Administrador de IDP: Un administrador que define identidades y sus atributos en un proveedor de identidad (IDP).

Terminología​

Esta guía utiliza los siguientes términos:

  • Recurso: Término genérico de IBM Cloud que hace referencia a un objeto que se puede gestionar a través de la interfaz de usuario, la CLI o la API de Cloud. En esta guía, un recurso es una instancia de servicio de IBM Quantum Platform.

  • Instancia de servicio: Una instancia de servicio se utiliza para acceder a los servicios de Cloud, específicamente a los ordenadores cuánticos. Se define a través del catálogo. Puedes definir varias instancias de servicio basadas en el mismo plan o en planes distintos, que ofrecen acceso a diferentes backends de computación cuántica. Consulta Plan de IBM Cloud disponible para más detalles.

  • Proyecto: Una unidad de agrupación que permite a los usuarios trabajar con los mismos recursos. Esta guía utiliza dos proyectos: ml y finance. Consulta Estructuras jerárquicas de proyectos para más información.

    nota

    Este proyecto no está relacionado con el concepto de "proyecto" en la versión clásica de IBM Quantum® Platform.

Planifica tu configuración​

Antes de configurar IBM Quantum Platform para tu organización, debes tomar estas decisiones:

  • ¿Cómo se definen las identidades de los usuarios? Puedes configurar usuarios de IBM Cloud, usuarios de otro IDP o ambos.

    • Si usas un IDP diferente, ¿el administrador de Cloud o el administrador del IDP asigna a los usuarios a los recursos del proyecto?
    • Si el administrador del IDP asigna usuarios a los proyectos, necesitas una cadena que se use como clave, como project (que es la que utiliza esta guía) para las comparaciones de proyectos.

  • ¿Cuáles son los proyectos y qué instancias de servicio pertenecerán a cada uno? Debes planificar los nombres de los proyectos con cuidado.

    • No hagas que los nombres de proyectos sean subcadenas de otro. Por ejemplo, si usas ml y chemlab como nombres de proyecto y luego configuras una coincidencia para ml, esta se activará para ambos valores, concediendo más acceso del esperado. En cambio, usa nombres únicos como ml y chem-lab. También puedes usar valores de prefijo o sufijo para evitar este tipo de coincidencias no deseadas.
    • Usar convenciones de nombres junto con valores de prefijo o sufijo puede ayudarte a permitir fácilmente el acceso a varios proyectos.
    • Los experimentos cuánticos (trabajos) pertenecen a instancias de servicio, y los usuarios con acceso a una instancia pueden ver sus trabajos.
    • Las instancias de servicio pueden basarse en diferentes planes, lo que permite el acceso a distintos backends.

  • ¿Qué usuarios necesitan acceder a qué proyectos?

  • ¿Deberían los usuarios poder eliminar trabajos? Mantener los trabajos en las instancias de servicio proporciona mayor trazabilidad para los costes de facturación.

  • ¿Usarás grupos de acceso que referencien directamente instancias de servicio de IBM Quantum Platform u organizarás los servicios en grupos de recursos?

    • Los grupos de acceso son una forma conveniente y habitual de controlar el acceso de usuarios a los recursos de IBM Cloud. Son un medio simple pero poderoso para asignar el acceso de usuarios de forma consistente. Creamos un grupo de acceso para cada proyecto y asignamos usuarios a grupos de acceso. Cada grupo de acceso usa un rol personalizado que permite a los usuarios acceder a instancias de servicio o grupos de recursos específicos.
    • Los grupos de recursos se utilizan solo cuando necesitas mantener una separación clara entre instancias de servicio. Si se crean más instancias de servicio en un grupo de recursos, todos los usuarios con acceso a ese grupo las verán automáticamente sin necesidad de actualizar los grupos de acceso. Si decides usar grupos de recursos, crearás grupos de acceso y luego los asignarás a los grupos de recursos.
    nota

    Una instancia de servicio solo puede pertenecer a un grupo de recursos y, una vez asignadas las instancias a grupos de recursos, no se pueden cambiar. Esto también significa que la asignación al grupo de recursos solo puede ocurrir en el momento de crear la instancia de servicio. Por tanto, los grupos de recursos podrían no ofrecer suficiente flexibilidad si las asignaciones de instancias de servicio a grupos de recursos pudieran necesitar cambios.

Consideraciones​

Debes tener en cuenta las siguientes consideraciones al configurar tu entorno.

Define roles más granulares​

Las acciones de los roles personalizados se pueden usar para un control de acceso más granular. Por ejemplo, algunos usuarios pueden necesitar acceso completo para trabajar con instancias de servicio, mientras que otros solo pueden necesitar acceso de lectura a instancias de servicio, programas y trabajos.

Para lograrlo, define dos roles personalizados distintos, como MLreader y MLwriter. Elimina todos los roles de cancelación, eliminación y actualización del rol personalizado MLreader, e incluye todas las acciones en el rol personalizado MLwriter. Luego, agrega los roles a dos grupos de acceso diferentes de forma correspondiente.

nota

Al usar reglas dinámicas, es decir, cuando el administrador del proveedor de identidad (IDP) gestiona el acceso mediante atributos de usuario IDP personalizados, no uses atributos de usuario IDP personalizados que sean subcadenas entre sí. Por ejemplo, no uses ml y mlReader, ya que la comparación de cadenas de ml también aceptaría mlReader. Podrías usar MLreader y MLwriter para evitar este conflicto.

Para ver un ejemplo de configuración de roles personalizados, consulta Crear grupos de acceso para proyectos.

Acceso compartido a cargas de trabajo​

Es importante tener en cuenta que el acceso se aplica a las instancias de servicio. Por tanto, los usuarios con acceso de escritura a una instancia pueden cancelar sus propias cargas de trabajo, pero también pueden ver y cancelar las cargas de trabajo de otros usuarios. Esta es una función del modo en que funciona IAM y no se puede cambiar.

Otros recursos de Cloud​

Los pasos de esta guía también se pueden usar para gestionar el acceso a otros recursos de Cloud. Incluye los permisos adecuados en los grupos de acceso de los proyectos relevantes.

Estructuras jerárquicas de proyectos​

En esta guía, la asignación de usuarios a proyectos e instancias de servicio se mantuvo simple. Sin embargo, al asociar varios usuarios con grupos de acceso y referenciar instancias de servicio desde varios grupos de acceso, se pueden implementar asignaciones más complejas.

Este método puede adaptarse a una estructura jerárquica. Es decir, puede alinearse con la forma en que los usuarios podrían asignarse a la estructura de acceso Hub/Group/Project en la versión clásica de IBM Quantum® Platform. Por ejemplo, un grupo podría ser un grupo de acceso asignado a todas las instancias de servicio de los proyectos del grupo. Los usuarios que deban tener acceso a todos los proyectos del grupo solo tendrían que agregarse al grupo de acceso de dicho grupo.

Implementación consistente y repetible de la configuración​

Los pasos de esta guía pueden automatizarse para una gestión consistente y repetible de usuarios, proyectos y la asignación entre ellos. Consulta la documentación del proveedor Terraform IBM Cloud® para ver las plantillas.

Próximos pasos​

Recomendaciones