組織向けIBM Quantum Platformのセットアップに関する考慮事項
IBM Quantum® Platformは、IBM Cloud®アカウントのIBM Quantum Compute Serviceインスタンスとワークロードのダッシュボードであり、アクセス管理の簡略化されたビューを提供します。組織のIBM Cloudアカウントは、複数のユーザーと複数のQuantum Computeインスタンスを持つことができ、それぞれに独自の割り当てがあります。Identity and Access Management(IAM)は、どのユーザーがどのサービスインスタンスにアクセスできるかを制御するため、必要に応じて可視性を制限しながらコラボレーションを可能にします。有料プランのサービスインスタンスがある場合、アクセス管理の重要性が高まります。アカウント、ユーザー、インスタンス、アクセスがどのように連携するかの概要については、IBM Cloudアカウント構造を参照してください。このガイドで参照されているアクセスグループ、ポリシー、ロール、リソースグループなどのIAMの概念の詳細については、IBM Cloud IAMドキュメントを参照してください。
このガイドでは、複数のサービスインスタンス(たとえば、チームやワークロードごとに1つのインスタンスを割り当てる場合)を持つ組織のアクセスを設定する際の決定事項とトレードオフについて説明します。
組織に複数のIBM Cloudアカウントがある場合 — 例えば、事業部ごとに個別のアカウントがあり、それぞれが独自のQuantum Computeインスタンスを持っている場合 — それらを単一のIBM Cloud Enterpriseアカウントの下にリンクすることができます。このアカウントには、課金を担当する1つのメインアカウントと1つ以上の子アカウントがあります。子アカウント間でPremiumまたはFlex Planの割り当てを再配分するには、IBM Cloud Support Centerを通じてIBM Quantumサポートにお問い合わせください。詳細については、IBM Cloud Enterpriseアカウントのドキュメントを参照してください。
概要
IBM Cloud®は、このガイドで説明されているメカニズムを実装するためのいくつかの方法を提供しています。カスタムロールの詳細を除き、ほとんどの手順はIBM Cloudに共通するものであり、Quantum Computeに固有のものではありません。
関連するペルソナ
このガイドでは、以下のペルソナが言及されています。
-
ユーザー: Quantum Compute リソース(サービスインスタンス)へのアクセス権を持ち、これらのリソースについて他のユーザーとコラボレーションできる人物。ユーザーのアクセスは管理者によって制御され、サービスインスタンスの作成・削除はできません。
-
クラウド管理者: IBM Quantum Compute リソースを所有し、どのユーザーがこれらのリソースにアクセスできるかを管理するIBM Cloudアカウントオーナー。リソースオーナーとして、有料リソースの使用料金が請求されます。
-
IDP管理者: IDプロバイダー(IDP)でIDおよびその属性を定義する管理者。
用語
このガイドでは以下の用語を使用します。
-
リソース: Cloud UIやCLI、APIを通じて管理できるオブジェクトを指す汎用的なIBM Cloud用語。このガイドでは、_リソース_は Quantum Compute Service インスタンスを指します。
-
サービスインスタンス: Cloudサービス、具体的には IBM Quantum Compute Service を通じた量子コンピューターへのアクセスに使用されます。カタログを通じて定義され、異なる量子コンピューティングBackendへのアクセスを提供するさまざまなプランに基づいて、複数のサービスインスタンスを定義できます。詳細は利用可能なIBM Cloudプランを参照してください。
セットアップの計画
組織向けにIBM Quantum Platformをセットアップする前に、以下の点を決定する必要があります。
-
ユーザーIDはどのように定義しますか? IBM Cloudユーザー、別のIDプロバイダー(IDP)のユーザー、またはその両方を設定できます。
-
別のIDPを使用する場合、ユーザーをアクセスグループに割り当てるのは、クラウド管理者とIDP管理者のどちらですか?
-
IDP管理者が動的ルールを通じてユーザーを割り当てる場合、マッチングキーとして使用するカスタムIDPユーザー属性(たとえば
team属性)が必要です。
-
-
サービスインスタンスはいくつ必要で、それぞれ何に使用しますか? インスタンス名は慎重に計画してください。IBM Quantum Platformのユーザーインターフェースを通じてサービスインスタンスを作成するたびに、プラットフォームはユーザーに代わってIAMへの追加の呼び出しを行い、そのインスタンスへの書き込みアクセスを許可する対応するアクセスグループ(インスタンスと同じ名前に「Collaborators」を付加したもの)を作成します。そのため、インスタンス名はアクセスグループ名にもなります。この追加のステップは、IBM Quantum Platformのユーザーインターフェースを通じてインスタンスを作成した場合にのみ発生します。Terraform、IBM Cloud CLI、またはIBM Cloud APIを使用してインスタンスを作成した場合には発生しません。
-
ワークロードはサービスインスタンスに属し、インスタンスへのアクセス権を持つユーザーはそのワークロードを確認できます。
-
サービスインスタンスは異なるプランに基づくことができ、異なるBackendおよび割り当てへのアクセスを提供します。
-
-
どのユーザーがどのサービスインスタンスにアクセスする必要がありますか?
-
ユーザーはワークロードを削除できるべきですか? サービスインスタンスにワークロードを保持することで、請求コストのトレーサビリティが向上します。
-
各インスタンスに対して自動的に作成されるアクセスグループを使用しますか、それとも独自の追加のアクセスグループを作成しますか、個々のユーザーに直接アクセス権を割り当てますか、あるいはインスタンスをリソースグループに整理しますか?
-
アクセスグループは、IBM Cloudリソースへのユーザーアクセスを制御するための便利で一般的な方法です。IBM Quantum Platformのユーザーインターフェースを通じて作成する各サービスインスタンスには、すでに独自の「Collaborators」アクセスグループがあります。そのグループをそのまま使用することも、IBM Cloudコンソールで追加のアクセスグループを作成して、1つまたは複数のインスタンスにわたってチームまたはワークロードごとにユーザーをグループ化する(たとえば
mlやfinance)こともできます。各アクセスグループは、ユーザーが特定のサービスインスタンスまたはリソースグループにアクセスできるようにするカスタムロールを使用します。ユーザーのグループが同じアクセスを共有する必要がない場合は、アクセスグループを使わずに個々のユーザーに直接アクセス権を割り当てることもできます。- IDP属性に基づく動的ルールを使用してユーザーをアクセスグループに割り当てる場合、互いの部分文字列となる属性値は避けてください。たとえば、
mlとchemlabを属性値として使用すると、mlにマッチするルールはchemlabにもマッチしてしまい、意図せず想定以上のアクセスが付与されます。mlとchem-labのような一意の値を使用するか、意図しない部分文字列マッチを避けるためにプレフィックスやサフィックスを追加してください。
- IDP属性に基づく動的ルールを使用してユーザーをアクセスグループに割り当てる場合、互いの部分文字列となる属性値は避けてください。たとえば、
-
リソースグループは、サービスインスタンスを明確に分離する必要がある場合にのみ使用します。IBM Quantum Platformからサービスインスタンスを作成する際に、そのインスタンスが属するリソースグループを選択できます(タグを追加することもできます)が、リソースグループの作成や管理にはIBM Cloudコンソールを使用する必要があります。リソースグループにさらにサービスインスタンスが作成されると、そのリソースグループへのアクセス権を持つすべてのユーザーは、アクセスグループを更新せずに自動的にそれらを確認できるようになります。リソースグループを使用する場合は、まずアクセスグループを作成してから、それらをリソースグループに割り当てます。
備考サービスインスタンスは1つのリソースグループにのみ属することができ、その割り当てはインスタンスの作成後に変更することはできません。したがって、サービスインスタンスを後でリソースグループ間で移動する必要がある場合、リソースグループでは十分な柔軟性が得られない可能性があります。
-
考慮事項
環境をセットアップする際は、以下の考慮事項を理解しておく必要があります。
より細かい粒度のロールを定義する
カスタムロールは、より細かい粒度のアクセス制御に使用できます。たとえば、サービスインスタンスで完全なアクセス権が必要なユーザーと、サービスインスタンス、プログラム、ワークロードへの読み取りアクセスのみが必要なユーザーがいる場合があります。
それを実現するには、MLreaderとMLwriterなどの2つの異なるカスタムロールを定義します。MLreaderカスタムロールからすべてのキャンセル、削除、更新アクションを削除し、MLwriterカスタムロールにすべてのアクションを含めます。次に、それぞれのロールを2つの異なるアクセスグループに追加します。
動的ルール、つまりIDP管理者がカスタムIDPユーザー属性を通じてアクセスを管理する場合は、互いに部分文字列となるIDPカスタムユーザー属性を使用しないでください。たとえば、mlとmlReaderを使用しないでください。mlの文字列比較ではmlReaderも受け入れてしまいます。この競合を避けるためにMLreaderとMLwriterを使用できます。
例については、カスタムロールの設定を参照してください。
共有ワークロードのアクセス
アクセスはサービスインスタンスに適用されます。したがって、インスタンスへの書き込みアクセス権を持つユーザー(IBM Quantum Platformのユーザーインターフェースによって作成されたインスタンスに対して自動的に作成される「Collaborators」アクセスグループを通じたアクセスを含む)は、自分自身のワークロードをキャンセルできますが、そのインスタンス内の他のユーザーのワークロードを表示およびキャンセルすることもできます。これはIAMの仕組みによるものであり、変更することはできません。
階層構造をシミュレートする
デフォルトでは、各サービスインスタンスのアクセスは、たとえばIBM Quantum Platformのユーザーインターフェースを通じて作成されたインスタンスに対して自動的に作成される「Collaborators」アクセスグループを通じて、独立して管理されます。IAMにはグループの組み込みの階層構造はありませんが、複数のチームのサービスインスタンスを参照するアクセスグループを作成することで、それに近い構造を実現できます。広範なアクセスが必要なユーザーは、各チーム個別のアクセスグループではなく、1つの「トップレベル」グループに追加するだけで済みます。
設定の一貫した繰り返し可能なデプロイ
このガイドの手順は、ユーザー、サービスインスタンス、およびそれらのアクセスマッピングを一貫して繰り返し管理するために自動化できます。テンプレートについてはTerraform IBM Cloud® Providerドキュメントを参照してください。
Terraformを使用して、割り当てと制限の設定、およびquantum-computingサービスインスタンスのBackendアクセスの制限を行うことができます。詳細については、IBM CloudでのTerraformの使用開始を参照してください。
例:
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
}
}
次のステップ
- IBM Quantum Platformのセットアップ手順については、組織向けIBM Quantum Platformの設定を参照してください。
- 利用可能なプランを確認する。
- インスタンスを作成する。
- IBM Cloudアカウント構造を理解する。
- ポリシーとアクセスグループを作成する。
- ユーザーを管理する。
- IAMの詳細については、IBM Cloud IAMドキュメントを参照してください。
- 複数のリンクされたアカウントを管理するには、IBM Cloud Enterpriseドキュメントを参照してください。