Aller au contenu principal

Considérations pour configurer IBM Quantum Platform pour une organisation

Dans une organisation où les individus peuvent travailler sur plusieurs projets, la gouvernance d'IBM Quantum Platform peut sembler complexe. Cependant, la gestion des accès peut être utilisée pour faciliter la collaboration entre utilisateurs et pour restreindre la visibilité des utilisateurs et des projets si nécessaire. La gestion des accès devient plus importante avec les ressources IBM Quantum Platform qui ne sont pas gratuites — c'est-à-dire les instances de service utilisant des plans payants (facturés aux organisations).

Vue d'ensemble​

remarque

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

Personas impliquées​

Voici les principales personas mentionnées dans ce guide :

  • Utilisateur : Une personne qui obtient l'accès aux ressources IBM Quantum Platform (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 Platform 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 IBM Quantum Platform.

  • Instance de service : Une instance de service est utilisée pour accéder aux services Cloud — plus précisément, aux ordinateurs quantiques. 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 Plan IBM Cloud disponible pour plus de détails.

  • Projet : Une unité de regroupement qui permet aux utilisateurs de travailler sur les mêmes ressources. Ce guide utilise deux projets : ml et finance. Consulte Structures de projets hiérarchiques pour plus d'informations.

    remarque

    Ce projet n'est pas lié au concept de « projet » dans la version classique d'IBM Quantum® Platform.

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 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 ressources de projet ?
    • Si l'administrateur IDP assigne les utilisateurs aux projets, tu as besoin d'une chaîne à utiliser comme clé, telle que project (utilisée dans ce guide) pour les comparaisons de projets.

  • Quels sont les projets et quelles instances de service appartiendront à chacun ? Tu dois planifier soigneusement les noms de tes projets.

    • Ne fais pas en sorte que les noms de projets soient des sous-chaînes d'un autre. Par exemple, si tu utilises ml et chemlab comme noms de projets, puis que tu configures plus tard une correspondance pour ml, cela se déclenchera sur les deux valeurs, accordant accidentellement plus d'accès que prévu. Utilise plutôt des noms uniques comme ml et chem-lab. Tu peux également utiliser des préfixes ou des suffixes pour éviter de telles correspondances involontaires.
    • Utiliser des conventions de nommage avec des préfixes ou des suffixes peut t'aider à accorder facilement l'accès à plusieurs projets.
    • Les expériences quantiques (jobs) appartiennent à des instances de service, et les utilisateurs ayant accès à une instance peuvent voir ses jobs.
    • Les instances de service peuvent être basées sur différents plans, permettant l'accès à différents backends.

  • Quels utilisateurs ont besoin d'accéder à quels projets ?

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

  • Utiliseras-tu des groupes d'accès qui référencent directement les instances de service IBM Quantum Platform ou organiseras-tu les services 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. C'est un moyen simple mais puissant d'assigner de façon cohérente l'accès des utilisateurs. Nous créons un groupe d'accès pour chaque projet et mappons les utilisateurs aux groupes d'accès. Chaque groupe d'accès utilise un rôle personnalisé qui permet aux utilisateurs d'accéder à des instances de service ou des groupes de ressources spécifiques.
    • Les groupes de ressources ne sont utilisés que lorsque tu as besoin de maintenir une séparation claire des instances de service. 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 verront automatiquement sans mise à jour des groupes d'accès. Si tu choisis d'utiliser des groupes de ressources, tu créeras des groupes d'accès puis tu les assigneras à des groupes de ressources.
    remarque

    Une instance de service ne peut appartenir qu'à un seul groupe de ressources, et une fois que les instances sont assignées à des groupes de ressources, elles ne peuvent plus être modifiées. Cela signifie également que l'assignation à un groupe de ressources ne peut se faire qu'à la création de l'instance de service. Par conséquent, les groupes de ressources pourraient ne pas offrir suffisamment de flexibilité si les assignations d'instances de service à des groupes de ressources sont susceptibles de changer.

Considérations​

Tu dois comprendre les considérations suivantes lors de la configuration de ton environnement.

Définir des rôles plus granulaires​

Les actions dans les rôles personnalisés peuvent être utilisées 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 jobs.

Pour y parvenir, définis deux rôles personnalisés différents, tels que MLreader et MLwriter. Supprime tous les rôles 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 du fournisseur d'identité (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 de configuration de rôles personnalisés, consulte Créer des groupes d'accès pour des projets.

Accès aux charges de travail partagées​

Il est important de noter que l'accès s'applique aux instances de service. Ainsi, les utilisateurs ayant un accès en écriture à une instance peuvent annuler leurs propres charges de travail, mais peuvent également voir et annuler les charges de travail d'autres utilisateurs. C'est une fonction du fonctionnement d'IAM et ne peut pas être modifiée.

Autres ressources Cloud​

Les étapes de ce guide peuvent également être utilisées pour gérer l'accès à d'autres ressources Cloud. Inclus les permissions appropriées dans les groupes d'accès des projets concernés.

Structures de projets hiérarchiques​

Dans ce guide, le mappage des utilisateurs aux projets et aux instances de service a été gardé simple. Cependant, en associant plusieurs utilisateurs à des groupes d'accès et en référençant des instances de service depuis plusieurs groupes d'accès, des mappages plus complexes peuvent être mis en œuvre.

Cette méthode peut accommoder une structure hiérarchique. C'est-à-dire qu'elle peut s'aligner sur la façon dont les utilisateurs pourraient être assignés à la structure d'accès Hub/Groupe/Projet dans la version classique d'IBM Quantum® Platform. Par exemple, un groupe pourrait être un groupe d'accès assigné à toutes les instances de service des projets du groupe. Les utilisateurs devant accéder à tous les projets du groupe n'auraient alors qu'à être ajoutés au groupe d'accès du groupe.

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 projets et du mappage entre eux. Consulte la documentation du fournisseur IBM Cloud® Terraform pour des modèles.

Prochaines étapes​

Recommandations