43 lines
3.0 KiB
Plaintext
43 lines
3.0 KiB
Plaintext
---
|
|
title: Considerations for setting up IBM Quantum Platform in an organization
|
|
description: Considerations when setting up IBM Quantum Platform in an organization
|
|
platform: cloud
|
|
---
|
|
|
|
|
|
# Considerations for setting up IBM Quantum Platform in an organization
|
|
<Admonition type="note">
|
|
This documentation is relevant to the new IBM Quantum® Platform. If you need the previous version, return to the [IBM Quantum Platform Classic documentation.](https://docs.quantum.ibm.com/admin/)
|
|
</Admonition>
|
|
|
|
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.
|
|
|
|
<Admonition type="note">
|
|
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.
|
|
</Admonition>
|
|
|
|
For an example of setting up custom roles, see [Create access groups for projects](/guides/custom-roles).
|
|
|
|
<span id="other-cloud-rsc-org"></span>
|
|
## 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.
|
|
|
|
<span id="nest-org"></span>
|
|
## 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.
|
|
|
|
<span id="repeat-org"></span>
|
|
## 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](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs) for templates. |