Qiskit Runtimeの組織向けプラン¶
個人が複数のプロジェクトに携わるような組織では、Qiskit runtime ガバナンスは複雑に見えるかもしれません。しかし、アクセス管理はユーザーのコラボレーションを容易にし、必要に応じてユーザーやプロジェクトの可視性を制限するために使用することができます。アクセス管理は、有料Qiskit Runtimeリソース、つまりスタンダード・プラン（組織が支払う）を使用するQiskit Runtimeサービスインスタンスに、より関連性が高いです。
概要¶
注釈
IBM Cloudは、このチュートリアルで説明するこれらのメカニズムを実装するためのさまざまな方法を提供します。これらの目的を達成するためには、いくつかの方法があります。さらに、このチュートリアルの手順のほとんどは、カスタムロールの詳細を除き、IBM Cloudに一般的であり、Qiskit Runtimeに固有のものではありません。
関係するペルソナ¶
このチュートリアルでは、いくつかの主要なペルソナを紹介しています：
ユーザー: Qiskit Runtimeリソース（サービスインスタンス）へのアクセスを取得し、これらのリソース上で他のユーザーと共同作業ができる可能性がある人。ユーザーのアクセスは管理者によって制御され、サービスインスタンスを作成または削除することはできません。
Cloud administrator (クラウド管理者): IBM Cloudのアカウント所有者で、Qiskit Runtime リソースを所有し、どのユーザーがこれらのリソースにアクセスできるかを管理します。リソース所有者として、管理者はすべての有料リソースの使用に対して課金されます。
IDP 管理者: IDP（アイデンティティー・プロバイダー）において、IDとその属性を定義する管理者。
専門用語¶
このチュートリアルでは、以下の用語を使用します：
リソース: IBM Cloudの一般的な用語で、Cloudのユーザーインターフェース、CLI、またはAPIを通じて管理できるオブジェクトを指します。このチュートリアルでは、 リソース はQiskit Runtimeサービスのインスタンスです。
サービス・インスタンス: クラウドの機能、具体的には、実機やシミュレーター上での量子コンピューティング、にアクセスするためのサービス・インスタンス。カタログで定義します。同じプラン、または異なるプランに基づいて複数のサービスインスタンスを定義し、異なる量子コンピューティングバックエンドへのアクセスを提供することができます。詳細は Qiskit Runtimeプラン を参照すること。
プロジェクト: ユーザーが同じリソースで作業することを可能にするグループ化された単位です。このチュートリアルでは、
mlとfinanceの2つのプロジェクトを使用します。詳しくは 階層的なプロジェクト構造 を参照してください。注釈
このプロジェクトは、IBM Quantum Platformの “project” の概念とは関係ありません。
意思決定¶
Qiskit Runtimeを組織用にセットアップする前に、これらの決定を行う必要があります。
ユーザー ID はどのように定義されますか？IBM Cloud ユーザー、別の IDP からのユーザー、またはその両方を設定できます。
別のIDPを使用している場合、クラウド管理者とIDP管理者のどちらがプロジェクトリソースにユーザーを割り当てるのでしょうか？
IDP管理者がユーザーをプロジェクトに割り当てる場合、プロジェクトの比較のために (このチュートリアルで意味する)
projectなどのキーとして使用する文字列が必要です。
プロジェクトとは何か、どのサービスインスタンスがそれぞれに所属するのか。プロジェクト名は慎重に計画する必要があります。
プロジェクト名を他のプロジェクト名の部分文字列にしないでください。例えば、
mlとchemlabをプロジェクト名として使用した場合、後でmlのプロジェクトマッチを設定すると、両方の値でトリガーされてしまい、誤って予想以上のアクセス権が付与されてしまいます。代わりに、mlやchem-labのようなユニークな名前を使用してください。また、プレフィックスやサフィックスを使用して、このような意図しない部分一致を避けることもできます。プレフィックス値やサフィックス値とともに命名規則を使用すると、複数のプロジェクトへのアクセスを容易に許可することができます。
量子実験（ジョブ）はサービス・インスタンスに所属し，あるインスタンスにアクセスできるユーザーはそのジョブを見ることができます．
サービス・インスタンスは異なるプランに基づくことができ、実機やシミュレーターのような異なるバックエンドにアクセスできるようになります。詳しくは システムまたはシミュレーターの選択 を参照してください。
どのユーザーがどのプロジェクトにアクセスする必要があるか？
ユーザーはジョブを削除できるようにすべきですか？ジョブをサービス・インスタンスに保存しておくと、コスト請求のための追跡可能性が高まります。この情報は、どのユーザーがジョブを投入したかを追跡する Activity Tracker の監査証跡とうまく結びつきます。
Qiskit Runtimeのサービス・インスタンスを直接参照するアクセスグループを使用するか、リソースグループにサービスを整理するか？
アクセス・グループ は、IBM Cloud リソースへのユーザー アクセスを制御するための便利で一般的な方法です。 これらは、ユーザー アクセスを一貫して割り当てるためのシンプルですが強力な手段です。 プロジェクトごとにアクセス・グループを作成し、ユーザーをアクセス・グループにマッピングします。 各アクセス・グループは、ユーザーが特定の Qiskit Runtime サービス インスタンスまたはリソース グループにアクセスできるようにするカスタム・ロールを使用します。
リソース・グループ は、サービス・インスタンスを明確に分離する必要がある場合にのみ使用されます。 リソース・グループに追加のサービス・インスタンスが作成された場合、リソース・グループにアクセスできるすべてのユーザーは、アクセス・グループを更新しなくても自動的にサービス・インスタンスを参照できます。 リソース・グループの使用を選択した場合は、アクセス・グループを作成してから、それらをリソース・グループに割り当てます。
注釈
サービス・インスタンスは 1 つのリソース・グループにのみ属することができ、インスタンスがリソース・グループに割り当てられた後は変更できません。 これは、リソース・グループの割り当てがサービス・インスタンスの作成時にのみ発生する可能性があることも意味します。 したがって、リソース・グループへのサービス・インスタンスの割り当てを変更する必要がある場合、リソース・グループでは十分な柔軟性が得られない可能性があります。
考慮事項¶
環境をセットアップするときは、次の考慮事項を理解する必要があります。
オーディオビリティ¶
アクティビティ・トラッカーは、Qiskit Runtime サービス・インスタンスで実行された重要なアクションをログに記録します。 イベントの監査証跡を取得するには、Qiskit Runtime インスタンスの領域に Activity Tracker のインスタンスを作成します。 ログに記録されたイベントの詳細については、Qiskit Runtime Activity Tracker ページ を参照してください。
この監査ログにはフィールド initiator_authnName および initiator_authnId が含まれており、これらは Manage → Access (IAM) → Users に表示される名前と一致します。このフィールドを表示するには、ユーザー名をクリックし、IAM ID フィールドの 詳細 をクリックします。
App ID イベントをキャプチャするには、App ID インスタンスを開き、Manage Authentication -> Authentication settings に移動し、Runtime Activity を有効にします。
よりきめ細かい粒度のロールを定義する¶
カスタム・ロールのアクションは、よりきめ細かいアクセス制御に使用できます。たとえば、サービス インスタンスで作業するためにフル・アクセスが必要なユーザーもいれば、サービス・インスタンス、プログラム、およびジョブへの読み取りアクセスのみが必要なユーザーもいます。
これを実現するには、MLreader と MLwriter のような２つの異なるカスタム・ロールを定義します。 MLreader カスタム・ロールからはすべてのキャンセル、削除、および更新ロールを除き、 MLwriter カスタム・ロールにはすべてのアクションを含めます。次に、ロールを２つの異なるアクセス・グループに適宜追加します。
動的ルールを使用する場合、つまり、IDP管理者がカスタムIDPユーザー属性を介してアクセスを管理する場合は、互いの部分文字列にあたるIDPカスタム・ユーザー属性を使用しないでください。たとえば、 ml の文字列比較は mlReader も受け入れるため、 ml と mlReader を使用しないでください。この衝突を避けるために MLreader と MLwriter を使うことができます。
カスタム・ロールを設定する例については、 プロジェクトのアクセス・グループの作成 を参照してください。
他のクラウド・リソース¶
このチュートリアルで使用する手順を使用して、他のクラウド・リソースへのアクセスを管理することもできます。 関連するプロジェクトのアクセス・グループに適切な権限を含めます。
階層型プロジェクト構造¶
このチュートリアルでは、プロジェクトとサービス・インスタンスへのユーザーのマッピングは単純に保たれます。ただし、複数のユーザーをアクセス・グループに関連付け、複数のアクセス・グループからサービス・インスタンスを参照することで、より複雑なマッピングを実装できます。
この方法は、階層構造に対応できます。つまり、IBM Quantum Platform のハブ/グループ/プロジェクトのアクセス構造にユーザーを割り当てる方法に合わせることができます。たとえば、 グループ は、グループのプロジェクトのすべてのサービス・インスタンスに割り当てられるアクセス・グループである可能性があります。グループのすべてのプロジェクトへのアクセス権を取得する必要があるユーザーは、グループのアクセス・グループに追加するだけで済みます。
構成の一貫性および反復可能なデプロイメント¶
このチュートリアルの手順は、ユーザー、プロジェクト、およびそれらの間のマッピングの一貫した反復可能な管理のために自動化できます。テンプレートについては、 Terraform IBM Cloud Provider documentation を参照してください。
次のステップ¶
Qiskit Runtime をセットアップする手順については、 組織におけるQiskit Runtime構成 を参照してください。