77 lines
5.9 KiB
Plaintext
77 lines
5.9 KiB
Plaintext
---
|
|
title: IBM Cloud account structure
|
|
description: Overview of IBM Cloud accounts, users, instances, and permissions.
|
|
platform: cloud
|
|
---
|
|
|
|
<span id="understand"></span>
|
|
# IBM Cloud account structure
|
|
|
|
Before setting up IBM Quantum® Platform, it is important to understand the IBM Cloud® [Identity and Access Management (IAM) account](https://cloud.ibm.com/docs/account?topic=account-overview) 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:](https://cloud.ibm.com/docs/account?topic=account-iamusermanpol) 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).
|
|
|
|
<Admonition type="Note">
|
|
This guide describes a simplified representation of the IAM model. For full details, refer to the [IBM Cloud IAM documentation.](https://cloud.ibm.com/docs/account?topic=account-iamoverview)
|
|
</Admonition>
|
|
|
|
|
|
|
|
## 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.
|
|
<Admonition type="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:
|
|
```cli
|
|
ibmcloud iam access-group-policy-create <group name> --roles Viewer --resource-type resource-group
|
|
```
|
|
</Admonition>
|
|
- 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 reviwing 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 |
|
|
|
|
## Next steps
|
|
|
|
<Admonition type="tip" title="Recommendations">
|
|
- Create [instances.](instances)
|
|
- [Upgrade from the Open Plan.](upgrade-from-open)
|
|
</Admonition>
|