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.

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.

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.

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. For more information about setting up your account and resources, see best practices for organizing users, teams, and applications.

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. For more information, see Classic infrastructure roles.	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 earlier 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.

Classic infrastructure roles

A user with the Super User infrastructure access role sets the API key for a region and resource group so that infrastructure actions can be performed.

The infrastructure actions that other users in the account can perform are authorized through IBM Cloud IAM platform access roles.

Use the following table to customize classic infrastructure permissions only when you can't assign Super User to the user who sets the API key. For instructions to assign permissions, see Customizing infrastructure permissions.

Required classic infrastructure permissions

Table 1: Required classic infrastructure permissions
Permission	Description
IPMI Remote Management	Manage worker nodes.
Add Server	Add worker nodes. Note: For worker nodes that have public IP addresses, you also need the Add Compute with Public Network Port permission in the Network category.
Cancel Server	Delete worker nodes.
OS Reloads and Rescue Kernel	Update, reboot, and reload worker nodes.
View Virtual Server Details	Required if the cluster has VM worker nodes. List and get details of VM worker nodes.
View Hardware Details	Required if the cluster has bare metal worker nodes. List and get details of bare metal worker nodes.
Add Support Case	As part of the cluster creation automation, support cases are opened to provision the cluster infrastructure.
Edit Support Case	As part of the cluster creation automation, support cases are updated to provision the cluster infrastructure.
View Support Case	As part of the cluster creation automation, support cases are used to provision the cluster infrastructure.

Suggested classic infrastructure permissions

Table 2: Suggested classic infrastructure permissions
Permission	Description
Access All Virtual	Access all worker nodes.
Access All Hardware	Designate access to all bare metal worker nodes. Without this permission, a user who creates one cluster might not be able to view the bare metal worker nodes of another cluster even if the user has IAM access to both clusters.
Add Compute with Public Network Port	Let worker nodes have a port that can be accessible on the public network.
Manage DNS	Set up public load balancer or Ingress networking to expose apps.
Edit Hostname/Domain	Set up public load balancer or Ingress networking to expose apps.
Add IP Addresses	Add IP addresses to public or private subnets that are used for cluster load balancing.
Manage Network Subnet Routes	Manage public and private VLANs and subnets that are used for cluster load balancing.
Manage Port Control	Manage ports that are used for app load balancing.
Manage Certificates (SSL)	Set up certificates that are used for cluster load balancing.
View Certificates (SSL)	Set up certificates that are used for cluster load balancing.
Add/Upgrade Storage (Storage Layer)	Create IBM Cloud File or Block storage instances to attach as volumes to your apps for persistent storage of data.
Storage Manage	Manage IBM Cloud File or Block storage instances that are attached as volumes to your apps for persistent storage of data.