Understanding access control for clusters

Learn how you can set up access control for your Red Hat® OpenShift® on IBM Cloud® clusters by using various types of access control, roles, and policies.

Access control checklist

Use the following checklist to configure user access to your Red Hat OpenShift on IBM Cloud cluster.

IBM Cloud access control

Your clusters use IBM Cloud Identity and Access Management (IAM) as the identity provider to control access to the cluster.

Understand how roles, users, and resources in your account can be managed.
Invite users to your account and assign them IBM Cloud IAM roles for the service.

Do not assign IBM Cloud IAM platform access roles at the same time as a service access role. You must assign platform and service access roles separately.
If you use Kubernetes namespaces to isolate resources within the cluster, grant access to namespaces by assigning users IBM Cloud IAM service access roles for the namespaces.
For any automation tooling such as in your CI/CD pipeline, set up service accounts and assign the service accounts Kubernetes RBAC permissions.

For more information about setting up your account and resources, see best practices for organizing users, teams, and applications.

Overview of 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, such as Kubernetes pods, namespaces, or services. Example actions that are permitted by RBAC roles are creating objects such as pods or reading pod logs.

You can assign RBAC roles through the following methods.

By using IBM Cloud IAM: You can use IAM to automatically create and manage RBAC in your cluster, by assigning IAM service access roles to users. Every user who is assigned a service access 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. Change that you make to the user in IAM, such as updating or removing the service access policy, are automatically synchronized to the RBAC in your cluster. The synchronization of service roles to RBAC might take a couple minutes, depending on the number of users and namespaces in your cluster.
Managing your own RBAC: See Assigning RBAC permissions.

Assign access roles to individual or groups of users in IBM Cloud IAM

When you set IBM Cloud IAM policies, you can assign roles to an individual user or to a group of users.

Individual users: You might have a specific user that needs more or less permissions than the rest of your team. You can customize permissions on an individual basis so that each person has the permissions that they need to complete their tasks. You can assign more than one IBM Cloud IAM role to each user.
Multiple users in an access group: You can create a group of users and then assign permissions to that group. For example, you can group all team leaders and assign administrator access to the group. Then, you can group all developers and assign only write access to that group. You can assign more than one IBM Cloud IAM role to each access group. When you assign permissions to a group, any user that is added or removed from that group is affected. If you add a user to the group, then they also have the additional access. If they are removed, their access is revoked.

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, namespaces, projects, or resource groups.

When you create your IBM Cloud account, the default resource group is created automatically. If you don't 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 you 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. 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.

Namespaces or projects

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 you 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 access role to a namespace, you can't apply the policy to a resource group or assign a platform access role at the same time.