組織向けIBM Quantum Platformのセットアップに関する考慮事項

個人が複数のプロジェクトに取り組む組織では、IBM Quantum Platformのガバナンスが複雑に見える場合があります。しかし、アクセス管理を活用することで、ユーザーのコラボレーションを簡単に実現しつつ、必要に応じてユーザーやプロジェクトの可視性を制限できます。アクセス管理は、無料ではないIBM Quantum Platformリソース、つまり有料プランを使用するサービスインスタンス（組織に請求されるもの）において特に重要になります。

概要

備考

IBM Cloud®は、このガイドで説明するメカニズムを実装するためのさまざまな方法を提供しています。これらの目標を達成する方法は複数あります。また、このガイドのほとんどの手順は、カスタムロールの詳細を除いて、IBM Quantum Platformに固有ではなく、IBM Cloudに共通するものです。

用語

このガイドでは以下の用語を使用します。

リソース: Cloud UIやCLI、APIを通じて管理できるオブジェクトを指す汎用的なIBM Cloud用語。このガイドでは、_リソース_はIBM Quantum Platformサービスインスタンスを指します。
サービスインスタンス: Cloudサービス、具体的には量子コンピューターへのアクセスに使用されます。カタログを通じて定義され、異なる量子コンピューティングBackendへのアクセスを提供するさまざまなプランに基づいて、複数のサービスインスタンスを定義できます。詳細は利用可能なIBM Cloudプランを参照してください。
プロジェクト: ユーザーが同じリソース上で作業できるようにするグループ化単位。このガイドではmlとfinanceの2つのプロジェクトを使用します。詳細は階層的なプロジェクト構造を参照してください。

備考
このプロジェクトは、クラシック版IBM Quantum® Platformの「プロジェクト」概念とは関係ありません。

セットアップの計画

組織向けにIBM Quantum Platformをセットアップする前に、以下の点を決定する必要があります。

ユーザーIDはどのように定義しますか？IBM Cloudユーザー、別のIDPのユーザー、またはその両方を設定できます。
- 別のIDPを使用する場合、クラウド管理者またはIDP管理者がユーザーをプロジェクトリソースに割り当てますか？
- IDP管理者がユーザーをプロジェクトに割り当てる場合、このガイドで使用するprojectのようなキーとして使用する文字列が必要です。
プロジェクトの内容と、それぞれに属するサービスインスタンスは何ですか？プロジェクト名は慎重に計画する必要があります。
- プロジェクト名を別の名前の部分文字列にしないでください。たとえば、プロジェクト名にmlとchemlabを使用した後、mlのプロジェクトマッチを設定すると、両方の値でトリガーされ、意図せず期待以上のアクセスが付与されます。代わりに、mlとchem-labのような一意の名前を使用してください。または、意図しない部分文字列マッチを避けるためにプレフィックスやサフィックスの値を使用してください。
- 命名規則とプレフィックス・サフィックスの値を組み合わせることで、複数のプロジェクトへのアクセスを簡単に許可できます。
- 量子実験（ジョブ）はサービスインスタンスに属し、インスタンスへのアクセス権を持つユーザーはそのジョブを確認できます。
- サービスインスタンスは異なるプランに基づくことができ、異なるBackendへのアクセスを提供します。
どのユーザーがどのプロジェクトにアクセスする必要がありますか？
ユーザーはジョブを削除できるべきですか？サービスインスタンスにジョブを保持することで、請求コストのトレーサビリティが向上します。
IBM Quantum Platformサービスインスタンスを直接参照するアクセスグループを使用しますか、それともサービスをリソースグループにまとめますか？
- アクセスグループは、IBM Cloudリソースのユーザーアクセスを制御する便利で一般的な方法です。ユーザーアクセスを一貫して割り当てるためのシンプルかつ強力な手段です。プロジェクトごとにアクセスグループを作成し、ユーザーをアクセスグループにマッピングします。各アクセスグループは、ユーザーが特定のサービスインスタンスまたはリソースグループにアクセスできるカスタムロールを使用します。
- リソースグループは、サービスインスタンスを明確に分離する必要がある場合にのみ使用します。リソースグループにさらにサービスインスタンスが作成されると、そのリソースグループへのアクセス権を持つすべてのユーザーは、アクセスグループを更新せずに自動的に参照できるようになります。リソースグループを使用する場合は、アクセスグループを作成した後、リソースグループに割り当てます。
備考
サービスインスタンスは1つのリソースグループにのみ属することができ、インスタンスがリソースグループに割り当てられた後は変更できません。つまり、リソースグループへの割り当てはサービスインスタンスの作成時にのみ行えます。したがって、サービスインスタンスとリソースグループの割り当てを変更する必要が生じた場合、リソースグループでは十分な柔軟性が得られない可能性があります。

考慮事項

環境をセットアップする際は、以下の考慮事項を理解しておく必要があります。

より細かい粒度のロールを定義する

カスタムロールのアクションは、より細かい粒度のアクセス制御に使用できます。たとえば、サービスインスタンスで完全なアクセス権が必要なユーザーと、サービスインスタンス、プログラム、ジョブへの読み取りアクセスのみが必要なユーザーがいる場合があります。

それを実現するには、MLreaderとMLwriterなどの2つの異なるカスタムロールを定義します。MLreaderカスタムロールからすべてのキャンセル、削除、更新ロールを削除し、MLwriterカスタムロールにすべてのアクションを含めます。次に、それぞれのロールを2つの異なるアクセスグループに追加します。

備考

動的ルール、つまりIDプロバイダー（IDP）管理者がカスタムIDPユーザー属性を通じてアクセスを管理する場合は、互いに部分文字列となるIDP カスタムユーザー属性を使用しないでください。たとえば、mlとmlReaderを使用しないでください。mlの文字列比較ではmlReaderも受け入れてしまいます。この競合を避けるためにMLreaderとMLwriterを使用できます。

カスタムロールの設定例については、プロジェクトのアクセスグループの作成を参照してください。

共有ワークロードのアクセス

アクセスはサービスインスタンスに適用されることに注意することが重要です。したがって、インスタンスへの「書き込み」アクセス権を持つユーザーは、自分のワークロードをキャンセルできますが、他のユーザーのワークロードを表示またはキャンセルすることもできます。これはIAMの仕組みによるものであり、変更することはできません。

その他のCloudリソース

このガイドの手順は、他のCloudリソースへのアクセス管理にも使用できます。関連するプロジェクトのアクセスグループに適切な権限を追加してください。

階層的なプロジェクト構造

このガイドでは、ユーザーとプロジェクト、サービスインスタンスのマッピングをシンプルに保っています。しかし、複数のユーザーをアクセスグループに関連付け、複数のアクセスグループからサービスインスタンスを参照することで、より複雑なマッピングを実装できます。

この方法は階層構造に対応できます。つまり、クラシック版IBM Quantum® PlatformのHub/Group/Projectアクセス構造にユーザーを割り当てる方法に合わせることができます。たとえば、_グループ_はそのグループのプロジェクトのすべてのサービスインスタンスに割り当てられたアクセスグループにできます。グループのすべてのプロジェクトへのアクセス権が必要なユーザーは、グループのアクセスグループに追加するだけで済みます。

設定の一貫した繰り返し可能なデプロイ

このガイドの手順は、ユーザー、プロジェクト、およびそれらのマッピングを一貫して繰り返し管理するために自動化できます。テンプレートについてはTerraform IBM Cloud® Providerドキュメントを参照してください。

次のステップ

推奨事項

IBM Quantum Platformのセットアップ手順については、組織向けIBM Quantum Platformの設定を参照してください。
利用可能なプランを確認する。
インスタンスを作成する。
IBM Cloudの構造を理解する。
ポリシーとアクセスグループを作成する。
ユーザーを管理する。

概要​

関連するペルソナ​

用語​

セットアップの計画​

考慮事項​

より細かい粒度のロールを定義する​

共有ワークロードのアクセス​

その他のCloudリソース​

階層的なプロジェクト構造​

設定の一貫した繰り返し可能なデプロイ​

次のステップ​

概要

関連するペルソナ

用語