IBM Cloud account structure
Before setting up IBM Quantum® Platform, it is important to understand the IBM Cloud® Identity and Access Management (IAM) account structure. As shown in the following high-level diagram, there is an account at the highest level. There is only one account owner, who has exclusive control over billing management.
This account contains multiple users and service instances (such as IBM Qiskit Runtime). Each service instance exists in a specific region and has one plan, so if you want to have multiple plans available to your users, you will have multiple service instances, each associated with a different plan.
Each user is assigned access policies, which grant them various levels of access to service instances. Access policies can be grouped together as an access group.
By default, all users within the account can view one another. In account settings, you can turn on the option to restrict visibility, ensuring only users with permissions for the IAM service can see others. Notably, IBM Cloud doesn't support user groups or group-specific administrators.
Access policies and groups
As described previously, each user can be assigned one or more access policies: individually, as part of an access group, or both.
Within an access policy, you can specify permissions by selecting platform and service roles or creating custom roles. Platform roles define platform-level actions, such as creating or managing instances. Service roles grant access to perform actions within the service, such as invoking a "create jobs" API endpoint (that is, running a job).
This guide describes a simplified representation of the IAM model. For full details, refer to the IBM Cloud IAM documentation.
Roles
There are two families of roles: platform management and service access.
Platform management roles define allowable actions, such as assigning user access and creating service instances for managing resources at the platform level. Platform roles also apply to actions that can be taken within the context of account management services, such as inviting and removing users, managing access groups, and managing service IDs.
Service access roles define allowable actions, such as calling service APIs or accessing a service's dashboard. These roles are customized based on the service that is selected within the policy. In the context of these guides, the service is always Qiskit Runtime.
Performing actions often requires a combination of platform management and service access roles. The writer
service role allows you to run jobs, for example, but not list instances. To list the instance you need at least the viewer
role for the platform. Following are some commonly used roles:
- Creating instances requires the
manager
service access role, as well as theviewer
platform management role on All account management services.NoteUsers with the
viewer
platform management role on All account management services can also view services such as billing. If you want to prevent this extra view access, use the IBM Cloud CLI to give them access to just Resource groups:ibmcloud iam access-group-policy-create <group name> --roles Viewer --resource-type resource-group
- Running jobs requires the
writer
service access role andviewer
platform management role access to the instance.
When creating an access policy (either on an access group or for a user), you can check which actions are part of the role by reviewing the description. For example quantum-computing.job.create - Create a job to run a program
.
The following table provides examples for some of the platform management actions that users can take within the context of the Qiskit Runtime service.
Platform management role | Qiskit Runtime service |
---|---|
Viewer role | View instances and credentials |
Operator role | View instances and manage credentials |
Editor role | Create, delete, edit, and view instances. Manage credentials |
Administrator role | All management actions for services |
The following table provides examples for some of the platform management actions that users can take within the context of the Qiskit Runtime service.
Service access role | Qiskit Runtime actions |
---|---|
Reader | Perform read-only actions, such as viewing jobs |
Writer | Permissions beyond the reader role, including running, updating, and canceling jobs |
Manager | Permissions beyond the writer role, including provisioning instances and setting the instance cost limit |