vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Overview of IBM Cloud IAM platform access roles 

Use platform access roles in IBM Cloud Identity and Access Management (IAM) to grant users access to manage cluster resources in Red Hat OpenShift on IBM Cloud. 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.

What types of actions do platform access roles permit?
: 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.

For more information, see [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles).

Platform access roles don't grant access to the Kubernetes API to manage resources within the cluster, like Kubernetes pods, namespaces, or services. However, users can still perform the ibmcloud oc cluster config command to set the Kubernetes context to the cluster. Then, you can authorize the users to perform select Kubernetes actions by using [custom RBAC policies](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewrole-binding). You 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 access roles.

Although platform access roles authorize you to perform infrastructure actions on the cluster, they don't 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](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewapi_key).
(https://cloud.ibm.com/docs/containers?topic=containers-faqsfaq_thirdparty_oss)
* [What am I charged for? Can I estimate and control costs in my cluster?](https://cloud.ibm.com/docs/containers?topic=containers-faqscharges)
* [Can I downgrade my cluster to a previous version?](https://cloud.ibm.com/docs/containers?topic=containers-faqsdowngrade)







 Troubleshooting 

[Getting help and support for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-get-helpget-help)



* [General ways to resolve cluster issues](https://cloud.ibm.com/docs/containers?topic=containers-get-helphelp-general)
* [Reviewing issues and status](https://cloud.ibm.com/docs/containers?topic=containers-get-helphelp-cloud-status)
* [Feedback and questions](https://cloud.ibm.com/docs/containers?topic=containers-get-helpfeedback-qs)
* [Contacting support](https://cloud.ibm.com/docs/containers?topic=containers-get-helphelp-support)
* [Requesting access to allowlisted features](https://cloud.ibm.com/docs/containers?topic=containers-get-helpallowlist-access-request)



[Running tests with the Diagnostics and Debug Tool](https://cloud.ibm.com/docs/containers?topic=containers-debug-tooldebug-tool)



* [Enabling the Diagnostics and Debug Tool add-on](https://cloud.ibm.com/docs/containers?topic=containers-debug-tooldebug-tool-enable)





 Clusters and masters 

[Debugging clusters](https://cloud.ibm.com/docs/containers?topic=containers-debug_clustersdebug_clusters)
See [Configuring your Kafka API client](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-kafka_usingkafka_api_client) how to configure SASL OAUTHBEARER in Kafka clients.

Enterprise users have the option to disable SASL PLAIN in their Enterprise instances. Use command:

ibmcloud resource service-instance-update <instance-name> -p '{"iam_token_only":true}'





 Managing authorization to your Event Streams resources 

You can secure your Event Streams resources in a fine-grained manner to manage the access that you want to grant each user to each resource.

When you change IAM policies and permissions, they can sometimes take several minutes to be reflected in the underlying service.



 What can I secure? 

Within Event Streams, you have secure access to the following resources:



* Cluster (cluster): You can control which applications and users can connect to the service.
* Topics (topic): You can control the ability of users and applications to create, delete, read, and write to a topic.
* Consumer groups (group): You can control an application's ability to join a consumer group.
* Producer transactions (txnid): You can control the ability to use the transactional producer capability in Kafka (that is, single, atomic writes across multiple partitions).



The levels of access (also known as a role) that you can assign to a user to each resource are as follows.



Table 1. Example Event Streams user roles and actions

 Access role Description of actions Example actions 

 Reader Perform read-only actions within Event Streams such as viewing resources. Allow an app to connect to a cluster by assigning read access to cluster resource type. 
 Writer Writers have permissions beyond the reader role, including editing Event Streams resources. Allow an app to produce to topics by assigning write access to topic resource and topic name types. 
 Manager Managers have permissions beyond the writer role to complete privileged actions. In addition, you can create and edit Event Streams resources. Allow full access to all resources by assigning manage access to the Event Streams instance.
* [ibm_cd_toolchain_tool_hostedgit](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cd_toolchain_tool_hostedgit)







 What type of authentication should I use to access GitHub repos from my toolchain? 

Before you can use a repo integration, you must authorize it so that IBM Cloud can access your GitHub account by using one of the following authentication methods.



* IBM Cloud OAuth app: When you grant authorization by using the IBM Cloud OAuth App, you allow IBM Cloud to act as the authenticated user. You can also revoke permissions from the Oauth App.
* Personal Access Token: Use a Personal Access Token (PAT) to provide granular access to a specific user or repo. Authorizing with a PAT is recommended when you use Terraform or the API.
If you want users to be able to interact with Kubernetes resources from within a cluster, you must assign user access to one or more namespaces through [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users). Every user who is assigned a service access 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 access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-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](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-rolesrbac_ref).

All users of a Red Hat OpenShift cluster are added to the basic-users RBAC group.





 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 access role. To grant other Kubernetes permissions, you can [create custom RBAC permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersrbac). Custom RBAC roles are in addition to and don't change or override any RBAC roles that you might have assigned with service access roles. Note that to create custom RBAC permissions, you must have the IAM Manager service access role that gives you the cluster-admin Kubernetes RBAC role.
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 access role. To grant other Kubernetes permissions, you can [create custom RBAC permissions](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac). Custom RBAC roles are in addition to and don't change or override any RBAC roles that you might have assigned with service access roles. Note that to create custom RBAC permissions, you must have the IAM Manager service access role that gives you the cluster-admin Kubernetes RBAC role. However, the other users don't 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.





 When do I need to use custom cluster role bindings and role bindings? 

You might want to authorize who can create and update pods in your cluster. With [pod security policies (PSPs)](https://cloud.ibm.com/docs/containers?topic=containers-psp), you can use existing cluster role bindings that come with your cluster, or create your own.

You might also want to integrate add-ons to your cluster. For example, when you [set up Helm in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-helm)







 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 access role. Do you 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.
To grant other Kubernetes permissions, you can [create custom RBAC permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersrbac). Custom RBAC roles are in addition to and don't change or override any RBAC roles that you might have assigned with service access roles. Note that to create custom RBAC permissions, you must have the IAM Manager service access role that gives you the cluster-admin Kubernetes RBAC role. However, the other users don't 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](https://docs.openshift.com/container-platform/4.11/authentication/understanding-authentication.html) in your cluster, and then assign roles to the group.





 When do I need to use custom cluster role bindings and role bindings? 

You might want to authorize who can create and update pods in your cluster. With [security context constraints (SCCs)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs), you can use existing cluster role bindings that come with your cluster, or create your own.

You might also want to integrate add-ons to your cluster. For example, when you [set up Helm in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-helm)







 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 access role.
Managers Users in this group should have permissions to fully manage the service in the IBM Cloud. 
 Advanced service users Users in this group should have permissions to run advanced service tasks. 
 Users Users in this group should have permissions to run basic tasks. 







 Policies 

A policy determines the full set of actions that a user or service ID can perform.

For each access group, define a policy for each resource group that defines the level of access to that resource group.

By default, the account owner is the only user in the account that can grant permissions to other users to manage and work with the IBM Cloud Activity Tracker service.

To allow other users or service IDs in the account to manage the service and be able to grant permissions to work with the IBM Cloud Activity Tracker service, define a policy for the IBM Cloud Activity Tracker service with the platform role administrator. Grant this policy to the administrators access group.

Access to resources within a resource group can be granted to all resources in a group, or only selected services within a group.

Access policies set a target, which is typically a service instance or all instances of a service in a resource group, and a role, which defines what type of access is allowed.

Roles define the actions that a user or serviceID can run. There are different types of roles in the IBM Cloud:



* Platform management roles define permissions to work with the service at the platform level, for example, some actions are assign user access for the service, create or delete service IDs, create instances, assign policies for your service to other users, and bind instances to applications. [Learn more](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iamplatform).
* Service access roles define permissions for calling the service's API. [Learn more](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iamservice).



For each access group, define a policy for each resource group that specifies the permissions granted to work with the resource group, the permissions to manage instances of the IBM Cloud Activity Tracker service in that resource group, and the permissions to run IBM Cloud Activity Tracker tasks.



Table 3. Roles per access group policy
User access To create classic infrastructure clusters, you must set up [infrastructure credentials](https://cloud.ibm.com/docs/openshift?topic=openshift-access-creds) for each region and resource group. To let users manage the cluster, use [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles). To grant users access to cluster resources, use [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles), which correspond with Kubernetes RBAC roles. 
 Integrations You can extend your cluster and app capabilities with a variety of IBM Cloud services, add-ons, and third-party integrations. For a list, see [Supported IBM Cloud and third-party integrations](https://cloud.ibm.com/docs/openshift?topic=openshift-supported_integrations). 
 Locations and versions Classic clusters are available in multizone and single zone locations [worldwide](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneslocations). 
 Service interface Classic clusters are fully supported in the Kubernetes Service [v1 API](https://containers.cloud.ibm.com/global/swagger-global-api//), [CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli), and [console](https://cloud.ibm.com/kubernetes/clusters). 
 Service compliance See the classic section in [What standards does the service comply to?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsstandards). 
 Service limitations See [Service limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationstech_limits).
For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/authorization/).

If you choose a custom access option, some Satellite Config components might not work. For example, if you grant access to view only certain resources, you cannot use subscriptions to create Kubernetes resources in your cluster group. To view an inventory of your Kubernetes resources in a cluster, Satellite Config must have an appropriate role that is bound to the razee-viewer service account. To deploy Kubernetes resources to a cluster by using subscriptions, Satellite Config must have an appropriate role that is bound to the razee-editor service account.





 Cluster admin access 

Grant the Satellite Config service accounts access to the cluster admin role.

kubectl create clusterrolebinding razee-cluster-admin --clusterrole=razee-cluster-admin --serviceaccount=razeedeploy:razee-viewer --serviceaccount=razeedeploy:razee-editor --serviceaccount=razeedeploy:razee-satcon





 Custom access, cluster-wide 

Create custom RBAC policies to grant Satellite Config access to the actions and Kubernetes resources that you want for the cluster.



1. Create a cluster role with the actions and resources that you want to grant. For example, the following command creates a viewer role so that Satellite Config can list all the Kubernetes resources in a cluster, but cannot modify them.

kubectl create clusterrole razee-viewer --verb=get,list,watch --resource="."



Understanding this command's components

 Component Description 

 razee-viewer The name of the cluster role, such as razee-viewer. 
 --verb=get,list,watch A comma-separated list of actions that the role authorizes. In this example, the action verbs are for roles typical for a viewer or auditor, get,list,watch.
Ask your cluster admin to [enable a key management service provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkeyprotect) in your cluster to encrypt new and existing secrets.





 How can I make sure that my app has the correct resources? 

When you [specify your app YAML file](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsapp_yaml), you can add Kubernetes functionalities to your app configuration that help your app get the correct resources. In particular, [set resource limits and requests](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) for each container that is defined in your YAML file.

Additionally, your cluster admin might set up resource controls that can affect your app deployment, such as the following.



* [Resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
* [Pod priority](https://cloud.ibm.com/docs/openshift?topic=openshift-pod_priority)







 How can I add capabilities to my app configuration? 

See [Specifying your app requirements in your YAML file](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsapp_yaml) for descriptions of what you might include in a deployment. The example includes the following options.



* [Replica sets](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsreplicaset)
* [Labels](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appslabel)
* [Affinity](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsaffinity)
Advanced service users Users in this group should have permissions to run advanced service tasks. 
 Users Users in this group should have permissions to run basic tasks. 







 Policies 

A policy determines the full set of actions that a user or service ID can perform.

For each access group, define a policy for each resource group that defines the level of access to that resource group.

By default, the account owner is the only user in the account that can grant permissions to other users to manage and work with the IBM Log Analysis service.

To allow other users or service IDs in the account to manage the service and be able to grant permissions to work with the IBM Log Analysis service, define a policy for the IBM Log Analysis service with the platform role administrator. Grant this policy to the administrators access group.

For more information, see [Granting permissions to a user to become an administrator of the service](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-work_iamadmin_account).

Access to resources within a resource group can be granted to all resources in a group, or only selected services within a group.

Access policies set a target, which is typically a service instance or all instances of a service in a resource group, and a role, which defines what type of access is allowed.

Roles define the actions that a user or serviceID can run. There are different types of roles in the IBM Cloud:



* Platform management roles define permissions to work with the service at the platform level, for example, some actions are assign user access for the service, create or delete service IDs, create instances, assign policies for your service to other users, and bind instances to applications. [Learn more](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-work_iam).
* Service access roles define permissions for calling the service's API. [Learn more](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-work_iam).
For clusters that run Kubernetes 1.21 and later, the service account tokens that pods use to communicate with the Kubernetes API server are time-limited, automatically refreshed, scoped to a particular audience of users (the pod), and invalidated after the pod is deleted. To continue communicating with the API server, you must design your apps to read the refreshed token value on a regular basis, such as every minute. For more information, see [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md).





 Managing access and monitoring app health 

After you deploy your app, you can control who can access the app, and monitor the health and performance of the app.



 How can I control who has access to my app deployments? 

The account and cluster administrators can control access on many different levels: the cluster, Red Hat OpenShift project, pod, and container.

With IBM Cloud IAM, you can assign permissions to individual users, groups, or service accounts at the cluster-instance level. You can scope cluster access down further by restricting users to particular namespaces within the cluster. For more information, see [Assigning cluster access](https://cloud.ibm.com/docs/openshift?topic=openshift-usersusers).

To control access at the pod level, you can configure [security context constraints (SCCs)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs).

Within the app deployment YAML, you can set the security context for a pod or container. For more information, review the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).

Want to control access at the application level?