Plan de Qiskit Runtime para una organización¶

En una organización donde las personas pueden trabajar en varios proyectos, la gobernabilidad de Qiskit Runtime puede parecer compleja. Sin embargo, la administración del acceso se puede utilizar para habilitar fácilmente la colaboración de usuarios y restringir la visibilidad de usuarios y proyectos cuando sea necesario. Administrar el acceso se vuelve más relevante con los recursos de Qiskit Runtime que no son gratuitos: es decir, las instancias de servicio de Qiskit Runtime que usan el plan Estándar (Standard) (que se cobra a las organizaciones).

Descripción General¶

Nota

IBM Cloud proporciona varias formas de implementar estos mecanismos descritos en este tutorial. Hay varias formas de lograr estos objetivos. Además, la mayoría de los pasos de este tutorial son genéricos para IBM Cloud y no específicos para Qiskit Runtime, excepto los detalles del rol personalizado.

Personas involucradas¶

Hay varias personas principales que se mencionan en este tutorial:

Usuario: Alguien que obtiene acceso a los recursos de Qiskit Runtime (instancias de servicio) y puede colaborar potencialmente con otros usuarios en estos 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 Qiskit Runtime y administra qué usuarios pueden acceder a estos recursos. Como propietario del recurso, al administrador se le cobra por el uso pagado de los recursos.
Administrador de IDP: Un administrador que define identidades y sus atributos en un proveedor de identidad (IDP).

Terminología¶

Este tutorial 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 de Cloud, la CLI o la API. Para este tutorial, un recurso es una instancia del servicio Qiskit Runtime.
Instancia de servicio: una instancia de servicio se utiliza para acceder a las funciones de Cloud. En concreto, computación cuántica sobre dispositivos reales o simuladores. Se define a través del catálogo. Puedes definir varias instancias de servicio basadas en planes iguales o diferentes, que ofrecen acceso a diferentes backends de computación cuántica. Consulta Planes de Qiskit Runtime para obtener más detalles.
Proyecto: Una unidad de agrupación que permite a los usuarios trabajar en los mismos recursos. Este tutorial utiliza dos proyectos; ml y finance. Consulta Estructuras jerárquicas de proyectos para obtener más información.

Nota

Este proyecto no está relacionado con el concepto de “project” en IBM Quantum Platform.

Decisiones¶

Antes de configurar Qiskit Runtime 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 estás utilizando un IDP diferente, ¿el administrador de Cloud o el administrador de IDP asigna usuarios a los recursos del proyecto?
- Si el administrador de IDP asigna usuarios a proyectos, necesitas una cadena a usar como una clave, tal como project (que usa este tutorial) para comparaciones de proyectos.
¿Cuáles son los proyectos y qué instancias de servicio pertenecerán a cada uno? Debes planificar cuidadosamente los nombres de tus proyectos.
- No hagas que los nombres de los proyectos sean subcadenas de otro. Por ejemplo, si usas ml y chemlab para nombres de proyectos, luego configuras una coincidencia de proyecto para ml, se activa en ambos valores, otorgando accidentalmente más acceso de lo esperado. En su lugar, utiliza nombres únicos como ml y chem-lab. Alternativamente, usa valores de prefijo o sufijo para evitar tales coincidencias de subcadena no deseadas.
- El uso de convenciones de nomenclatura, junto con valores de prefijo o sufijo, puede ayudarte a permitir el acceso a varios proyectos fácilmente.
- Los experimentos cuánticos (jobs) pertenecen a instancias de servicio y los usuarios que tienen acceso a una instancia pueden ver sus trabajos.
- Las instancias de servicio pueden basarse en diferentes planes, lo que permite el acceso a diferentes backends como dispositivos reales o simuladores. Consulta Eligir un sistema o simulador para obtener más detalles.
¿Qué usuarios necesitan acceder a qué proyectos?
¿Deberían los usuarios poder eliminar trabajos (jobs)? Mantener trabajos en instancias de servicio brinda más trazabilidad para los costos de facturación. Esta información se combina bien con el seguimiento de auditoría del Activity Tracker, que rastrea qué usuario envió el trabajo.
¿Usarás grupos de acceso que hagan referencia directa a las instancias de servicio de Qiskit Runtime u organizarás los servicios en grupos de recursos?
- Los grupos de acceso son una forma conveniente y común de controlar el acceso de los usuarios a los recursos de IBM Cloud. Son un medio simple pero poderoso para asignar de manera consistente el acceso de los usuarios. Creamos un grupo de acceso para cada proyecto y asignamos usuarios a grupos de acceso. Cada grupo de acceso utiliza un rol personalizado que permite a los usuarios acceder a instancias de servicio o grupos de recursos específicos de Qiskit Runtime.
- Los grupos de recursos se usan solo cuando necesitas mantener una separación clara de las instancias de servicio. Si se crean más instancias de servicio en un grupo de recursos, todos los usuarios que tienen acceso al grupo de recursos las ven automáticamente sin actualizar los grupos de acceso. Si eliges usar grupos de recursos, crearás grupos de acceso y luego los asignarás a grupos de recursos.
Nota

Una instancia de servicio puede pertenecer a un solo grupo de recursos y, una vez que las instancias se asignan a grupos de recursos, no se pueden cambiar. Esto también significa que la asignación del grupo de recursos solo puede ocurrir en la creación de la instancia de servicio. Por lo tanto, es posible que los grupos de recursos no brinden suficiente flexibilidad si es necesario cambiar las asignaciones de instancias de servicio a los grupos de recursos.

Consideraciones¶

Debes comprender las siguientes consideraciones al configurar tu entorno.

Auditabilidad¶

El rastreador de actividad registra acciones significativas realizadas en las instancias del servicio Qiskit Runtime. Crea una instancia de Activity Tracker en la región de tus instancias de Qiskit Runtime para obtener un seguimiento de auditoría de los eventos. Consulta la página Activity Tracker de Qiskit Runtime para obtener detalles sobre los eventos registrados.

Este registro de auditoría contiene los campos initiator_authnName y initiator_authnId, que coinciden con el nombre que se muestra en Manage → Access (IAM) → Users. Para ver este campo, haz clic en el nombre de usuario, luego en Details en el campo IAM ID.

event

Para capturar eventos de App ID, abre tu instancia de App ID, luego dirígete a Manage Authentication -> Authentication settings y habilita Runtime Activity.

Definir roles más detallados¶

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

Para lograrlo, define dos funciones personalizadas diferentes, como MLreader y MLwriter. Elimina todas las funciones de cancelación, eliminación y actualización de la función personalizada MLreader e incluye todas las acciones en la función personalizada MLwriter. A continuación, agrega los roles a dos grupos de acceso diferentes según corresponda.

Cuando se utilicen reglas dinámicas, es decir, cuando el administrador de IDP gestiona el acceso a través de atributos de usuario de IDP personalizados, no utilices atributos de usuario de 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 funciones personalizadas, consulta Crear grupos de acceso para proyectos.

Otros recursos de Cloud¶

Los pasos utilizados en este tutorial también se pueden utilizar para administrar el acceso a otros recursos de Cloud. Incluyendo los permisos apropiados a los grupos de acceso de los proyectos relevantes.

Estructuras jerárquicas de proyectos¶

En este tutorial, 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 hacer referencia a instancias de servicio de 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 pueden asignarse a la estructura de acceso Hub/Group/Project en 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 deberían tener acceso a todos los proyectos del grupo solo tendrían que agregarse al grupo de acceso del grupo.

Despliegue consistente y repetible de la configuración¶

Los pasos de este tutorial se pueden automatizar para una administración consistente y repetible de usuarios, proyectos y el mapeo entre ellos. Consulta la documentación de Terraform IBM Cloud Provider para ver las plantillas.

Siguientes pasos¶

Consulta Configurar Qiskit Runtime para una organización para conocer los pasos para configurar Qiskit Runtime.