Skip to main contentIBM Quantum Documentation Preview
This is a preview build of IBM Quantum™ documentation. Refer to docs.quantum.ibm.com for the official documentation.

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.

A high level diagram is shown, illustrating the relationships between the account, users, instances, and access policies.
Cloud account structure

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).

Note

This guide describes a simplified representation of the IAM model. For full details, refer to the IBM Cloud IAM documentation.

This diagram illustrates the relationships between access groups, access policies, and user permissions.
Access policies and groups

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 the viewer platform management role on All account management services.
    Note

    Users 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 and viewer 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 roleQiskit Runtime service
Viewer roleView instances and credentials
Operator roleView instances and manage credentials
Editor roleCreate, delete, edit, and view instances. Manage credentials
Administrator roleAll 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 roleQiskit Runtime actions
ReaderPerform read-only actions, such as viewing jobs
WriterPermissions beyond the reader role, including running, updating, and canceling jobs
ManagerPermissions beyond the writer role, including provisioning instances and setting the instance cost limit

Next steps

Recommendations