+

Search Tips   |   Advanced Search

Assigning cluster access

As a cluster administrator, you can define access policies for your Red Hat OpenShift on IBM Cloud clusters to create different levels of access for different users. For example, you can authorize certain users to work with cluster infrastructure resources and others to deploy only containers.


Setting up access to your cluster

Use the following checklist to configure user access in your cluster.

  1. Understand how roles, users, and resources in your account can be managed.
  2. Set the API key for all the regions and resource groups that we want to create clusters in.
  3. Invite users to your account and assign them IBM Cloud IAM roles for the service (containers-kubernetes in the API or CLI, and Kubernetes Service in the console).

    Do not assign IBM Cloud IAM platform roles at the same time as a service role. You must assign platform and service roles separately.

  4. To allow users to bind services to the cluster or to view logs that are forwarded from cluster logging configurations, grant users Cloud Foundry roles for the org and space that the services are deployed to or where logs are collected.
  5. If you use Kubernetes namespaces to isolate resources within the cluster, grant access to namespaces by assigning users IBM Cloud IAM service roles for the namespaces.
  6. For any automation tooling such as in your CI/CD pipeline, set up service accounts and assign the service accounts Kubernetes RBAC permissions.
  7. For other advanced configurations to control access to your cluster resources at the pod level, see Configuring security context constraints (SCCs).


For more information about setting up your account and resources, try out this tutorial about the best practices for organizing users, teams, and applications.



Understanding access policies and roles

Access policies determine the level of access that users in your IBM Cloud account have to resources across the IBM Cloud platform. A policy assigns a user one or more roles that define the scope of access to a single service or to a set of services and resources that are organized together in a resource group. Each service in IBM Cloud might require its own set of access policies.


Pick the right access policy and role for your users

You must define access policies for every user that works with Red Hat OpenShift on IBM Cloud. The scope of an access policy is based on a user's defined role or roles, which determine the actions that the user can perform. Some policies are pre-defined but others can be customized. The same policy is enforced whether the user makes the request from the IBM Cloud console or through the CLI.

The following image shows the different types of permissions and roles, the actions a role can perform, and how the roles relate to each other.

To see the specific Red Hat OpenShift on IBM Cloud permissions that can be performed with each role, check out the User access permissions reference topic.

    IBM Cloud IAM platform and service roles
    Red Hat OpenShift on IBM Cloud uses IBM Cloud Identity and Access Management (IAM) platform and service access roles to grant users access to the cluster.
    • Platform: Platform roles determine the actions that users can perform on cluster infrastructure by using the Red Hat OpenShift on IBM Cloud API, console, and CLI (ibmcloud oc). Platform roles do not grant access to the Kubernetes API. Although platform roles authorize you to perform infrastructure actions on the cluster, they do not grant access to the IBM Cloud infrastructure resources. Access to the IBM Cloud infrastructure resources is determined by the API key that is set for the region. Example actions that are permitted by platform roles are creating or removing clusters, binding services to a cluster, managing networking and storage resources, or adding extra worker nodes.

      You can set the policies for these roles by resource group, region, or cluster instance. You cannot scope a platform role by namespace within a cluster.

      If you assign only platform roles to users, they cannot interact with Kubernetes resources within the cluster. They can, however, still perform the ibmcloud oc cluster config command. Then, you can authorize the users to perform select Kubernetes actions by using custom RBAC policies. We might do this if your organization currently uses custom RBAC policies to control Kubernetes access and plans to continue using custom RBAC instead of service roles.
    • Service: Service roles grant corresponding Kubernetes RBAC policies that a user is given within a cluster. As such, service roles grant access to the Kubernetes API, dashboard, and CLI (oc). Example actions that are permitted by service roles are creating app deployments, adding namespaces, or setting up configmaps.

      You can scope the policy for service roles by resource group, region, or cluster instance. Further, you can also scope service roles to Kubernetes namespaces that are in all, individual, or region-wide clusters. When you scope a service role to a namespace, you cannot apply the policy to a resource group or assign a platform role at the same time.

      If you assigned only service roles to users, the users must be given the cluster master URL to open the OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, give the users the platform Viewer role.

    When you configure permissions for Red Hat OpenShift on IBM Cloud in IAM, use the name containers-kubernetes for the API or CLI, and Kubernetes Service for the console.

    RBAC
    In Kubernetes, role-based access control (RBAC) is a way of securing the resources inside your cluster. RBAC roles determine the Kubernetes actions that users can perform on those resources. Every user who is assigned a service role is automatically assigned a corresponding RBAC cluster role. This RBAC cluster role is applied either in a specific namespace or in all namespaces, depending on whether you scope the policy to a namespace.

    Example actions that are permitted by RBAC roles are creating objects such as pods or reading pod logs.

    Classic infrastructure
    Classic infrastructure roles enable access to your classic IBM Cloud infrastructure resources. Set up a user with Super User infrastructure role, and store this user's infrastructure credentials in an API key. Then, set the API key in each region and resource group that we want to create clusters in. After you set up the API key, other users that you grant access to Red Hat OpenShift on IBM Cloud do not need infrastructure roles as the API key is shared for all users within the region. Instead, IBM Cloud IAM platform roles determine the infrastructure actions that users are allowed to perform. If you don't want to set up the API key with full Super User infrastructure permissions or we need to grant specific device access to users, you can customize infrastructure permissions.

    Example actions that are permitted by infrastructure roles are viewing the details of cluster worker node machines or editing networking and storage resources.

    VPC clusters do not need classic infrastructure permissions. Instead, you assign Administrator platform access to the VPC Infrastructure service in IBM Cloud. Then, these credentials are stored in the API key for each region and resource group that you create clusters in.

    Cloud Foundry
    Not all services can be managed with IBM Cloud IAM. If you're using one of these services, you can continue to use Cloud Foundry user roles to control access to those services. Cloud Foundry roles grant access to organizations and spaces within the account. To see the list of Cloud Foundry-based services in IBM Cloud, run ibmcloud service list.

    Example actions that are permitted by Cloud Foundry roles are creating a new Cloud Foundry service instance or binding a Cloud Foundry service instance to a cluster. To learn more, see the available org and space roles or the steps for managing Cloud Foundry access in the IBM Cloud IAM documentation.

IBM Cloud IAM roles can't be assigned to a service account. Instead, you can directly assign RBAC roles to service accounts.

You must also specify whether users have access to one cluster in a resource group, all clusters in a resource group, or all clusters in all resource groups in your account.


Scope user access to cluster instances, namespaces, or resource groups

In IBM Cloud IAM, you can assign user access roles to resource instances, Kubernetes namespaces (projects in OpenShift ), or resource groups.

When you create your IBM Cloud account, the default resource group is created automatically. If you do not specify a resource group when you create the resource, resource instances (clusters) automatically belong to the default resource group. In IBM Cloud IAM, a Kubernetes namespace is a resource type of a resource instance (cluster). If we want to add a resource group in your account, see Best practices for setting up your account and Setting up your resource groups.

    Resource instance

    Each IBM Cloud service in your account is a resource that has instances. The instance differs by service. For example, in Red Hat OpenShift on IBM Cloud, the instance is a cluster, but in IBM Cloud Certificate Manager, the instance is a certificate. By default, resources belong to the default resource group in your account. You can assign users an access role to a resource instance to grant permissions as described in the following scenarios.

    • All IBM Cloud IAM services in your account, including all clusters in Red Hat OpenShift on IBM Cloud and images in IBM Cloud Container Registry.
    • All instances within a service, such as all the clusters in Red Hat OpenShift on IBM Cloud.
    • All instances within a region of a service, such as all the clusters in the US South region of Red Hat OpenShift on IBM Cloud.
    • To an individual instance, such as one cluster.

    Kubernetes namespace (projects in OpenShift )

    As part of cluster resource instances in IBM Cloud IAM, you can assign users with service access roles to namespaces within your clusters.

    When you assign access to a namespace, the policy applies to all current and future instances of the namespace in all the clusters that you authorize. For example, say that we want a dev group of users to be able to deploy Kubernetes resources in a test namespace in all your clusters in AP North. If you assign the dev access group the Writer service access role for the Kubernetes namespace test in all clusters in the AP North region within the default resource group, the dev group can access the test namespace in any AP North cluster in the default resource group that currently has or eventually has a test namespace.

    If you scope a service role to a namespace, you cannot apply the policy to a resource group or assign a platform role at the same time.

    Resource group

    You can organize your account resources in customizable groupings so that you can quickly assign individual or groups of users access to more than one resource at a time. Resource groups can help operators and administrators filter resources to view their current usage, troubleshoot issues, and manage teams.

    A cluster can be created in only one resource group that you can't change afterward. If you create a cluster in the wrong resource group, we must delete the cluster and re-create it in the correct resource group. Furthermore, if you need to use the ibmcloud oc cluster service bind command to integrate with an IBM Cloud service, that service must be in the same resource group as the cluster. Services that do not use resource groups like IBM Cloud Container Registry or that do not need service binding like IBM Log Analysis with LogDNA work even if the cluster is in a different resource group.

    Consider giving clusters unique names across resource groups and regions in your account to avoid naming conflicts. You cannot rename a cluster.

    You can assign users an access role to a resource group to grant permissions as described in the following scenarios. Note that unlike resource instances, you cannot grant access to an individual instance within a resource group.

    • All IBM Cloud IAM services in the resource group, including all clusters in Red Hat OpenShift on IBM Cloud and images in IBM Cloud Container Registry.
    • All instances within a service in the resource group, such as all the clusters in Red Hat OpenShift on IBM Cloud.
    • All instances within a region of a service in the resource group, such as all the clusters in the US South region of Red Hat OpenShift on IBM Cloud.



Setting up the API key to enable access to the infrastructure portfolio

To successfully provision and work with clusters, we must ensure that your IBM Cloud account is correctly set up to access IBM Cloud infrastructure in each resource group and region that your clusters are in. In most cases, you can set up infrastructure access by using the API key. For other options, see Understanding other options than the API key


Setting up the API key in most cases

Your IBM Cloud Pay-As-You-Go or Subscription account is already set up with access to IBM Cloud infrastructure. To use this infrastructure in Red Hat OpenShift on IBM Cloud, the account owner must make sure that an API key is created with appropriate permissions for each region and resource group.

The quickest way to set up the API key is to ask the account owner, who already has the required infrastructure permissions. However, the account owner might want to create a functional ID with all the required infrastructure permissions. Then, if the account owner is unavailable or changes, the API key owner remains the functional ID.

  1. As the account owner, invite a functional ID to your IBM Cloud account to use to set the API key infrastructure credentials, instead of a personal user.
  2. Assign the functional ID the correct permissions.
  3. Log in as the functional ID. 
    ibmcloud login
  4. Target the resource group where we want to set the API key. If you do not target a resource group, the API key is set for the default resource group. To list available resource groups, run ibmcloud resource groups. 
     ibmcloud target -g <resource_group_name>
  5. Create an API key that impersonates your infrastructure permissions. Red Hat OpenShift on IBM Cloud uses this API key to authenticate requests to manage infrastructure in the region and resource group. The previous API key for the region and resource group, if any, is deleted. 
     ibmcloud oc api-key reset --region <region>
  6. Verify that the API key is set up. 
     ibmcloud oc api-key info --cluster <cluster_name_or_ID>
  7. Repeat these steps for each region and resource group that we want to create clusters in.

Now that the API key is set up for the region and resource group, you can assign users IBM Cloud IAM platform roles to restrict what cluster infrastructure actions they can perform.


Understanding other options than the API key

For different ways to access the IBM Cloud infrastructure portfolio, check out the following sections.


Understanding access to the infrastructure portfolio

Determine whether your account has access to the IBM Cloud infrastructure portfolio and learn about how Red Hat OpenShift on IBM Cloud uses the API key to access the portfolio.

Does the classic or VPC infrastructure provider for my cluster affect what access I need to the portfolio?
Access to IBM Cloud infrastructure works differently in classic and VPC clusters. Infrastructure resources for classic clusters are created in a separate IBM Cloud infrastructure account. In most cases, your Pay-As-You-Go or Subscription account is linked to the IBM Cloud infrastructure account so that account owners can access classic IBM Cloud infrastructure automatically. To authorize other users to access classic compute, storage, and networking resources, we must assign classic infrastructure roles.

VPC infrastructure resources are integrated into IAM and as such, we must have the IBM Cloud IAM Administrator platform access role to the VPC Infrastructure service to create and list VPC resources.

For both classic and VPC clusters, the credentials to access infrastructure resources are stored in an API key for the region and resource group of the cluster. To create and manage clusters after the infrastructure permissions are set, assign users IAM access roles to Red Hat OpenShift on IBM Cloud.

Unlike classic, VPC does not support manually setting infrastructure credentials (ibmcloud oc credential set) to use another IBM Cloud infrastructure account to provision worker nodes. You must use your IBM Cloud account's linked infrastructure account.

Does my account already have access to the IBM Cloud infrastructure portfolio?

To access the IBM Cloud infrastructure portfolio, you use an IBM Cloud Pay-As-You-Go or Subscription account. If we have a different type of account, view your options in the following table.

Account description Options to create a standard cluster
Lite accounts cannot provision clusters. Upgrade your Lite account to an IBM Cloud Pay-As-You-Go or Subscription account.
Pay-As-You-Go accounts come with access to the infrastructure portfolio. You can create standard clusters. Use an API key to set up infrastructure permissions for your clusters.

To use a different classic infrastructure account for classic clusters, manually set IBM Cloud infrastructure credentials for your IBM Cloud account. You cannot set up your IBM Cloud account to use the VPC infrastructure of a different account.
Subscription accounts come with access to the infrastructure portfolio. You can create standard clusters. Use an API key to set up infrastructure permissions for your clusters.

To use a different classic infrastructure account for classic clusters, manually set IBM Cloud infrastructure credentials for your IBM Cloud account. You cannot set up your IBM Cloud account to use the VPC infrastructure of a different account.
IBM Cloud infrastructure accounts, no IBM Cloud account

Create an IBM Cloud Pay-As-You-Go or Subscription account. You have two separate IBM Cloud infrastructure accounts and billing.

By default, your new IBM Cloud account uses the new infrastructure account. To continue using the previous classic infrastructure account, manually set the credentials. You can manually set credentials for only classic clusters, not VPC clusters.


Accessing the portfolio with the API key

Red Hat OpenShift on IBM Cloud accesses the IBM Cloud infrastructure portfolio by using an API key. The API key impersonates, or stores the credentials of, a user with access to an IBM Cloud infrastructure account. Red Hat OpenShift on IBM Cloud uses the API key to order resources in IBM Cloud infrastructure, such as new worker nodes or VLANs. You have a different API key for each region within a resource group.

To check if an API key is already set up for the region and resource group, you can use the following command.

ibmcloud oc api-key info --cluster <cluster_name_or_ID>

To enable all users to access the infrastructure portfolio, the user whose credentials are stored in the API key must have the correct permissions. Then, log in as the user or functional ID and perform the first admin action in a region and resource group or reset the API key. For example, one of your admin users creates the first cluster in the default resource group in the us-south region. As a result, the IBM Cloud IAM API key for this admin user is created in the account for this resource group and region.

Other users within the account share the API key for accessing the infrastructure. When users log in to the IBM Cloud account, an IBM Cloud IAM token that is based on the API key is generated for the CLI session and enables infrastructure-related commands to be run in a cluster.

To see the IBM Cloud IAM token for a CLI session, you can run ibmcloud iam oauth-tokens.

If users have access to the portfolio through an IBM Cloud IAM token, how do I limit which commands a user can run?

After you set up access to the portfolio for users in your account, you can then control which infrastructure actions the users can perform by assigning the appropriate platform role. By assigning IBM Cloud IAM roles to users, they are limited in which commands they can run against a cluster. For example, because the API key owner has all the required infrastructure roles, all infrastructure-related commands can be run in a cluster. But, depending on the IBM Cloud IAM role that is assigned to a user, the user can run only some of those infrastructure-related commands.

For example, if we want to create a cluster in a new region, make sure that the first cluster is created by a user with the Super User infrastructure role, such as the account owner. After verification, you can invite individual users or users in IBM Cloud IAM access groups to that region by setting platform management policies for them in that region. A user with a Viewer platform role isn't authorized to add a worker node. Therefore, the worker-add action fails, even though the API key has the correct infrastructure permissions. If you change the user's platform role to Operator, the user is authorized to add a worker node. The worker-add action succeeds because the user is authorized and the API key is set correctly. You don't need to edit the user's IBM Cloud infrastructure permissions.

To audit the actions that users in your account run, you can use Activity Tracker to view all cluster-related events.

What if I don't want to assign the API key owner or credentials owner the Super User infrastructure role?

For compliance, security, or billing reasons, we might not want to give the Super User infrastructure role to the user who sets the API key or whose credentials are set with the ibmcloud oc credential set command. However, if this user doesn't have the Super User role, then infrastructure-related actions, such as creating a cluster or reloading a worker node, can fail. Instead of using IBM Cloud IAM platform roles to control users' infrastructure access, we must set specific IBM Cloud infrastructure permissions for users.

What happens if the user who set up the API key for a region and resource group leaves the company?

If the user is leaving your organization, the IBM Cloud account owner can remove that user's permissions. However, before you remove a user's specific access permissions or remove a user from your account completely, we must reset the API key with another user's infrastructure credentials. Otherwise, the other users in the account might lose access to the IBM Cloud infrastructure portal and infrastructure-related commands might fail. For more information, see Removing user permissions.

How can I lock down my cluster if my API key becomes compromised?

If an API key that is set for a region and resource group in your cluster is compromised, delete it so that no further calls can be made by using the API key as authentication. For more information about securing access to the Kubernetes API server, see the Kubernetes API server and etcd security topic.

How do I set up the API key for my cluster?

It depends on what type of account that you're using to access the IBM Cloud infrastructure portfolio:


Ensuring that the API key or infrastructure credentials owner has the correct permissions

To ensure that all infrastructure-related actions can be successfully completed in the cluster, the user whose credentials we want to set for the API key must have the proper permissions. Consider using a functional ID user for the API key owner instead of a personal user. In case the person leaves the team, the functional ID user remains the API key owner.

  1. Log in to the IBM Cloud console.

  2. To make sure that all account-related actions can be successfully performed, verify that the user has the correct IBM Cloud IAM platform roles.

    1. From the menu bar, select Manage > Access (IAM), and then click the Users page.
    2. Click the name of the user who we want to set the API key for or whose credentials we want to set for the API key, and then click the Access policies tab.
    3. Assign the user the minimum permissions that are needed to create and manage clusters.

  3. To make sure that all infrastructure-related actions in your cluster can be successfully performed, verify that the user has the correct infrastructure access policies.

    1. From the menu bar, select Manage > Access (IAM).
    2. Select the Users tab, click on the user. The required infrastructure permissions vary depending on what type of cluster infrastructure provider you use, classic or VPC.
      • For classic clusters:
      • In the API keys pane, verify that the user has a Classic infrastructure API key, or click Create an IBM Cloud API key. For more information, see Managing classic infrastructure API keys.
      • Click the Classic infrastructure tab and then click the Permissions tab.
      • If the user doesn't have each category checked, you can use the Permission sets drop-down list to assign the Super User role. Or you can expand each category and give the user the required infrastructure permissions.
      • For VPC clusters: Assign the user the Administrator platform role for VPC Infrastructure.


Accessing the infrastructure portfolio with your IBM Cloud Pay-As-You-Go or Subscription account

IBM Cloud Pay-As-You-Go and Subscription accounts are automatically set up with an IBM Cloud infrastructure account that allows access to classic infrastructure resources. The API key that you set is used to order infrastructure resources from this infrastructure account, such as new worker nodes or VLANs.

You can find the current API key owner by running ibmcloud oc api-key info --cluster <cluster>. If we find that we need to update the API key that is stored for a region, you can do so by running the ibmcloud oc api-key reset --region <region> command. This command requires the Red Hat OpenShift on IBM Cloud admin access policy and stores the API key of the user that executes this command in the account.

Be sure that we want to reset the key and understand the impact to your app. The key is used in several different places and can cause breaking changes if it's unnecessarily changed.

Before beginning:

To set up the API key to access the IBM Cloud infrastructure portfolio:

  1. Create an API key for the region and resource group that the cluster is in.

    1. Log in to the terminal with the user whose infrastructure permissions we want to use.
    2. Target the resource group where we want to set the API key. If you do not target a resource group, the API key is set for the default resource group. 
      ibmcloud target -g <resource_group_name>
    3. Set up the API key that has the user's permissions for the region. 
      ibmcloud oc api-key reset --region <region>
    4. Verify that the API key is set up. 
      ibmcloud oc api-key info --cluster <cluster_name_or_ID>

  2. Create a cluster. To create the cluster, the API key credentials that you set up for the region and resource group are used.


Accessing a different classic infrastructure account

Instead of using the default linked IBM Cloud infrastructure account to order infrastructure for clusters within a region, we might want to use a different IBM Cloud infrastructure account that you already have. You can link this infrastructure account to your IBM Cloud account by using the ibmcloud oc credential set command. The IBM Cloud infrastructure credentials are used instead of the default Pay-As-You-Go or Subscription account's credentials that are stored for the region.

You can manually set infrastructure credentials to a different account only for classic clusters, not for VPC clusters.

The IBM Cloud infrastructure credentials that are set by the ibmcloud oc credential set command persist after your session ends. If you remove IBM Cloud infrastructure credentials that were manually set with the ibmcloud oc credential unset --region <region> command, the credentials of the Pay-As-You-Go or Subscription account are used instead. However, this change in infrastructure account credentials might cause orphaned clusters.

Before beginning:

To set infrastructure account credentials to access the IBM Cloud infrastructure portfolio:

  1. Get the infrastructure account that we want to use to access the IBM Cloud infrastructure portfolio. You have different options that depend on your current account type.

  2. Set the infrastructure API credentials with the user for the correct account.

    1. Get the user's infrastructure API credentials. Note that the credentials differ from the IBMid.

      1. From the IBM Cloud console, select Manage > Access (IAM) > Users table and click the username.

      2. In the API Keys section, find or create a classic infrastructure API key.

    2. Set the infrastructure API credentials to use.

      ibmcloud oc credential set --infrastructure-username <infrastructure_API_username> --infrastructure-api-key <infrastructure_API_authentication_key> --region <region>

    3. Verify that the correct credentials are set.

       ibmcloud oc credential get --region <region>

      Example output:

       Infrastructure credentials for user name user@email.com set for resource group default.

  3. Create a cluster. To create the cluster, the infrastructure credentials that you set for the region and resource group are used.

  4. Verify that your cluster uses the infrastructure account credentials that you set.

    1. Open the IBM Cloud clusters console and select your cluster.
    2. In the Overview tab, look for an Infrastructure User field.
    3. If you see that field, you do not use the default infrastructure credentials that come with your Pay-As-You-Go or Subscription account in this region. Instead, the region is set to use the different infrastructure account credentials that you set.




Granting users access to your cluster through IBM Cloud IAM

Set IBM Cloud IAM platform management and service access policies in the IBM Cloud console or CLI so that users can work with clusters in Red Hat OpenShift on IBM Cloud. Before beginning, check out Understanding access policies and roles to review what policies are, whom you can assign policies to, and what resources can be granted policies.

IBM Cloud IAM roles can't be assigned to a service account. Instead, you can directly assign RBAC roles to service accounts.


Example use cases and roles

Wondering which access roles to assign to your cluster users? Use the examples in following table to determine which roles and scope to assign. You can find more information about what roles authorize which types of actions on the user access reference page in the table's links.

Use case Example roles and scope
App auditor Viewer platform role for a cluster, region, or resource group, Reader service role for a cluster, region, or resource group.
App developers Editor platform role for a cluster, Writer service role scoped to a namespace, Cloud Foundry developer space role.
Billing Viewer platform role for a cluster, region, or resource group.
Create a cluster See Permissions to create a cluster.
Cluster administrator Administrator platform role for a cluster, Manager service role not scoped to a namespace (for the whole cluster).
DevOps operator Operator platform role for a cluster, Writer service role not scoped to a namespace (for the whole cluster), Cloud Foundry developer space role.
Operator or site reliability engineer Administrator platform role for a cluster, region, or resource group, Reader service role for a cluster or region or Manager service role for all cluster namespaces to be able to use kubectl top nodes,pods commands.


Assigning IBM Cloud IAM roles with the console

Grant users access to your Red Hat OpenShift on IBM Cloud clusters by assigning IBM Cloud IAM platform management and service access roles with the IBM Cloud console.

Do not assign platform roles at the same time as a service role. You must assign platform and service roles separately.

Before beginning, verify that you're assigned the Administrator platform role for the IBM Cloud account in which you're working.

  1. Log in to the IBM Cloud console. From the menu bar, select Manage > Access (IAM).

  2. Select users individually or create an access group of users.

    • To assign roles to an individual user:
      1. In the left navigation, click the Users page, and then click the name of the user that we want to set permissions for. If the user isn't shown, click Invite users to add them to the account.
      2. Click the Access policies tab, and then click Assign access. Now, the breadcrumbs on the page are Users / Manage User.
      3. Optional: Add the user to an access group that has access to Red Hat OpenShift on IBM Cloud.
    • To assign roles to multiple users in an access group:
      1. In the left navigation, click the Access groups page.
      2. Click Create and give your group a Name and Description. Click Create.
      3. Click Add users to add people to your access group. A list of users that have access to your account is shown.
      4. Check the box next to the users that we want to add to the group. A dialog box displays.
      5. Click Add to group.
      6. Click the Access policies tab.
      7. Click Assign access. Now, the breadcrumbs on the page are Groups / Manage Group.

  3. Assign an access policy to Red Hat OpenShift on IBM Cloud.

    1. Click the IAM services tile.
    2. In the services drop-down list, select Kubernetes Service. You can enter text in the drop-down list instead of scrolling through the list.
    3. Optional: To scope the access policy to a resource group, select the resource group from the resource group drop-down list. If we want to scope the policy to a Kubernetes namespace, make sure to clear the resource group drop-down list. You cannot scope an access policy to both a Kubernetes namespace and a resource group at the same time.
    4. From the Region list, select one or all regions.
    5. From the Cluster string equals drop-down list, select the cluster that we want to scope the access policy to. To scope the policy to all clusters, clear or leave the field blank.
    6. From the Namespace string equals field, enter the Kubernetes namespace that we want to scope the access policy to.

      You cannot scope an access policy to a namespace if you also scope the access policy to a resource group. Additionally, if you scope an access policy to a namespace, we must assign only a service access role. Do not assign a platform access role at the same time as you assign a service access role. Assign a platform role separately.

    7. Select roles for the access policy.
      • Platform access role: Grants access to Red Hat OpenShift on IBM Cloud so that users can manage infrastructure resources such as clusters, worker nodes, worker pools, Ingress application load balancers, and storage. To find a list of supported actions per role, see platform roles reference page.

        If you assign a user the Administrator platform role for only one cluster, we must also assign the user the Viewer platform role for all clusters in that region in the resource group.

      • Service access role: Grants access to the Kubernetes API from within a cluster so that users can manage Kubernetes resources such as pods, deployments, services, and namespaces. To find a list of supported actions per role, see service roles reference page.

        Do not assign a platform role at the same time as you assign a service role. If you also want the user to have a platform role, repeat these steps but leave the namespace field blank and assign only a platform role (do not assign a service access role again).

    8. Click Add.
    9. If you assigned only service roles to users, the users must perform a one-time ibmcloud oc cluster config command and be given the cluster master URL to open the OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, give the users the platform Viewer role.

  4. Assign the users Viewer access to the resource group so that they can work with clusters in resource groups other than default. Note that users must have access to the resource group to create clusters.

    1. Click the IAM services tile.
    2. In the services drop-down list, select No service access.
    3. In the next drop-down list, scope the policy to All resource groups or to particular resource groups.
    4. Select Viewer.
    5. Click Add.

  5. In the side panel, review the Access summary of your changes, and click Assign.

  6. For the user to be added, the RBAC permissions must be synced to the cluster. The user who is granted access must launch the Kubernetes dashboard to initiate the sync. RBAC permissions are cached, so the sync might not be instantaneous.


Assigning IBM Cloud IAM roles with the CLI

Grant users access to your Red Hat OpenShift on IBM Cloud clusters by assigning IBM Cloud IAM platform management and service access roles with the CLI.

Before beginning:


To assign IBM Cloud IAM platform roles from the CLI:

  1. Create an IBM Cloud IAM access policy to set permissions for Red Hat OpenShift on IBM Cloud (--service-name containers-kubernetes). Scope the access policy based on what we want to assign access to.

    Scroll for moreScroll for more
    Scope CLI flag Description
    User N/A You can assign the policy to an individual or group of users. Place this positional argument immediately following the command.
    • Individual user: Enter the email address of the user.
    • Access group: Enter the name of the access group of users. You can create an access group with the ibmcloud iam access-group-create command. To list available access groups, run ibmcloud iam access-groups. To add a user to an access group, run ibmcloud iam access-group-user-add <access_group_name> <user_email>.
    Resource group --resource-group-name You can grant a policy for a resource group. If you do not specify a resource group or a specific cluster ID, the policy applies to all clusters for all resource groups. To list available resource groups, run ibmcloud resource groups.
    Cluster --service-instance You can limit the policy to a single cluster. To list your cluster IDs, run ibmcloud oc cluster ls. Note: If you assign a user the Administrator platform role for only one cluster, you must also assign the user the Viewer platform role for all clusters in the region within the resource group.
    Region --region You can scope the policy to apply to clusters within a particular region. If you do not specify a region or specific cluster ID, the policy applies to all clusters for all regions. To list available regions, review the Previous region column in the Red Hat OpenShift on IBM Cloud locations table.
    Role --role Choose the platform role that we want to assign. Possible values are: Administrator, Operator, Editor, or Viewer.

    Example commands:

    • Assign an individual user the Viewer platform role to one cluster in the default resource group and US East region:

      ibmcloud iam user-policy-create user@email.com --resource-group-name default --service-name containers-kubernetes --region us-east --service-instance clusterID-1111aa2b2bb22bb3333c3c4444dd4ee5 --roles Viewer

    • Assign an individual user Administrator platform access to all clusters in a HR resource group:

      ibmcloud iam user-policy-create user@email.com --resource-group-name HR --service-name containers-kubernetes [--region <region>] --roles Administrator

    • Assign an auditors group of users the Viewer platform role to all clusters in all resource groups:

      ibmcloud iam access-group-policy-create auditors --service-name containers-kubernetes --roles Viewer

  2. Assign the users Viewer access to the resource group so that they can work with clusters in resource groups other than default. Note that users must have access to the resource group to create clusters. You can find the resource group ID by running ibmcloud resource group <resource_group_name> --id.

    • For individual users: 
      ibmcloud iam user-policy-create <user@email.com> --resource-type resource-group --resource <resource_group_ID> --roles Viewer
    • For access groups: 
      ibmcloud iam access-group-policy-create <access_group> --resource-type resource-group --resource <resource_group_ID> --roles Viewer

  3. Verify that the user or access group has the assigned platform role.

    • For individual users: 
      ibmcloud iam user-policies <user@email.com>
    • For access groups: 
      ibmcloud iam access-group-policies <access_group>



To assign IBM Cloud IAM service roles from the CLI:

You cannot scope IBM Cloud IAM service access roles to an IAM access group because the roles are not synced to the RBAC roles within the cluster. If we want to scope RBAC roles to a group of users, we must manually set up groups of users in your cluster instead of using IAM access groups. You can still manage individual users and service accounts with IAM service roles. You can also still scope IAM platform roles to IAM access groups to control actions like ordering worker nodes, because platform roles are never synced to RBAC roles.

  1. Get the user information for the individual user that we want to assign the service role to.

    1. Get your Account ID. 
      ibmcloud account show
    2. For individual users, get the user's userID and ibmUniqueId. 
      ibmcloud account users --account-id <account_ID> --output JSON

  2. Create a policy.json file that scopes the service access role to a Kubernetes namespace in your cluster.

    {
    "subjects": [
        {
   "attributes": [
       {
           "name": "(iam_id)",
           "value": "<user_ID>"
       }
   ]
        }
    ],
    "roles": [
        {
   "role_id": "crn:v1:bluemix:public:iam::::serviceRole:<(Manager|Writer|Reader)>"
        }
    ],
    "resources": [
        {
   "attributes": [
       {
           "name": "accountId",
           "value": "<account_ID>"
       },
       {
           "name": "serviceName",
           "value": "containers-kubernetes"
       },
       {
           "name": "serviceInstance",
           "value": "<cluster_ID1,cluster_ID2>"
       },
       {
           "name": "namespace",
           "value": "<namespace_name>"
       }
   ]
        }
    ]
}
    Scroll for moreScroll for more
    Component Description
    subjects.attributes Enter the IBM Cloud IAM details for the individual user or access group that you previously retrieved.
    • For individual users, set iam_id for the name field. Enter the previously retrieved ibmUniqueId for the value field.
    roles.role_id Choose the IAM service access role that we want to assign. Possible values are:
    • crn:v1:bluemix:public:iam::::serviceRole:Manager
    • crn:v1:bluemix:public:iam::::serviceRole:Writer
    • crn:v1:bluemix:public:iam::::serviceRole:Reader
    resources.attributes Configure the scope of the policy to your account, cluster, and namespace. Leave the "name" fields as given in the example, and enter certain "value" fields as follows.
    • For "accountId": Enter your IBM Cloud account ID that you previously retrieved
    • For "serviceName": Leave the service name as given: containers-kubernetes.
    • For "serviceInstance": Enter your cluster ID. For multiple clusters, separate with a comma. To get your cluster ID, run ibmcloud oc cluster ls.
    • For "namespace": Enter a Kubernetes namespace in your cluster. To list the namespaces in your cluster, run oc get namespaces.

      To assign the access policy to all namespaces in a cluster, remove the entire {"name": "namespace", "value": "<namespace_name"} entry.

  3. Apply the IBM Cloud IAM policy to an individual user.

    • For individual users: 
      ibmcloud iam user-policy-create <user@email.com> --file <filepath>/policy.json

  4. If you assigned only service roles to users, the users must be given the cluster master URL to open the OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, give the users the platform Viewer role.

  5. For the changes to take effect, the user that is granted access must refresh the cluster configuration. Users are not added to the role bindings until they individually refresh the cluster configuration, even if you added multiple users at the same time. Users are also not added to a role binding if they have a higher permission. For example, if users have a cluster role and are in a cluster role binding, they are not added to each individual namespace role binding as well.

    ibmcloud oc cluster config --cluster <cluster_name_or_id>

  6. Optional: Verify that the user is added to the corresponding RBAC role binding or cluster role binding. Note that we must be a cluster administrator (Manager service role in all namespaces) to check role bindings and cluster role bindings. Check the role binding or cluster role binding for the role.

    • Reader: 
      oc get rolebinding ibm-view -o yaml -n <namespace>
    • Writer: 
      oc get rolebinding ibm-edit -o yaml -n <namespace>
    • Manager, scoped to a namespace: 
      oc get rolebinding ibm-operate -o yaml -n <namespace>
    • Manager, all namespaces: 
      oc get clusterrolebinding ibm-admin -o yaml

    Example output: You get the following example output if you assign user user@email.com and access group team1 the Reader service role, and then run oc get rolebinding ibm-view -o yaml -n default.

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: 2018-05-23T14:34:24Z
  name: ibm-view
  namespace: default
  resourceVersion: "8192510"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/ibm-view
  uid: 63f62887-5e96-11e8-8a75-b229c11ba64a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: IAM#user@email.com
- apiGroup: rbac.authorization.k8s.io
  kind: group
  name: team1



Assigning RBAC permissions

Use RBAC roles to define the actions that a user can take to work with the Kubernetes resources in your cluster.


Understanding RBAC permissions

What are RBAC roles and cluster roles?
RBAC roles and cluster roles define a set of permissions for how users can interact with Kubernetes resources in your cluster. A role is scoped to resources within a specific namespace, like a deployment. A cluster role is scoped to cluster-wide resources, like worker nodes, or to namespace-scoped resources that can be found in each namespace, like pods.

What are RBAC role bindings and cluster role bindings?
Role bindings apply RBAC roles or cluster roles to a specific namespace. When you use a role binding to apply a role, you give a user access to a specific resource in a specific namespace. When you use a role binding to apply a cluster role, you give a user access to namespace-scoped resources that can be found in each namespace, like pods, but only within a specific namespace.

Cluster role bindings apply RBAC cluster roles to all namespaces in the cluster. When you use a cluster role binding to apply a cluster role, you give a user access to cluster-wide resources, like worker nodes, or to namespace-scoped resources in every namespace, like pods.

What do these roles look like in my cluster?
If we want users to be able to interact with Kubernetes resources from within a cluster, we must assign user access to one or more namespaces through IBM Cloud IAM service roles. Every user who is assigned a service role is automatically assigned a corresponding RBAC cluster role. These RBAC cluster roles are predefined and permit users to interact with Kubernetes resources in your cluster. Additionally, a role binding is created to apply the cluster role to a specific namespace, or a cluster role binding is created to apply the cluster role to all namespaces.

To learn more about the actions permitted by each RBAC role, check out the IBM Cloud IAM service roles reference topic. To see the permissions that are granted by each RBAC role to individual Kubernetes resources, check out Kubernetes resource permissions per RBAC role.

All users of an OpenShift cluster are added to the following OpenShift RBAC groups by cluster version. Version 3 clusters: basic-users and self-provisioners. Version 4 clusters: basic-users.

Can I create custom roles or cluster roles?
The view, edit, admin, and cluster-admin cluster roles are predefined roles that are automatically created when you assign a user the corresponding IBM Cloud IAM service role. To grant other Kubernetes permissions, you can create custom RBAC permissions. Custom RBAC roles are in addition to and do not change or override any RBAC roles that we might have assigned with service access roles. Note that to create custom RBAC permissions, we must have the IAM Manager service access role that gives you the cluster-admin Kubernetes RBAC role. However, the other users do not need an IAM service access role if you manage your own custom Kubernetes RBAC roles.

Making your own custom RBAC policies? Be sure not to edit the existing IBM role bindings that are in the cluster, or name new role bindings with the same name. Any changes to IBM-provided RBAC role bindings are overwritten periodically. Instead, create your own role bindings.

Can I assign custom RBAC roles to groups of users?
You can manually assign users to groups in your cluster, and then assign roles to the group. However, a known issue is that you cannot use IBM Cloud IAM access groups.

When do I need to use cluster role bindings and role bindings that are not tied to the IBM Cloud IAM permissions that I set?
We might want to authorize who can create and update pods in your cluster. With security context constraints (SCCs), you can use existing cluster role bindings that come with your cluster, or create your own.

We might also want to integrate add-ons to your cluster. For example, when you set up Helm in your cluster, we must create a service account for Tiller in the tiller project and a Kubernetes RBAC cluster role binding for the tiller-deploy pod.


Creating custom RBAC permissions for users, groups, or service accounts

The view, edit, admin, and cluster-admin cluster roles are automatically created when you assign the corresponding IBM Cloud IAM service role. Do we need your cluster access policies to be more granular than these predefined permissions allow? No problem! You can create custom RBAC roles and cluster roles.

You can assign custom RBAC roles and cluster roles to individual users, groups of users, or service accounts. When a binding is created for a group, it affects any user that is added or removed from that group. When you add users to a group, they get the access rights of the group in addition to any individual access rights that you grant them. If they are removed, their access is revoked. Note that you can't add service accounts to access groups.

If we want to assign access to a process that runs in pods, such as a continuous delivery toolchain, you can use Kubernetes ServiceAccounts. To follow a tutorial that demonstrates how to set up service accounts for Travis and Jenkins and to assign custom RBAC roles to the service accounts, see the blog post Kubernetes ServiceAccounts for use in automated systems.

To prevent breaking changes, do not change the predefined view, edit, admin, and cluster-admin cluster roles. Custom RBAC roles are in addition to and do not change or override any RBAC roles that we might have assigned with IBM Cloud IAM service access roles.

Do I create a role or a cluster role? Do I apply it with a role binding or a cluster role binding?

  • Namespace access: To allow a user, access group, or service account to access a resource within a specific namespace, choose one of the following combinations:
    • Create a role, and apply it with a role binding. This option is useful for controlling access to a unique resource that exists only in one namespace, like an app deployment.
    • Create a cluster role, and apply it with a role binding. This option is useful for controlling access to general resources in one namespace, like pods.
  • Cluster-wide access: To allow a user or an access group to access cluster-wide resources or resources in all namespaces, create a cluster role, and apply it with a cluster role binding. This option is useful for controlling access to resources that are not scoped to namespaces, like worker nodes, or resources in all namespaces in your cluster, like pods in each namespace.

Before beginning:

To create custom RBAC permissions:

  1. Create the role or cluster role with the access that we want to assign.

    1. Create a .yaml file to define the role or cluster role.

       kind: Role
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   namespace: default
   name: my_role
 rules:
 - apiGroups: [""]
   resources: ["pods"]
   verbs: ["get", "watch", "list"]
 - apiGroups: ["apps", "extensions"]
   resources: ["daemonsets", "deployments"]
   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
      Scroll for moreScroll for more
      Parameter Description
      kind Use Role to grant access to resources within a specific namespace. Use ClusterRole to grant access to cluster-wide resources such as worker nodes, or to namespace-scoped resources such as pods in all namespaces.
      apiVersion
      • For clusters that run Kubernetes 1.8 or later, use rbac.authorization.k8s.io/v1.
      • For earlier versions, use apiVersion: rbac.authorization.k8s.io/v1beta1.
      metadata.namespace For kind Role only: Specify the Kubernetes namespace to which access is granted.
      metadata.name Name the role or cluster role.
      rules.apiGroups Specify the Kubernetes API groups that we want users to be able to interact with, such as "apps", "batch", or "extensions". For access to the core API group at REST path api/v1, leave the group blank: [""].
      rules.resources Specify the Kubernetes resource types to which we want to grant access, such as "daemonsets", "deployments", "events", or "ingresses". If you specify "nodes", then the kind must be ClusterRole.
      rules.verbs Specify the types of actions that we want users to be able to do, such as "get", "list", "describe", "create", or "delete".

    2. Create the role or cluster role in your cluster.

       oc apply -f my_role.yaml

    3. Verify that the role or cluster role is created.

      • Role:

         oc get roles -n <namespace>

      • Cluster role:

         oc get clusterroles

  2. Bind users to the role or cluster role.

    1. Create a .yaml file to bind users to your role or cluster role. Note the unique URL to use for each subject's name.

       kind: RoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: my_role_binding
   namespace: default
 subjects:
 - kind: User
   name: IAM#user1@example.com
   apiGroup: rbac.authorization.k8s.io
 - kind: Group
   name: team1
   apiGroup: rbac.authorization.k8s.io
 - kind: ServiceAccount
   name: <service_account_name>
   namespace: <kubernetes_namespace>
 roleRef:
   kind: Role
   name: my_role
   apiGroup: rbac.authorization.k8s.io
      Scroll for moreScroll for more
      Parameter Description
      kind
      • Specify RoleBinding for a namespace-specific Role or ClusterRole.
      • Specify ClusterRoleBinding for a cluster-wide ClusterRole.
      apiVersion
      • For clusters that run Kubernetes 1.8 or later, use rbac.authorization.k8s.io/v1.
      • For earlier versions, use apiVersion: rbac.authorization.k8s.io/v1beta1.
      metadata.namespace
      • For kind RoleBinding: Specify the Kubernetes namespace to which access is granted.
      • For kind ClusterRoleBinding: don't use the namespace field.
      metadata.name Name the role binding or cluster role binding.
      subjects.kind Specify the kind as one of the following:
      • User: Bind the RBAC role or cluster role to an individual user in your account.
      • Group: Bind the RBAC role or cluster role to an IBM Cloud IAM access group in your account.
      • ServiceAccount: Bind the RBAC role or cluster role to a service account in a namespace in your cluster.
      subjects.name
      • For User: Append the individual user's email address to IAM# as follows: IAM#user@email.com.
      • For Group: Specify the name of the IBM Cloud IAM access group in your account.
      • For ServiceAccount: Specify the service account name.
      subjects.apiGroup
      • For User or Group: use rbac.authorization.k8s.io.
      • For ServiceAccount: don't include this field.
      subjects.namespace For ServiceAccount only: Specify the name of the Kubernetes namespace that the service account is deployed to.
      roleRef.kind Enter the same value as the kind in the role .yaml file: Role or ClusterRole.
      roleRef.name Enter the name of the role .yaml file.
      roleRef.apiGroup Use rbac.authorization.k8s.io.

    2. Create the role binding or cluster role binding resource in your cluster.

       oc apply -f my_role_binding.yaml

    3. Verify that the binding is created.

      oc get rolebinding -n <namespace>

  3. Optional: To enforce the same level of user access in other namespaces, you can copy the role bindings for those roles or cluster roles to other namespaces.

    1. Copy the role binding from one namespace to another namespace.

       oc get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | oc -n <namespace_2> create -f -

      For example, to copy the custom-role role binding from the default namespace to the testns namespace:

       oc get rolebinding custom-role -o yaml | sed 's/default/testns/g' | oc -n testns create -f -

    2. Verify that the role binding is copied. If you added an IBM Cloud IAM access group to the role binding, each user in that group is added individually, not as an access group ID.

       oc get rolebinding -n <namespace_2>

Now that you created and bound a custom Kubernetes RBAC role or cluster role, follow up with users. Ask them to test an action that they have permission to complete due to the role, such as deleting a pod.


Extending existing permissions by aggregating cluster roles

You can extend your users' existing permissions by aggregating, or combining, cluster roles with other cluster roles. When you assign a user an IBM Cloud service role, the user is added to a corresponding Kubernetes RBAC cluster role. However, we might want to allow certain users to perform additional operations.

For example, a user with the namespace-scoped admin cluster role cannot use the oc top pods command to view pod metrics for all the pods in the namespace. We might aggregate a cluster role so that users in the admin cluster role are authorized to run the top pods command. For more information, see the Kubernetes docs.

What are some common operations that I might want to extend permissions for a default cluster role?
Review the operations that each default RBAC cluster role permits to get a good idea of what your users can do, and then compare the permitted operations to what we want them to be able to do.

If your users in the same cluster role encounter errors similar to the following for the same type of operation, we might want to extend the cluster role to include this operation.

Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAM#myname@example.com" cannot list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"

To aggregate cluster roles:

Before beginning: Access your OpenShift cluster.

  1. Create a cluster role YAML file. In the labels section, specify the existing cluster role that we want to aggregate permissions to. The following example extends the predefined admin cluster role to allow users to run oc top pods. For more examples, see the Kubernetes docs.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-pod-metrics
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
- apiGroups:
  - "metrics.k8s.io"
  resources:
  - pods
  verbs:
  - list
    Scroll for moreScroll for more
    Parameter Description
    metadata.name Enter a name for the cluster role. Do not use the predefined cluster role names: view, edit, admin, and cluster-admin.
    metadata.labels Add a label that matches the cluster role that we want to aggregate to in the format rbac.authorization.k8s.io/aggregate-to-<cluster_role>: "true". The labels for the predefined cluster roles are as follows.
    • IAM Manager service role, scoped to a namespace: rbac.authorization.k8s.io/aggregate-to-admin: "true"
    • IAM Writer service role: rbac.authorization.k8s.io/aggregate-to-edit: "true"
    • IAM Reader service role: rbac.authorization.k8s.io/aggregate-to-view: "true"
    rules.apiGroups Specify the Kubernetes API groups that we want users to be able to interact with, such as "apps", "batch", or "extensions". For access to the core API group at REST path api/v1, leave the group blank: [""].
    rules.resources Specify the Kubernetes resource types to which we want to grant access, such as "daemonsets", "deployments", "events", or "ingresses".
    rules.verbs Specify the types of actions that we want users to be able to do, such as "get", "list", "describe", "create", or "delete".
  2. Create the cluster role in your cluster. Any users that have a role binding to the admin cluster role now have the additional permissions from the view-pod-metrics cluster role. 
    oc apply -f <cluster_role_file.yaml>
  3. Follow up with users that have the admin cluster role. Ask them to refresh their cluster configuration and test the action, such as oc top pods.



Customizing classic infrastructure permissions

When you assign the Super User infrastructure role to the admin or functional ID that sets the API key or whose infrastructure credentials are set, other users within the account share the API key or credentials for performing infrastructure actions. You can then control which infrastructure actions the users can perform by assigning the appropriate IBM Cloud IAM platform role. You don't need to edit the user's IBM Cloud infrastructure permissions.

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see Granting user permissions for VPC resources.

For compliance, security, or billing reasons, we might not want to give the Super User infrastructure role to the user who sets the API key or whose credentials are set with the ibmcloud oc credential set command. However, if this user doesn't have the Super User role, then infrastructure-related actions, such as creating a cluster or reloading a worker node, can fail. Instead of using IBM Cloud IAM platform roles to control users' infrastructure access, we must set specific IBM Cloud infrastructure permissions for users.

For example, if your account is not VRF-enabled, your IBM Cloud infrastructure account owner must turn on VLAN spanning. The account owner can also assign a user the Network > Manage Network VLAN Spanning permission so that the user can enable VLAN spanning. For more information, see VLAN spanning for cross-VLAN communication.


Assigning infrastructure access through the console

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see Granting user permissions for VPC resources.

Before beginning:

To customize classic infrastructure permissions through the console:

  1. Log in to the IBM Cloud console. From the menu bar, select Manage > Access (IAM).
  2. Click the Users page, and then click the name of the user that we want to set permissions for.
  3. Click the Classic infrastructure tab, and then click the Permissions tab.
  4. Customize the user's access. The permissions that users need depend on what infrastructure resources they need to use. You have two options for assigning access:
    • Use the Permission sets drop-down list to assign one of the following predefined roles. After selecting a role, click Set.
      • View Only gives the user permissions to view infrastructure details only.
      • Basic User gives the user some, but not all, infrastructure permissions.
      • Super User gives the user all infrastructure permissions.
    • Select individual permissions for each category. To review permissions that are needed to perform common tasks in Red Hat OpenShift on IBM Cloud, see User access permissions.
  5. Click Save.
  6. In the Device tab, select the devices to grant access to.
    • In the Select type group, you can grant access to all bare metal, dedicated, and virtual servers so that users can work with all flavors for worker nodes.
    • In the Enable future access group, you can grant the user access to all future bare metal, dedicated, and virtual servers.
    • In the table of devices, make sure that the appropriate devices are selected.
  7. To save your changes, click Set.
  8. Important: If we are assigning permissions so that a user can manage clusters and worker nodes, we must assign the user access for working with support cases.
    1. Click the Access policies tab, and then click Assign access.
    2. Click the Account management card.
    3. Select Support Center.
    4. To allow the user to view, add, and edit support cases, select Administrator.
    5. Click Assign.

Downgrading permissions? The action can take a few minutes to complete.


Assigning infrastructure access through the CLI

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see Granting user permissions for VPC resources.

Before beginning:

To customize classic infrastructure permissions through the CLI:

  1. Check whether the credentials for classic infrastructure access for Red Hat OpenShift on IBM Cloud in the region and resource group have any missing required or suggested permissions.

    ibmcloud oc infra-permissions get --region <region>

    Example output if classic infrastructure access is based on an API key.

    ...with infrastructure access set up by linked account API key.

    Example output if classic infrastructure access is based on manually-set credentials.

    ...with infrastructure access set up by manually-set IaaS credentials.

  2. Get the user whose classic infrastructure credentials are used.

    • API key: Check the API key that is used for the region and resource group of the cluster. Note the Name and Email of the API key owner in the output of the following command. 
      ibmcloud oc api-key info --cluster <cluster_name_or_ID>
    • Manually-set credentials: Get the username in the output of the following command. 
       ibmcloud oc credential get --region <region>

    Need to change the infrastructure credential owner? Check out the ibmcloud oc api-key reset command or the ibmcloud oc credential set command.

  3. List the users in your classic infrastructure account and note the id of the user whose credentials are set manually or by the API key.

    ibmcloud sl user list
  4. List the current classic infrastructure permissions that the user has. Note the KeyName of the permission that we want to change. 
    ibmcloud sl user permissions <user_id>

  5. Edit the permission of the user. For the --enable flag, enter true to assign the permission or false to remove the permission.

    ibmcloud sl user permission-edit <user_id> --permission <permission_keyname> --enable (true|false)

    To assign or remove user access to all permissions:

    ibmcloud sl user permission-edit <user_id> --permission ALL --enable (true|false)

  6. For individual required or suggested permissions, see the Infrastructure roles table.



Removing user permissions

If a user no longer needs specific access permissions, or if the user is leaving your organization, the IBM Cloud account owner can remove that user's permissions.


Checking if the user's credentials are used for infrastructure permissions

Before you remove a user's specific access permissions or remove a user from your account completely, ensure that the user's infrastructure credentials are not used to set the API key or for the ibmcloud oc credential set command. Otherwise, the other users in the account might lose access to the IBM Cloud infrastructure portal and infrastructure-related commands might fail.

To avoid this issue for future users, consider using a functional ID user for the API key owner instead of a personal user. In case the person leaves the team, the functional ID user remains the API key owner.

  1. Target your CLI context to a region and resource group where we have clusters.

     ibmcloud target -g <resource_group_name> -r <region>

  2. Check the owner of the API key or infrastructure credentials set for that region and resource group.

  3. API key: If the user's username is returned, use another user's credentials to set the API key.

    1. Invite a functional ID user to your IBM Cloud account to use to set the API key infrastructure credentials, instead of a personal user. In case a person leaves the team, the functional ID user remains the API key owner.
    2. Ensure that the functional ID user who sets the API key has the correct permissions.
    3. Log in as the functional ID. 
      ibmcloud login
    4. Change the infrastructure credentials to the functional ID user. 
      ibmcloud oc api-key reset --region <region>
    5. Refresh the clusters in the region to pick up on the new API key configuration. 
      ibmcloud oc cluster master refresh -c <cluster_name_or_ID>
  4. Infrastructure account: If the user's username is returned as the owner of the infrastructure account, migrate the existing clusters to a different infrastructure account before removing the user. For each cluster that the user created, follow these steps:
    1. Check which infrastructure account the user used to provision the cluster.
      1. In the Worker Nodes tab, select a worker node and note its ID.
      2. Open the menu and click Classic Infrastructure.
      3. From the infrastructure navigation pane, click Devices > Device List.
      4. Search for the worker node ID that you previously noted.
      5. If you do not find the worker node ID, the worker node is not provisioned into this infrastructure account. Switch to a different infrastructure account and try again.
    2. Determine what happens to the infrastructure account that the user used to provision the clusters after the user leaves.
      • If the user does not own the infrastructure account, then other users have access to this infrastructure account and it persists after the user leaves. You can continue to work with these clusters in your account. Make sure that at least one other user has the Administrator platform role for the clusters.
      • If the user owns the infrastructure account, then the infrastructure account is deleted when the user leaves. You cannot continue to work with these clusters. To prevent the cluster from becoming orphaned, the user must delete the clusters before the user leaves. If the user has left but the clusters were not deleted, we must use the ibmcloud oc credential set command to change your infrastructure credentials to the account that the cluster worker nodes are provisioned in, and delete the cluster. For more information, see Unable to modify or delete infrastructure in an orphaned cluster.
  5. Repeat these steps for each combination of resource groups and regions where we have clusters.


Removing a user from your account

If a user in your account is leaving your organization, we must remove permissions for that user carefully to ensure that you do not orphan clusters or other resources. After you remove permissions, you can remove the user from your IBM Cloud account.

  1. Check that the user's infrastructure credentials are not used for any Red Hat OpenShift on IBM Cloud resources.
  2. If we have other service instances in your IBM Cloud account that the user might have provisioned, check the documentation for those services for any steps that we must complete before you remove the user from the account.
  3. Remove the user from the IBM Cloud account. When you remove a user, the user's assigned IBM Cloud IAM platform roles, Cloud Foundry roles, and IBM Cloud infrastructure roles are automatically removed.
  4. When IBM Cloud IAM platform permissions are removed, the user's permissions are also automatically removed from the associated predefined RBAC roles. However, if you created custom RBAC roles or cluster roles, remove the user from those RBAC role bindings or cluster role bindings.

    The IBM Cloud IAM permission removal process is asynchronous and can take some time to complete.

  5. Optional: If the user had admin access to your cluster, you can rotate your cluster's Certificate Authority (CA) certificates.


Removing specific permissions

If we want to remove specific permissions for a user, you can remove individual access policies that have been assigned to the user.

Before beginning, check that the user's infrastructure credentials are not used for any Red Hat OpenShift on IBM Cloud resources. After checking, you can remove:


Remove IBM Cloud IAM platform permissions and the associated pre-defined RBAC permissions

  1. Log in to the IBM Cloud console. From the menu bar, select Manage > Access (IAM).
  2. Click the Users page, and then click the name of the user that we want to remove permissions from.
  3. In the table entry for the user, click the Actions menu > Remove user.
  4. When IBM Cloud IAM platform permissions are removed, the user's permissions are also automatically removed from the associated predefined RBAC roles. To update the RBAC roles with the changes, run ibmcloud oc cluster config. However, if you created custom RBAC roles or cluster roles, we must remove the user from the .yaml files for those RBAC role bindings or cluster role bindings. See steps to remove custom RBAC permissions in the next section.


Remove custom RBAC permissions

If you do not need custom RBAC permissions anymore, you can remove them.

  1. Open the .yaml file for the role binding or cluster role binding that you created.
  2. In the subjects section, remove the section for the user.
  3. Save the file.
  4. Apply the changes in the role binding or cluster role binding resource in your cluster. 
     oc apply -f my_role_binding.yaml


Remove Cloud Foundry permissions

To remove all of a user's Cloud Foundry permissions, you can remove the user's organization roles. If we want to remove only a user's ability, for example, to bind services in a cluster, then remove only the user's space roles.

  1. Log in to the IBM Cloud console. From the menu bar, select Manage > Access (IAM).
  2. Click the Users page, and then click the name of the user that we want to remove permissions from.
  3. Click the Cloud Foundry access tab.
    • To remove the user's space role:
      1. Expand the table entry for the organization that the space is in.
      2. In the table entry for the space role, click the actions menu and select Edit space role.
      3. Delete a role by clicking the close button.
      4. To remove all space roles, select No space role in the drop-down list.
      5. Click Save role.
    • To remove the user's organization role:
      1. In the table entry for the organization role, click the actions menu and select Edit organization role.
      2. Delete a role by clicking the close button.
      3. To remove all organization roles, select No organization role in the drop-down list.
      4. Click Save role.


Remove classic infrastructure permissions

You can remove IBM Cloud infrastructure permissions for a user by using the IBM Cloud console.

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see Granting user permissions for VPC resources.

  1. Log in to the IBM Cloud console. From the menu bar, select Manage > Access (IAM).
  2. Click the Users page, and then click the name of the user that we want to remove permissions from.
  3. Click the Classic infrastructure tab, then click the Permissions, Devices, or VPN subnets tabs.
  4. In each tab, deselect specific permissions.
  5. To save your changes, click Set and Save. Permissions are downgraded after a few minutes.