Resource Groups and Access Management

5 min read

Resource Groups and Access Management

In November 2017, IBM Cloud added support for resource groups. This enables you to group resources across regions and to manage access to those resources based on their resource groups.  For more information on resource group management, please visit our docs.

Once you’ve created resource groups, let’s take a look at some best practices on how to manage access for those groups.

IAM Access Management Concepts for Resource Groups

IAM fine grained access management supports setting access at multiple levels, depending on the requirements for your account and users. Access can be set at the account level, the resource group level, or to individual service instances or other resources. Access given at the account or resource group level can be limited to only a specific service or region. This allows you to manage access at a very coarse-grained level, a fine-grained level, or somewhere in between, whatever is appropriate for your resources and users.

When granting access to resource groups, it’s also important to know that there are two separate policies:

  • One that governs access to the resource group itself, giving users the ability to view the group, its name, and other characteristics.

  • Another that governs access to the resources within the group.

Commonly you will want to grant a user access to both the group and the resources in it, but there may be cases when you may wish for a user to have access to some of the resources in a group but not the group itself.

Another important concept is that of platform roles and service roles.

  • Platform roles govern a user’s ability to do actions within the IBM Cloud Platform, such as creating, viewing, or deleting an instance of a service, binding a service instance to an application, or managing resource groups.

  • Service roles govern a user’s ability to consume a service by using the service-specific UIs, CLIs, and APIs. Platform roles can be assigned to any service that is Resource Controller-enabled. Service roles can be assigned only to services that have adopted IAM to govern the actions exposed by the service.

Some examples of these types of policies are shown below, followed by a explanation of each policy and how they demonstrate the concepts above:

  1. This policy grants the user the Platform Role “Administrator” on the IBM Bluemix Container Service across the entire account. This allows the user access to all instances of this service and allows him to create instances of the service in any resource group he has at least Viewer role on. Users with the Administrator role on any resource can also grant other users access to that resource.

  2. This policy grants the user the Platform Role “Viewer” on a resource group, but not its member resources. This allows this user visibility to the resource group, which is required to create instances of any service in this resource group.

  3. This policy grants the user the Platform Role “Editor” on all resources in the resource group. A user with Editor role on a resource can edit or delete that resource.

  4. This policy grants the user the Platform Role “Editor” on a single instance of the IBM Bluemix Container Service

  5. This policy grants the user the Service Role “Writer” for a specific resource within a specific instance of the Cloud Object Storage Service. This allows the user to call the service’s APIs to access that resource and perform any action the service allows for the Writer role. To understand what actions a service allows for each role, please consult the service documentation.

  6. This policy grants the user the Platform Role “Administrator” on the entire account. This allows the user to perform any platform actions on any resource in the entire account and also includes the ability to perform management actions on the account such as managing the resource groups in the account.

Access Management Best Practices

IAM Access Control provides a great deal of flexibility in managing access to meet the needs of your account. It’s recommended that you manage access at the broadest level that meets your needs and grant fine-grained access to specific resources only if you need to. This simplifies management for the account administrator and improves performance by keeping the number of policies in your account to the smallest number needed. A few examples:

  1. I have a small account with only 10 users who all work together on a single project. Some of these users need to be able to manage the account and assign other users access. Some of the users need to be able to provision service instances which will incur expenses. Other users are application developers who only need to be able to use the service instances from their application components. All of these users should be granted various roles on the account and the default resource group – there’s no need to create additional resource groups to separate resources or restrict some users from accessing some of the resources. Users can be granted the roles on the account and default resource group that are appropriate to their needs – Administrator on the account for users who need to be able to manage the account and give others access, Editor on the default resource group and its members for users who need to be able to provision service instances, and Writer or Reader on the resource group members for users who only need to use the service instances.

  2. I have an account that includes three different teams who work on three projects. A few users are administrators and need the ability to add new users to the account, create new resource groups, and assign users access to resource groups. The remaining users only need access to the resource group associated with their project. I would assign the administrators account Administrator role. I would assign the remaining users various roles on the resource group and resource group members associated with their project – resource group Editor for those who need to create instances, plus resource group member Reader or Writer for those who need to be able to use instances.

  3. I have an account with multiple resource groups. I have some users who are the administrators for Service A across my entire account and need access to all instances of that service as well as the ability to create instances, but these users don’t need access to any other resources in the account. I would assign these users the Administrator role on Service A at the account level, as well as assigning them Viewer role for all resource groups in the account where they need to be able to create instances.

  4. I have a user in my account who only needs access to a specific resource in one service, for example the ability to write to a Bucket A in IBM Cloud Object Storage. This user shouldn’t be able to see the resource groups in my account or access any other services or any other buckets in this instance of Cloud Object Storage. I would give this user the Writer role on Bucket A in the specific instance of Cloud Object Storage. You can either grant this policy using service-specific interfaces (the Cloud Object Storage UI, in this example) or the main Assign Access UI. The service-specific UI is recommended because it will allow you to choose from a list of resources, while the Assign Access UI does not display resources below the service instance level and you would need to manually enter the CRN to assign policy to those resources.

A Word About Other Access Management Systems

The goal for introducing resource groups to the platform is two-fold – to allow services to be used from all types of infrastructure, including but not limited to Cloud Foundry applications, and to simplify the organization and access management for all types of resources in the IBM Cloud. The goal of IAM is to unify access management across the platform. IAM supports access management both for actions in the platform and it can be adopted by services to manage access for their actions. However, not all services will choose to use IAM initially, and some services with well-established access management systems for their service actions may never use IAM for their actions. Cloud Foundry is one example of this. IBM Cloud will continue to support Cloud Foundry, and Cloud Foundry will continue to use its own access management system, centered around orgs and spaces, for applications that are deployed there. You will notice that there are separate pages in the UI that continue to allow you to manage Cloud Foundry access. Another example is infrastructure services in SoftLayer. SoftLayer will continue to use its well-established permission system to manage access to its services, and this must be managed through the Infrastructure section of the unified console. It’s helpful to understand that IAM will always be the access management system for IBM Cloud Platform, but for individual services they can optionally use IAM or another access control system. Generally if a service uses another access control system, it will be accessed using service-specific interfaces. For Cloud Foundry and SoftLayer we do provide access to those service-specific interfaces through the IBM Cloud console.

Be the first to hear about news, product updates, and innovation from IBM Cloud