| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2021-04-28 |
organizing resources, organizing resource groups, account best practices, best practices account, access best practice, use cases |
account |
{:shortdesc: .shortdesc} {:codeblock: .codeblock} {:screen: .screen} {:tip: .tip} {:note: .note} {:important: .important} {:term: .term} {:external: target="_blank" .external} {:video: .video}
{: #account_setup}
After you set up your {{site.data.keyword.cloud}} account, you're ready to start planning how you want to organize resources and assign access to identities in your account. These best practices provide you with the basic building blocks to enable successful and secure app development in {{site.data.keyword.cloud_notm}}. {:shortdesc}
The following best practices focus on resources that are enabled for {{site.data.keyword.cloud_notm}} Identity and Access Management (IAM) and that are assigned to resource groups. Cloud Foundry and classic infrastructure services aren't IAM-enabled, which means that they can't be assigned to resource groups.
{: note}
{: #resource-group-strategy}
Use resource groups to organize your account resources{: term} for access control and billing purposes. If you're familiar with using Cloud Foundry spaces, think of organizing resources in resource groups similar to the way you organize resources in spaces.
Administrators can have better control of resource usage at the project environment level if one resource group per project environment is used. For example, a typical project has development, test, and production environments. A project that is named CustApp might have the following resource groups:
- CustApp-Dev
- CustApp-Test
- CustApp-Prod
In this scenario, you might assign a developer fairly wide-ranging access to the development resource group and much tighter or no access to the production resource group.
{: #setting-up-rgs}
All resources that are managed by using IAM access control belong to a resource group. You assign a resource to its resource group when you create it from the catalog. It's important to create your resource groups first because you can't change the assignment of resources after you set it. If you accidentally assign a resource to the wrong resource group, delete the resource and create a new one.
A default resource group is created for you when you create a Lite account, and you're limited to the use of one resource group. If you want to create multiple resource groups, upgrade to a Pay-As-You-Go or Subscription account. {: tip}
{: #tags}
You can use user tags to easily organize and search for the resources in your account. You can also use user tags to help identify specific team usage or cost allocation when you view your exported usage report.
For more information, see Working with tags.
{: #how_access}
After you set up and organize resource groups in your account, you can take advantage of access groups to streamline the access management process. By using access groups, you can minimally manage the number of assigned policies by giving the same access to all identities in an access group.
A policy consists of a subject, target, and role. The subject in this case is the access group. The target is what you want the subject to access, such as a set of resources in a resource group, a service instance, all services in the account, or all instances of a service. The role defines the level of access that is granted.
The most commonly used roles are viewer, editor, operator, and administrator platform roles.
- The viewer role provides the least amount of access for viewing instances and resource groups in an account.
- The operator role includes actions such as the ability to view instances and manage aliases, bindings, and credentials.
- The editor role includes actions the same actions of an operator role but also actions for creating, editing, deleting, and binding service instances.
- The administrator role includes everything for working with a service instance and assigning access to others for that service or instance that the policy is for.
While these are the most popular roles for assigning access in the platform, there are a second set of roles to consider called service roles. The actions mapped to these roles are defined by each service. Typically the actions mapped to these roles relate specifically to the ability to work with a service's APIs and UI.
For more information about the roles that can be assigned, see IAM roles.
{: #limit-policies}
There is a limit on the total number of policies that are allowed in an account. You can leverage a few strategies to ensure that you don't reach the limit and to reduce the amount of time that you spend managing access for the identities in your account (users or service IDs):
- Use the principle of least privilege and assign only the access that is required. This can help you ensure that the identities in your account are limited to only the actions that you want to allow.
- Add resources to a resource group to further minimize the number of required policies. For example, you might have a team working on a project that uses specific resources in your account. Add the team members to an access group with a policy defined to assign access only to the resources that are in a specific resource group. This way, you don't have to assign a policy to each resource for each team member.
- Use access groups to streamline managing access for identities that require the same level of access. You can set up an access group with a specific policy defined, and then add those identities to the group. If the group members need additional access later on, you simply define a new policy for the access group.
- Use access management tags to control access to the resources in your account at scale. By assigning access only to resources that have specific tags attached to them, you can avoid multiple updates to your defined policies.
{: #accessgroup_strategy}
An access group is an organization of users and service IDs in a grouping to which the same IAM access can be granted. All identities in a single access group inherit the same access.
A logical way to assign access to your resource groups and the included resources is by creating one access group per required level of access. Then, you can map each access group to the previously created resource groups. For example, to control access to the CustApp project, you might create the following access groups:
- Auditor-Group
- Developer-Group
- Admin-Group
For the Auditor-Group, assign two access policies that grant viewer access to the CustApp-Test and the CustApp-Prod resources and resource groups. For the Developer-Group, assign two access policies that grant editor access to the CustApp-Dev and CustApp-Test resources and resource groups. For the Admin-Group, assign three access policies that grant administrator access to all three CustApp resource groups and their resources.
You can assign administrator access to everything in an account by creating an access group and assigning two policies to it. To create the first policy, use the IAM services option, and select All Identity and Access enabled services in Account with the Administrator platform role and Manager service role. To create the second policy, use the Account Management option, and select All Account Management Services with the Administrator role assigned. {: tip}
{: #sample_policies}
Review the following sample access policies to help you determine how you might want to assign access to and access group for resources that are organized in resource groups.
- A policy that grants the access group a platform administrator role on the {{site.data.keyword.containerlong_notm}} across the entire account. The users in the access group can access all instances of this service and create instances of the service in any resource group that the they have at least a viewer role assigned. Access group members with an administrator role assigned on any resource can also grant access to that resource.
- A policy that grants the access group a platform viewer role on a resource group, but not its member resources. The users in the access group have visibility to the resource group, which is required to create instances of any service in this resource group.
- A policy that grants the access group a platform editor role on all resources in the resource group. The users in the access group can edit or delete that resource.
- A policy that grants the access group a platform administrator role on the entire account (all IAM-enabled services). The users in the access group can perform any platform actions on any resource in the entire account and management actions, such as managing the resource groups in the account.
{: #usecase_examples}
Review the following use cases to help you prepare a plan that works for your organization. For each use case, it is recommended to use access groups to provide access to a group of users with a minimal number of access policies. By using access groups, you can simply add or remove users from the access groups to assign or revoke access as needed.
{: #account-ten-users}
Some of the users in your account need to manage the account and assign other users access. Some users need to create service instances that incur expenses. Other users are application developers who need to use only the service instances from their application components.
You want to grant all users various roles in the account and the default resource group. You don't need to create more resource groups to separate resources or restrict some users from accessing some of the resources. You can grant the users the roles that are appropriate for their needs by creating an access group for each group of users:
- Create an access group and assign users to the group who need to manage the account and give others access. Then, assign a policy with an administrator role on the all IAM-enabled services and all account management services.
- Create an access group and assign users to the group who need to create service instances. Then, assign a policy with an editor role on the default resource group and a policy with the editor role for any service the users need to create.
- Create an access group and assign users to the group who need to use the service instances in a resource group. Then, assign a policy with a writer or reader role on the service instances that exist in the resource group.
{: #two-teams-projects}
You have two functional projects in your account. Developers working on a project needs access to all of its resources. As an account administrator, you can grant access by creating access groups for each project and incorporating access management tags into each group's access policies.
Flexibility is important, and with IAM, you can share resources between various groups. Let's say you notice that a resource might work well for both projects. You can share a resource between the two projects by tagging the resource and relying on the existing permissions to grant access to the developers. If a project doesn't require a resource anymore, you can simply revoke the developers' access by detaching the appropriate tag from the service instance. Check out the following video to gain a better understanding of how you can use access management tags to manage access to the resources in your account.
{: video output="iframe" data-script="#video-transcript-tags" id="watsonmediaplayer" width="560" height="315" scrolling="no" allowfullscreen webkitallowfullscreen mozAllowFullScreen frameborder="0" style="border: 0 none transparent;"}
{: #video-transcript-tags} {: notoc}
As an account administrator, you can use tags to centrally manage access to the resources in your account at scale.
For example, you have two functional projects: One is called soulmate which is used for Watson language services and storage, and the other one is called Soul-FAQ, which is a support for project soulmate. It uses Watson Assistant and Cloud Object Storage.
To create access management tags as an account administrator, click Manage then Account in the IBM Cloud console. From the Tags page, click Access management tags. To create new tags, type the tag names separated by commas. We're creating two tags: one for the project soulmate and one for the project soul-faq.
Jumping to the resource list you can see all resources on the account. You can tag project-related resources here and view them throughout the account by filtering by tags.
At this point, the developer cannot view the resources because they don't have the correct permissions assigned yet.
An account administrator can give the developer permissions to access the resources on their project using a combination of access-groups and tags.
As an account administrator, click Manage then Access and select Access groups. You have two access groups set up: one for the soulmate project, one for the FAQ.
There's one developer in the soulmate developer's group. There are no policies set up, so the account administrator needs to assign access. To do so, select all services in the account based on specific attributes. Select Access Management Tags to view all the tags that are available in the account. Since you're creating a policy for the project soulmate, select the corresponding tag. The console shows that the project soulmate tag is mapped to three distinct resources.
Next, select some roles. Give the whole group the viewer role so everyone can view the resources in the list as well as all the functional access to these services. Click Assign to create the policy.
Now there are three services available for the developer. They have access to all three resources and any subresources that might exist.
Flexibility is important, so we've made it easy to share resources between various groups. Let's say an account administrator notices that IBM Cloud Object Storage is great for backup purposes and works well with the FAQ project. The account administrator wants to leverage IBM Cloud Object Storage in the soulmate project.
Simply edit the Access management tags. Add the project soulmate tag and click Save.
In the resource list, you can confirm that there are two access management tags attached to the Cloud Object Storage instance.
In addition to the original resources, the developer can now see the Cloud Object Storage resource. The instance is available to anyone who has access to project soulmate or project FAQ.
Let's say you don't want the Tone Analyzer service for the soulmate project anymore. Detaching the project soulmate tag from the Tone Analyzer service revokes the developer's access to that service instance. An account administrator can detach the tag by clicking Edit tags, and deleting the tag from the list.
The Tone Analyzer service instance is no longer included in the developer's list of resources.
When you use access management tags to control access, your team's projects can grow without requiring updates to IAM policies.
{: #three-teams-projects}
A few users in my account are administrators. They need to create new resource groups and assign users access to them. I assign these users to an access group with a policy that has the administrator role assigned on all IAM-enabled services.
The remaining users only need access to the resource group that's associated with their project. I use access groups and assign various roles on the resource group and its members that are associated with their project: an editor role on the resource group for those who need to create instances, plus a reader or writer role on the resource group members for those who need to use those instances.
{: #multi-rgs}
Some of the users in my account are the administrators for a service, Service A, across my entire account, and they need access to all instances of that service and to create instances. These users don’t need access to other resources in the account. I create an access group and assign an administrator role on Service A at the account level, and a policy with the viewer role for any resource groups in the account that they need to be able to create instances in. You can do this by selecting No service access, then select the resource group, and at least viewer role for that resource group. Then, repeat for each resource group that they need access to.
{: #user-specific-resource}
My account includes a user who needs access to only a specific resource in one service, for example, the ability to write to a bucket, Bucket A, in {{site.data.keyword.cos_full_notm}}. This user doesn't need to view the resource groups in my account or access other services or buckets in this instance of {{site.data.keyword.cos_short}}.
I assign the user a writer role on Bucket A in the specific instance of {{site.data.keyword.cos_short}}. I can choose to use the IAM UI or the {{site.data.keyword.cos_short}} UI to assign the role. I use the service-specific UI because I can from a list of resources. The IAM UI doesn't display resources past the service instance level, and I need to manually enter the CRN to assign policy to those resources.
{: #bp-access-next}
Now that you know how to set up your resource groups, organize your resources, and create access groups in your account, you can start inviting users to your account and assigning them access to your access groups.
If you already invited users to your account, you can go to your Users page and start assigning access.