vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To check a user's permissions, review the access policies and access groups of the user in the [IBM Cloud console](https://cloud.ibm.com/iam/users), or use the ibmcloud iam user-policies <user> command.

If the API key is based on one user, how are other cluster users in the region and resource group affected?

Other users within the region and resource group of the account share the API key for accessing the infrastructure and other services with Red Hat OpenShift on IBM Cloud clusters. When users log in to the IBM Cloud account, an IBM Cloud IAM token that is based on the API key is generated for the CLI session and enables infrastructure-related commands to be run in a cluster.

To see the IBM Cloud IAM token for a CLI session, you can run ibmcloud iam oauth-tokens.





 How do I limit which commands a user can run? 

After you set up access to the portfolio for users in your account, you can then control which infrastructure actions the users can perform by assigning the appropriate [platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms). By assigning IBM Cloud IAM roles to users, they are limited in which commands they can run against a cluster. For example, because the API key owner has all the required infrastructure roles, all infrastructure-related commands can be run in a cluster. But, depending on the IBM Cloud IAM role that is assigned to a user, the user can run only some of those infrastructure-related commands.

For example, if you want to create a cluster in a new region, make sure that the first cluster is created by a user with the Super User infrastructure role, such as the account owner. After verification, you can invite individual users or users in IBM Cloud IAM access groups to that region by setting platform access policies for them in that region. A user with a Viewer platform access role isn't authorized to add a worker node. Therefore, the worker-add action fails, even though the API key has the correct infrastructure permissions. If you change the user's platform access role to Operator, the user is authorized to add a worker node.
IAM Identity service [Login events](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-at_events_iamat_events_iam_login) _platform:==iam-identity (action login) 
 IAM Identity service [API key events](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-at_events_iamat_events_iam_apikeys) _platform:==iam-identity (action user-apikey) -(action login) 
 IAM Identity service [Account service ID events](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-at_events_iamat_events_iam_serviceids) _platform:==iam-identity (action account-serviceid) 
 Resource controller [Provisioning and managing service instances](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-at_events_rcrc_provision) _platform:==BSS (action instance) 
 Resource controller [Managing users in the account](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-at_events_acc_mgtat_events_acc_mgt_users) _platform:==BSS (action user-management.user) 







 Query for events that have a specific action 

Each event has an action field that informs about the action that triggered the event. You can enter the following query to search for all events that have the same action:

action ACTIONVALUE

Where ACTIONVALUE is the value of the action field or part of the value.

The following table show examples of queries for different actions:



Table 4. Samples of queries by action type

 Action Sample query 

 Provision a service action instance.create 
 Remove an instance action instance.delete 
 Add a user action user-management.user.create 







 Query for events with a specific reason code 

You can enter the following query to search for events with a specific reason code:

reason.reasonCode:VALUE
Managing access for App ID 

With IBM Cloud® App ID and IBM Cloud Identity and Access Management (IAM), account owners can manage user access in your account.

As an account owner, you can set policies within your account to create different levels of access for different users. For example, certain users can have Read only access to one instance, but Write access to another. You can decide who is allowed to create, update, and delete instances of App ID.

For more information about IAM, see [IAM Access](https://cloud.ibm.com/docs/account?topic=account-userroles).



 User roles 

The scope of an access policy is based on a user's assigned role.

Policies enable access to be granted at different levels. Some options include:



* Access across all instances of the service in your account
* Access to an individual service instances in your account
* Access to a specific resource within an instance
* Access to all IAM-enabled services in your account





 Platform roles 

Platform management roles enable users to perform tasks on service resources at the platform level. For example, roles can be assigned to determine who can create or delete IDs, create instances, and bind instances to apps. The following table details the actions as they correlate to platform management roles.



Table 1. Platform roles, permissions, and the example actions that each role can take

 Platform role Permissions Example actions 

 Viewer View App ID instances. You can see that instances of the service exist, but not the information that is contained within them. 
 Editor View and bind App ID instances. You can bind applications to an instance of App ID. 
 Operator Create, delete, edit, suspend, resume, view, or bind App ID instances. You can create or delete an App ID instance. 
 Administrator All management actions for all services in the account. You can perform all operator actions and the ability to assign policies to other users. 







 Service access roles 

The following table details actions that are mapped to service access roles. Service access roles enable users to access App ID and to call the App ID API.



Table 2. Service roles and the actions that the role can take
name: IAMuser@email.com
- apiGroup: rbac.authorization.k8s.io
kind: group
name: team1







 Checking infrastructure roles 

Check your IBM Cloud classic infrastructure roles. For more information, see [Understanding access to the infrastructure portfolio](https://cloud.ibm.com/docs/openshift?topic=openshift-access-credsunderstand_infra).

VPC infrastructure permissions are managed with [IAM platform and service access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-iam).

If you are an administrator for the region and resource group, you might want to [check if the user's credentials are used for infrastructure permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersremoving_check_infra), especially before removing the user.



 Checking infrastructure roles from the UI 



1. Log in to the [IBM Cloud IAM console](https://cloud.ibm.com/iam).
2. From the navigation menu, click the Users tab.
3. In the table, click the user with the tag self for yourself or the user that you want to check.
4. Click the Classic infrastructure tab.
5. Review each of the classic infrastructure tabs.



1. Permissions: Expand the categories to review the permissions that the user has.
2. Devices: Review the devices that the user has permissions to. A common issue is when a user has administrator permissions but the Enable future access was Not checked so whenever a new device is ordered, the user can't administer the device.
3. VPN subnets: The subnets permission is important if the user must administer the subnets for the cluster.



6. To review what the roles and allowed actions permit, see the following topics.



* [Account classic infrastructure permissions](https://cloud.ibm.com/docs/account?topic=account-mngclassicinfra)
See [Granting IAM policies to a user to launch the web UI](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-launchlaunch_iam).







 Step 1: Launch the IBM Log Analysis web UI 



1. Log in to your IBM Cloud account.

Click [Log in to IBM Cloud](https://cloud.ibm.com/login) to sign in to the IBM Cloud.

After you log in with your user ID and password, the IBM Cloud console opens.
2. Select your account.
3. Click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/icons/icon_hamburger.svg) > Observability.
4. Click Logging.
5. For your instance, click Open dashboard. The logging web UI will be displayed.







 Step 2: Create a custom view 

In IBM Log Analysis, you can configure custom views to monitor a subset of data. For example, you configure your cluster to forward specific logs to the logging instance and you can filter those logs for analysis.

This tutorial will show you how to create a view that shows only a specific log.



1. [Make sure you are logged in to the IBM Cloud and have accessed the IBM Log Analysis web UI](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-tutorial-use-logdnaLA-launch-ui).
2. Click the EVERYTHING view.

![EVERYTHING view](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/everything.png)
3. Click Apps and select the log you want to view.
4.
The following tables outline the actions that users can take when they are assigned a specific role for each account management service. Review the information to ensure that you are assigning the correct level of access to your users.



 All Account Management services 

To quickly give users a wide range of account management access, you can assign a policy on all account management services. When a user is assigned a role on All Account Management services, they can complete all of the actions that are associated with that role for each individual service.

Give users access to the group of All Account Management services so that they can work with the following services:



* IAM Access Groups
* IAM Identity service
* IAM Access Management



* Role management



* User Management
* Billing
* Catalog management
* Context-based restrictions
* Enterprise
* Global catalog
* IBM Cloud shell settings
* License and entitlement
* Partner Center
* Partner Center - Sell
* Projects
* Security and Compliance Center
* Software instance
* Support center





Table 1. Roles and example actions for a policy on all account management services

 Roles Actions 

 Viewer All viewer role actions for the account management services 
 Operator All operator role actions for the account management services 
 Editor All editor role actions for the account management services and the ability to create resource groups 
 Administrator All administrator role actions for the account management services and the ability to create resource groups 







 All IAM Account Management services 

Identity and Access Management (IAM) services make up a subset of all account management services. Give users access to the group of All IAM Account Management services so that they can work with the following services:



* IAM Access Groups
* IAM Identity service
* IAM Access Management



* Role Management



* User Management





Table 2. Roles and example actions for a policy on all IAM account management services

 Roles Actions 

 Viewer All viewer role actions for IAM services 
 Operator All operator role actions for IAM services 
 Editor All editor role actions for IAM services and the ability to create resource groups 
 Administrator All administrator role actions for IAM services and the ability to create resource groups 
 User API key creator Create API keys when the account setting to restrict API key creation is enabled
* UI
* CLI
* API
* Terraform







 Managing access to resources 

To manage access for users or service IDs by using IAM policies, you must be the account owner or have the correct access assigned. To assign user's access to resources you must be an administrator on all services in the account, or the assigned administrator for the particular service or service instance. To assign access to a service ID, you must be administrator on the identity service or the specific service ID.



 Assigning access to resources 

You can assign access to resources by using two types of policies:



* Access to resources in the account, including the option for just one type or all types
* Access to resources within a resource group, including the option for just one resource or all



If you delete or edit an existing policy for a service ID currently being used, it might cause service interruption.

If you want to enable a user full administrator access to complete [account management tasks](https://cloud.ibm.com/docs/account?topic=account-account-servicesaccount-management-access), such as inviting and removing users, viewing billing and usage, managing service IDs, managing access groups, managing user access, and access to all IAM-enabled resources, you must assign a user the following access:



* A policy for All Identity and Access enabled services with the Administrator and Manager roles.
* A policy with Administrator role on All Account Management services.



You can also set access management tags to manage access. For more information, see [Controlling access to resources by using tags](https://cloud.ibm.com/docs/account?topic=account-access-tags-tutorial).

Users with the Administrator role for account management services can change the access of other users for any account management service. They can also invite and remove users from the account, including other users with the administrator role.



 Assigning access to resources in the console 

To assign access to an individual resource in the account or access to all resources in the account, complete the following steps:



1. In the IBM Cloud console, click Manage > Access (IAM), and select Users or Service IDs, depending on which identity you want to assign access.
2.
Most likely, your account administrator has already provisioned the auditing instances and has not given you permisisons to see or work with them.

To see auditing instances, you must have IAM platform permissions for the IBM Cloud Activity Tracker service.

Therefore, if you cannot see any Auditing instances when you [launch the Activity Tracker observability dashboard](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-launch), check that you have permissions to at least view them. You need at least the viewer platform role to see the auditing instances. To learn more about IAM permissions, see [Managing access with IAM](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iam).
* How do I create an API key?

Complete the following steps:



1. Log in to IBM Cloud with the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).

ibmcloud login

If the login fails, run the ibmcloud login --sso command to try again. The --sso parameter is required when you log in with a federated ID. If this option is used, go to the link listed in the CLI output to generate a one-time passcode.
2. Create a [service ID](https://cloud.ibm.com/docs/iam?topic=iam-serviceids) for your application.

ibmcloud iam service-id-create <SERVICE_ID_NAME> [-d, --description DESCRIPTION]
3. [Assign an access policy](https://cloud.ibm.com/docs/iam?topic=iam-serviceidpolicy) for the service ID.

You can assign access permissions for your service ID [by using the IBM Cloud console](https://cloud.ibm.com/docs/iam?topic=iam-serviceidpolicyaccess_new).
Users with a service access role to IBM Cloud Kubernetes Service in IAM are given [corresponding user roles in RBAC](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-rolesrbac_ref). The RBAC user details include a unique issuer ID, subject identifier claim, and Kubernetes username. These details vary with the Kubernetes version of the cluster. When you update a cluster from a previous version, the details are automatically updated. RBAC usernames are prefixed by IAM. For more information about how OpenID authentication works, see the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/).

You might use this information if you build automation tooling within the cluster that relies on the user details to authenticate with the Kubernetes API server.



IBM Cloud IAM issuer details for RBAC users

 Version Issuer Claim Casing* 

 1.18 or later https://iam.cloud.ibm.com/identity realmed_sub_<account_ID> lowercase 
 1.17 https://iam.cloud.ibm.com/identity sub_<account_ID> lowercase 
 1.10 - 1.16 https://iam.bluemix.net/identity sub_<account_ID> lowercase 
 1.9 or earlier https://iam.ng.bluemix.net/kubernetes sub camel case 



: An example of lowercase is user.name@company.com. An example of camel case is User.Name@company.com.
Managing IAM access for IBM Cloud Juniper vSRX 

Access to IBM Cloud® Juniper vSRX service instances for users in your account is controlled by IBM Cloud® Identity and Access Management (IAM). Every user that accesses the vSRX service in your account must be assigned an access policy with an IAM role. Review the following roles, actions, and more to help determine the best way to assign access to vSRX.

The access policy that you assign users in your account determines what actions a user can perform within the context of the service or specific instance that you select. The allowable actions are customized and defined by the vSRX as operations that are allowed to be performed on the service. Each actions is mapped to an IAM platform or service role that you can assign to a user.

If a specific role and its actions don't fit the use case that you're looking to address, you can [create a custom role](https://cloud.ibm.com/docs/account?topic=account-custom-rolescustom-access-roles) and pick the actions to include.

IAM access policies enable access to be granted at different levels. Some of the options include the following:



* Access across all instances of the service in your account
* Access to an individual service instance in your account
* Access to a specific resource within an instance, such as resource type bucket



Review the following tables that outline what types of tasks each role allows for when you're working with the vSRX service.

When you assign policies to users for this service, use servicename for the service name in the CLI command or API call.

The following table describes the types of tasks that can be completed with each platform management role assigned. Platform management roles enable users to perform tasks on service resources at the platform level, for example, assign user access to the service, create or delete instances, and bind instances to applications.



Table 1. IAM platform roles
The rows are read from left to right. The first column is the platform management role. The second column is a description of the actions in the service that the platform management role permits.

 Platform role Description of actions 

 Viewer Description of what users can accomplish; think tasks. 
 Operator Description
Managing access for flow logs 

Access to IBM Cloud® Flow Logs service instances for users in your account is controlled by IBM Cloud® Identity and Access Management. Every user that accesses the Flow Logs service in your account must be assigned an access policy with an IAM role defined. The policy determines the actions that a user can take within the context of the service or instance that you select. The allowable actions are customized and defined by the IBM Cloud service as operations that are allowed to be run on the service. The actions are then mapped to IAM user roles.

Policies enable access to be granted at different levels. The following are some of the included options:



* Access across all instances of the service in your account
* Access to an individual service instance in your account



After you define the scope of the access policy, you assign a role, which determines the user's level of access. Review the following tables that outline the actions that each role allows within the Flow Logs service.

The following table details actions that are mapped to platform management roles. Platform management roles enable users to complete tasks on service resources at the platform level, for example, assign user access for the service and create or delete instances.

For more information about IAM roles, see [Getting Started with IAM](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).



Table 1. IAM user roles and actions

 Platform management role Description of actions 

 Administrator Read, operate, update, create, delete, and list flow log collectors 
 Editor Read, operate, update, create, delete, and list flow log collectors 
 Operator Operate and list flow log collectors 
 Viewer Read flow log collectors 



For more information about assigning user roles in the console, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources).

Only one operator role is needed, as determined by the scope of your flow log collector.

In addition, you also require the following actions and operations that are not specific to IBM Cloud Flow Logs.



Table 2. Additional IAM user roles and actions

 Role Description of actions
You can check your [IBM Cloud resource list](https://cloud.ibm.com/resources) to find your service instance names.
* <your_service_key_name>: any name that you want to use for the key. This name is used to retrieve service keys.
* <role>: the role you assigned to the IAM API key which was generated for the service credentials. You will be able to perform only those operations that are permitted for the chosen role. For more details on the roles required to perform an operation, refer to section Required IAM permissions in [Granting permissions to users](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-grant-permissions).



Expected response:

Creating service key of service instance <service_instance_name> under account <your account name> as <your user name>...
OK
Service key <service key crn> was created.
Name: service-key-name
ID: crn:v1:staging:public:ibmanalyticsengine:us-south:a/d628eae2cxxxxx229f2xxxx:1671b660-xxxx-448f-xxx-e1633a2b97c7:resource-key:4f1b043c-xxxx-xxxx-xxxx-cbf90f6155d0
Created At: Mon Nov 29 11:47:32 UTC 2021
State: active
Credentials:
apikey: xxxxxx
endpoints:
applications_api: https://api-staging.us-south.ae.cloud.ibm.com/v3/analytics_engines/xxxx660-7f2x-4xxf-9xx4-exxxxxxxxxc7/spark_applications
instance_api: https://api-staging.us-south.ae.cloud.ibm.com/v3/analytics_engines/xxxx660-7f2x-4xxf-9xx4-exxxxxxxxxc7
To get this ID from the command line, run ibmcloud account show.

curl -L -X POST 'https://iam.cloud.ibm.com/v1/profiles' -H 'Accept: application/json' -H 'Authorization: Bearer <access_token>' -H 'Content-Type: application/json' --data-raw '{
"name": "<profile_name>",
"description": "<description>",
"account_id": "<account_id>"
}'



2. Link the IAM trusted profile to a Kubernetes namespace in your Red Hat OpenShift on IBM Cloud cluster.



1. Get your <profile-id> from the output of the first step. Or, you can run the following API command.

curl -L -X GET 'https://iam.cloud.ibm.com/v1/profiles/?account_id=<account_id>' -H 'Accept: application/json' -H 'Authorization: <access_token>' -H 'Content-Type: application/json'
2. Get your cluster name and CRN by running the following API command.

curl --location --request GET 'https://containers.cloud.ibm.com/global/v1/clusters' --header 'Authorization: <access_token>'
3. Link the IAM trusted profile to your cluster.



* For <link_name>, enter a name for the link between the trusted profile and the cluster.
* Replace <profile-id>, <access_token>, <cluster_crn>, and <cluster_name> with the values that you previously retrieved.
* For <ns>, enter the namespace in your cluster. You can list namespaces by logging in to the cluster and running oc get ns. The Kubernetes namespace that you enter does not have to exist already. Any future namespace with this name can establish trust.