Considérations pour configurer IBM Quantum Platform pour une organisation

IBM Quantum® Platform est le tableau de bord pour les instances IBM Quantum Compute Service et les charges de travail de ton compte IBM Cloud®, et fournit une vue simplifiée de la gestion des accès. Le compte IBM Cloud d'une organisation peut avoir plusieurs utilisateurs et plusieurs instances Quantum Compute, chacune avec sa propre allocation. La gestion des identités et des accès (IAM) contrôle quels utilisateurs peuvent accéder à quelles instances de service, ce qui te permet d'activer la collaboration tout en restreignant la visibilité si nécessaire. La gestion des accès devient plus pertinente si tu as des instances de service sur des plans payants. Consulte Structure d'un compte IBM Cloud pour un aperçu de la façon dont les comptes, les utilisateurs, les instances et les accès s'articulent entre eux. Consulte la documentation IBM Cloud IAM pour tous les détails sur les concepts IAM référencés dans ce guide, tels que les groupes d'accès, les politiques, les rôles et les groupes de ressources.

Ce guide décrit les décisions et les compromis impliqués dans la configuration de l'accès pour une organisation ayant plusieurs instances de service — par exemple, l'attribution d'une instance par équipe ou charge de travail.

remarque

Si ton organisation possède plusieurs comptes IBM Cloud — par exemple, des comptes distincts par unité commerciale, chacun avec ses propres instances Quantum Compute — tu peux les lier sous un seul compte IBM Cloud Enterprise, qui possède un compte principal responsable de la facturation et un ou plusieurs comptes enfants. Pour redistribuer l'allocation Premium ou Flex Plan entre les comptes enfants, contacte le support IBM Quantum via le centre de support IBM Cloud. Consulte la documentation sur les comptes IBM Cloud Enterprise pour plus de détails.

Vue d'ensemble

remarque

IBM Cloud® propose plusieurs façons de mettre en œuvre les mécanismes décrits dans ce guide. La plupart des étapes sont génériques à IBM Cloud et non spécifiques à Quantum Compute, à l'exception des détails sur les rôles personnalisés.

Personas impliquées

Les personas suivantes sont mentionnées dans ce guide :

• Utilisateur : Une personne qui obtient l'accès aux ressources Quantum Compute (instances de service) et peut potentiellement collaborer avec d'autres utilisateurs sur ces ressources. L'accès des utilisateurs est contrôlé par un administrateur et ils ne peuvent pas créer ni supprimer des instances de service.

• Administrateur Cloud : Un propriétaire de compte IBM Cloud qui possède des ressources IBM Quantum Compute et gère les utilisateurs autorisés à y accéder. En tant que propriétaire des ressources, l'administrateur est facturé pour toute utilisation payante.

• Administrateur IDP : Un administrateur qui définit les identités et leurs attributs dans un fournisseur d'identité (IDP).

Terminologie

Ce guide utilise les termes suivants :

• Ressource : Un terme générique d'IBM Cloud qui désigne un objet pouvant être géré via l'interface utilisateur Cloud, la CLI ou l'API. Dans ce guide, une ressource est une instance de service Quantum Compute.

• Instance de service : Une instance de service est utilisée pour accéder aux services Cloud — plus précisément, aux ordinateurs quantiques, via le service IBM Quantum Compute. Elle est définie via le catalogue. Tu peux définir plusieurs instances de service basées sur des plans identiques ou différents, qui offrent l'accès à différents backends de calcul quantique. Consulte Plans IBM Cloud disponibles pour plus de détails.

Planifier ta configuration

Avant de configurer IBM Quantum Platform pour ton organisation, tu dois prendre ces décisions :

• Comment les identités des utilisateurs sont-elles définies ? Tu peux configurer des utilisateurs IBM Cloud, des utilisateurs provenant d'un autre fournisseur d'identité (IDP), ou les deux.

  • Si tu utilises un IDP différent, est-ce l'administrateur Cloud ou l'administrateur IDP qui assigne les utilisateurs aux groupes d'accès ?

  • Si l'administrateur IDP attribue des utilisateurs via des règles dynamiques, tu as besoin d'un attribut utilisateur IDP personnalisé à utiliser comme clé de correspondance (par exemple, un attribut team).

• De combien d'instances de service as-tu besoin, et à quoi chacune servira-t-elle ? Planifie soigneusement les noms de tes instances. Chaque fois que tu crées une instance de service via l'interface utilisateur d'IBM Quantum Platform, la plateforme effectue un appel supplémentaire à IAM en ton nom pour créer un groupe d'accès correspondant (portant le même nom que l'instance, avec « Collaborators » ajouté) qui accorde un accès en écriture à cette instance. Par conséquent, les noms d'instance deviennent aussi des noms de groupe d'accès. Cette étape supplémentaire ne se produit que lorsque tu crées une instance via l'interface utilisateur d'IBM Quantum Platform. Elle ne se produit pas si tu crées l'instance en utilisant Terraform, l'IBM Cloud CLI, ou l'API IBM Cloud.

  • Les charges de travail appartiennent à des instances de service, et les utilisateurs qui ont accès à une instance peuvent voir ses charges de travail.

  • Les instances de service peuvent être basées sur différents plans, permettant l'accès à différents backends et allocations.

• Quels utilisateurs ont besoin d'accéder à quelles instances de service ?

• Les utilisateurs doivent-ils pouvoir supprimer des charges de travail ? Conserver les charges de travail dans les instances de service offre une meilleure traçabilité pour les coûts de facturation.

• Vas-tu utiliser le groupe d'accès créé automatiquement pour chaque instance, créer des groupes d'accès supplémentaires de ton choix, attribuer un accès directement à des utilisateurs individuels, ou organiser les instances en groupes de ressources ?

  • Les groupes d'accès sont un moyen pratique et courant de contrôler l'accès des utilisateurs aux ressources IBM Cloud. Chaque instance de service que tu crées via l'interface utilisateur d'IBM Quantum Platform dispose déjà de son propre groupe d'accès « Collaborators ». Tu peux utiliser ce groupe tel quel, ou créer des groupes d'accès supplémentaires dans la console IBM Cloud pour regrouper les utilisateurs par équipe ou charge de travail (par exemple, ml et finance) sur une ou plusieurs instances. Chaque groupe d'accès utilise un rôle personnalisé qui permet aux utilisateurs d'accéder à des instances de service ou groupes de ressources spécifiques. Si tu n'as pas besoin qu'un groupe d'utilisateurs partage le même accès, tu peux aussi attribuer un accès directement à des utilisateurs individuels, sans groupe d'accès.

    • Si tu utilises des règles dynamiques basées sur des attributs IDP pour assigner des utilisateurs à des groupes d'accès, évite les valeurs d'attributs qui sont des sous-chaînes les unes des autres. Par exemple, si tu utilises ml et chemlab comme valeurs d'attributs, une règle correspondant à ml correspondrait aussi à chemlab, accordant accidentellement plus d'accès que prévu. Utilise des valeurs uniques telles que ml et chem-lab, ou ajoute des préfixes ou des suffixes pour éviter les correspondances de sous-chaînes involontaires.

  • Les groupes de ressources ne sont utilisés que lorsque tu as besoin de maintenir une séparation claire des instances de service. Lors de la création d'une instance de service depuis IBM Quantum Platform, tu peux sélectionner le groupe de ressources auquel elle appartient (et ajouter des tags), mais tu dois utiliser la console IBM Cloud pour créer ou gérer les groupes de ressources. Si d'autres instances de service sont créées dans un groupe de ressources, tous les utilisateurs ayant accès au groupe de ressources les voient automatiquement, sans mise à jour des groupes d'accès. Si tu choisis d'utiliser des groupes de ressources, crée d'abord des groupes d'accès puis assigne-les à des groupes de ressources.

  remarque

  Une instance de service ne peut appartenir qu'à un seul groupe de ressources, et cette assignation ne peut pas être modifiée après la création de l'instance. Par conséquent, les groupes de ressources risquent de manquer de souplesse si des instances de service doivent plus tard passer d'un groupe de ressources à un autre.

Considérations

Voici les points à prendre en compte lorsque tu configures ton environnement.

Définir des rôles plus granulaires

Les rôles personnalisés peuvent être utilisés pour un contrôle d'accès plus granulaire. Par exemple, certains utilisateurs pourraient avoir besoin d'un accès complet pour travailler sur des instances de service, tandis que d'autres pourraient n'avoir besoin que d'un accès en lecture aux instances de service, aux programmes et aux charges de travail.

Pour y parvenir, définis deux rôles personnalisés différents, tels que MLreader et MLwriter. Supprime toutes les actions d'annulation, de suppression et de mise à jour du rôle personnalisé MLreader, et inclus toutes les actions dans le rôle personnalisé MLwriter. Ensuite, ajoute les rôles à deux groupes d'accès différents en conséquence.

remarque

Lorsque tu utilises des règles dynamiques, c'est-à-dire lorsque l'administrateur de l'IDP gère l'accès via des attributs utilisateur IDP personnalisés, n'utilise pas des attributs utilisateur IDP personnalisés qui sont des sous-chaînes les uns des autres. Par exemple, n'utilise pas ml et mlReader, car la comparaison de chaînes de ml accepterait également mlReader. Tu pourrais utiliser MLreader et MLwriter pour éviter ce conflit.

Pour un exemple, consulte Configurer des rôles personnalisés.

Accès aux charges de travail partagées

L'accès s'applique aux instances de service. Ainsi, les utilisateurs ayant un accès en écriture à une instance (y compris via le groupe d'accès « Collaborators » créé automatiquement pour les instances créées via l'interface utilisateur d'IBM Quantum Platform) peuvent annuler leurs propres charges de travail, mais peuvent également voir et annuler les charges de travail d'autres utilisateurs dans cette instance. Cela découle du fonctionnement d'IAM et ne peut pas être modifié.

Simuler des structures hiérarchiques

Par défaut, l'accès à chaque instance de service est géré indépendamment, par exemple via le groupe d'accès « Collaborators » créé automatiquement pour les instances créées via l'interface utilisateur d'IBM Quantum Platform. IAM ne dispose pas d'une hiérarchie de groupes intégrée, mais tu peux en approximer une en créant des groupes d'accès qui référencent les instances de service de plusieurs équipes. Les utilisateurs ayant besoin d'un accès étendu n'ont besoin d'être ajoutés qu'à un seul groupe de « niveau supérieur », plutôt qu'au groupe d'accès individuel de chaque équipe.

Déploiement cohérent et reproductible de la configuration

Les étapes de ce guide peuvent être automatisées pour une gestion cohérente et reproductible des utilisateurs, des instances de service et des mappages d'accès entre eux. Consulte la documentation du fournisseur IBM Cloud® Terraform pour des modèles.

Tu peux utiliser Terraform pour définir des allocations et des limites, ainsi que pour restreindre l'accès aux backends, pour les instances du service quantum-computing. Consulte Démarrer avec Terraform sur IBM Cloud pour plus d'informations.

Exemple :

resource "ibm_resource_instance" "instance1" {
  name       = "name"
  service    = "quantum-computing"
  plan       = "premium"
  location   = "us-east"
  parameters = {
    usage_allocation_seconds = "10" # Mandatory
    usage_limit_seconds      = "20" # Optional. If omitted, it can
            # continue using time after reaching the allocation
    backends                 = ["ibm_boston"] # Optional
  }
}

Prochaines étapes

Recommandations

• Consulte Configurer IBM Quantum Platform pour une organisation pour les étapes de configuration d'IBM Quantum Platform.
• Comprendre les plans disponibles.
• Créer des instances.
• Comprendre la structure de compte IBM Cloud.
• Créer des politiques et des groupes d'accès.
• Gérer les utilisateurs.
• Documentation IBM Cloud IAM pour tous les détails sur IAM.
• Documentation IBM Cloud Enterprise pour gérer plusieurs comptes liés.