IAM roles and actions
Red Hat OpenShift on IBM Cloud is configured to use IBM Cloud® Identity and Access Management roles to determine the actions that users can perform on Red Hat OpenShift on IBM Cloud clusters, worker nodes, and Ingress application load balancers (ALBs).
Review the following table for a list of Platform and Service roles and their associated actions.
Kubernetes Service
Review the available platform and service roles and the actions mapped to each to help you assign access. If you're using the CLI or API to assign access, use containers-kubernetes
for the service name.
Role | Description |
---|---|
Administrator | As an administrator, you can perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users. |
Editor | As an editor, you can perform all platform actions except for managing the account and assigning access policies. |
Operator | As an operator, you can perform platform actions required to configure and operate service instances, such as viewing a service's dashboard. |
Viewer | As a viewer, you can view service instances, but you can't modify them. |
Role | Description |
---|---|
Compliance Management | Allows Security and Compliance Center to access your cluster to setup, run, and fetch compliance results. |
Manager | As a manager, you have permissions beyond the writer role to complete privileged actions as defined by the service. In addition, you can create and edit service-specific resources. |
Reader | As a reader, you can perform read-only actions within a service such as viewing service-specific resources. |
Writer | As a writer, you have permissions beyond the reader role, including creating and editing service-specific resources. |
Action | Description | Roles |
---|---|---|
containers-kubernetes.cluster.create |
Users such as cluster or account administrators can create and delete clusters or set up cluster-wide features like service endpoints or managed add-ons. | Administrator, Compliance Management |
containers-kubernetes.cluster.read |
Users such as auditors or billing can see cluster details but not modify the infrastructure. | Administrator, Editor, Operator, Viewer |
containers-kubernetes.cluster.operate |
Users such as reliability or DevOps engineers can add worker nodes and troubleshoot infrastructure such as reloading a worker node. They cannot create, delete, change credentials, or set up cluster-wide features. | Administrator, Operator |
containers-kubernetes.cluster.update |
Users such as developers can bind service, work with Ingress resources, and set up log forwarding for their apps but cannot modify the infrastructure. | Administrator, Editor |
containers-kubernetes.kube.read |
Users get read access to most Kubernetes resources in the namespace, but not to certain resources like roles, role bindings, or secrets. Corresponds to the RBAC view cluster role, which can be scoped to a namespace. | Reader |
containers-kubernetes.kube.write |
Users get read and write access to most Kubernetes resources in the namespace, but not to certain resources like roles or role bindings. Corresponds to the RBAC edit cluster role, which can be scoped to a namespace. | Writer |
containers-kubernetes.kube.manage |
When scoped to one namespace: Users can read and write to all Kubernetes resources in the namespace, but not to objects that apply across namespaces, the namespace resource quota, or the namespace itself. Corresponds to the RBAC admin cluster role to that namespace. When scoped to all namespaces in the cluster (by leaving the previous namespace field empty): Users can read and write to all Kubernetes resources in all namespaces in the cluster and work with objects that apply across namespaces, like top pods, top nodes, or creating an Ingress resource to make apps publicly available. Corresponds to the RBAC cluster-admin cluster role. | Manager |
For a list of all IBM services and their associated roles and actions, see IAM roles and actions
- Platform access roles
- With platform access roles, users can manage resources like clusters, worker pools, worker nodes, and add-ons. Example actions that are permitted by platform access 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 can't scope a platform access role by namespace within a cluster. Platform access roles don't grant access to the Kubernetes API to manage resources within the cluster, like Kubernetes pods, namespaces, or services.
- Service access roles
- Use service access roles to grant users access to manage Kubernetes resources within Red Hat OpenShift on IBM Cloud clusters. Service access roles are synchronized with corresponding Kubernetes RBAC policies in a cluster. As such, service access roles grant access to the Kubernetes API, dashboard, and CLI (
oc
). Example actions that are permitted by service access roles include creating app deployments, adding namespaces, or setting up configmaps. You can scope the policy for service access roles by resource group, region, or cluster instance. Further, you can also scope service access roles to Kubernetes namespaces that are in all clusters, individual clusters, or clusters in a specific region.
Permissions to create a cluster
Review the following permissions that you need to create a cluster including the required permissions for other integrations and services that you might use.
Service or resource group | Role | Scope | Required? |
---|---|---|---|
Kubernetes Service |
|
The resource group where you want to create a cluster. | Yes |
Container Registry | Administrator platform access role. | An individual instance or all instances. Do not limit policies for IBM Cloud Container Registry to the resource group level. | Yes |
IBM Cloud Object Storage | Administrator platform access role | An individual instance or all instances. | Yes |
Secrets Manager |
Administrator or Editor platform access role
|
All resource groups | Required if you plan to use Secrets Manager for encryption. |
Resource group permissions |
|
The resource group where you want to create a cluster. | Yes |
IAM Identity Service |
|
The resource group where you want to create a cluster. | Yes |
Key Protect | Administrator platform access role. | All instances or the specific instance you want to use. | Required if you plan to use Key Protect for encryption. |
Hyper Protect Crypto Services | Administrator platform access role. | All instances or the specific instance you want to use. | Required if you plan to use Hyper Protect Crypto Services for encryption. |
Classic infrastructure | Super User role | N/A | Yes |
VPC infrastructure | Administrator platform access role for VPC Infrastructure. | All instances or the specific instance you want to use. | Yes |
Consider saving the permissions outlined in the previous table as a custom IAM role. This way, you can assign users to the custom role instead of assigning each individual service. For more information, see the following example custom roles or the IAM documentation for Creating custom roles.
Example custom IAM roles
The following table provides some example use cases and the corresponding IAM roles for those cases. You can use these examples or create your own custom roles. For more information, see Creating custom roles.
Example custom role | Permissions |
---|---|
App auditor |
|
App developers |
|
Billing | Viewer platform access role for a cluster, region, or resource group. |
Cluster administrator |
|
DevOps operator |
|
Operator or site reliability engineer |
|