IAM roles and actions

IBM Cloud Kubernetes Service is configured to use IBM Cloud® Identity and Access Management roles to determine the actions that users can perform on IBM Cloud Kubernetes Service 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.

Table 26. Platform roles - Kubernetes Service
Use the tab buttons to change the context of the table. This table has row and column headers. The row headers provide the platform role name and the column headers identify the specific information available about each role.
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.

Table 26. Service roles - Kubernetes Service
Use the tab buttons to change the context of the table. This table has row and column headers. The row headers provide the service role name and the column headers identify the specific information available about each role.
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.

Table 26. Service actions - Kubernetes Service
Use the tab buttons to change the context of the table. This table provides the available actions for the service, descriptions of each, and the roles that each action are mapped to.
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 IBM Cloud Kubernetes Service 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 (kubectl). 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.

IAM roles needed to create a cluster.
Service or resource group	Role	Scope	Required?
Kubernetes Service	Administrator platform access role Writer or Manager service access role	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
Secrets Manager	Administrator or Editor platform access role Manager service access role	All resource groups	Required if you plan to use Secrets Manager for encryption.
Resource group permissions	Viewer platform access role	The resource group where you want to create a cluster.	Yes
IAM Identity Service	Service ID creator User API key creator role Viewer platform access role	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.

Types of roles you might assign to meet different use cases.
Example custom role	Permissions
App auditor	Viewer platform access role for a cluster, region, or resource group. Reader service access role for a cluster, region, or resource group.
App developers	Editor platform access role for a cluster. Writer service access role scoped to a namespace.
Billing	Viewer platform access role for a cluster, region, or resource group.
Cluster administrator	Administrator platform access role for a cluster. Manager service access role for the whole cluster (not scoped to a namespace).
DevOps operator	Operator platform access role for a cluster. Writer service access role for the whole cluster (not scoped to a namespace).
Operator or site reliability engineer	Administrator platform access role for a cluster, region, or resource group. Reader service access role for a cluster or region. Manager service access role for all cluster namespaces to be able to use `kubectl top nodes,pods` commands.