Considerations for setting up Qiskit Runtime in an organization
This documentation is relevant to the new IBM Quantum® Platform. If you need the previous version, return to the IBM Quantum Platform Classic documentation.
You should understand the following considerations when setting up your environment.
Define more fine-grained roles
The actions in the custom roles can be used for more fine-grained access control. For example, some users might need full access to work on service instances, while others might only need Read access to service instances, programs, and jobs.
To achieve that, define two different custom roles such as MLreader and MLwriter. Remove all cancel, delete, and update roles from the MLreader custom role, and include all actions in the MLwriter custom role. Next, add the roles to two different access groups accordingly.
When using dynamic rules, that is, when the identity provider (IDP) administrator manages access through custom IDP user attributes, do not use IDP custom user attributes that are substrings of each other. For instance, don't use ml and mlReader, as the string comparison of ml would also accept mlReader. You could use MLreader and MLwriter to avoid this conflict.
For an example of setting up custom roles, see Create access groups for projects.
Other Cloud resources
The steps in this guide can be used to manage access to other Cloud resources as well. Include the appropriate permissions to the access groups of the relevant projects.
Hierarchical project structures
In this guide, the mapping of users to projects and service instances was kept simple. However, by associating several users with access groups and referencing service instances from several access groups, more complex mappings can be implemented.
This method can accommodate a hierarchical structure. That is, it can align to how users might be assigned to the Hub/Group/Project access structure in the classic version of IBM Quantum®Platform. For example, a group could be an access group that is assigned to all service instances of the group's projects. Users who should get access to all of the group's projects would then only have to be added to the group's access group.
Consistent and repeatable deployment of the configuration
The steps of this guide can be automated for consistent and repeatable management of users, projects, and the mapping between those. Refer to the Terraform IBM Cloud® Provider documentation for templates.