vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Select roles for the access policy.



* Platform access role: Grants access to Red Hat OpenShift on IBM Cloud so that users can manage infrastructure resources such as clusters, worker nodes, worker pools, Ingress application load balancers, and storage. To find a list of supported actions per role, see [platform access roles reference page](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles). Note that if you assign a user the Administrator platform access role for only one cluster, you must also assign the user the Viewer platform access role for all clusters in that region in the resource group.
* Service access role: Grants access to the Kubernetes API from within a cluster so that users can manage Kubernetes resources such as pods, deployments, services, and namespaces. To find a list of supported actions per role, see [service access roles reference page](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles). don't assign a platform access role at the same time as you assign a service access role. If you also want the user to have a platform access role, repeat these steps but leave the namespace field blank and assign only a platform access role (don't assign a service access role again).



8. Click Add.
9. If you assigned only service access roles to users, the users must perform a one-time ibmcloud oc cluster config[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_config) and be given the cluster master URL to open the Red Hat OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli_platform).



4.
If you assigned only service access roles to users, the users must perform a one-time ibmcloud oc cluster config[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_config) and be given the cluster master URL to open the Red Hat OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli_platform).



4. Assign the users Viewer access to the resource group so that they can work with clusters in resource groups other than default. Note that users must have access to the resource group to create clusters.



1. Click the IAM services tile.
2. In the services drop-down list, select No service access.
3. In the next drop-down list, scope the policy to All resource groups or to particular resource groups.
4. Select Viewer.
5. Click Add.



5. In the side panel, review the Access summary of your changes, and click Assign. If you assigned a service access role, the role might take a couple minutes to sync with your cluster's RBAC.







 Assign IBM Cloud IAM roles with the CLI 

Grant users access to your Red Hat OpenShift on IBM Cloud clusters by assigning IBM Cloud IAM platform access and service access roles with the CLI.

Before you begin, complete the following steps.



* Verify that you're assigned the cluster-admin IBM Cloud IAM platform access role for the IBM Cloud account in which you're working.
* Verify that the user is added to the account. If the user is not, invite the user to your account by running ibmcloud account user-invite <user@email.com>.
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
You can add the image pull secret to the service account for the project, or refer to the secret in each deployment. For instructions, see [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).

Image pull secrets are valid only for the Red Hat OpenShift projects that they were created for. Repeat these steps for every namespace where you want to deploy containers.

Before you begin:



1. [Set up a namespace in IBM Cloud Container Registry and push images to this namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_namespace_add).
2. [Create a Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters).
3. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



To use your own image pull secret, choose among the following options:



* [Copy the image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret) from the default Red Hat OpenShift project to other projects in your cluster.
* [Create new IAM API key credentials and store them in an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts) to access images in other IBM Cloud accounts or to apply IAM policies that restrict access to certain registry domains or namespaces.
* [Create an image pull secret to access images in external private registries](https://cloud.ibm.com/docs/openshift?topic=openshift-registryprivate_images).
* Verify that you're assigned the cluster-admin IBM Cloud IAM platform access role for the IBM Cloud account in which you're working.
* Verify that the user is added to the account. If the user is not, invite the user to your account by running ibmcloud account user-invite <user@email.com>.
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* Decide whether to assign [platform or service access](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewaccess_policies) roles. The CLI steps vary depending on which access role you want to assign:



* [Assign platform access roles from the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli_platform)
* [Assign service access roles from the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli_service)







 Assigning IBM Cloud IAM platform roles from the CLI 

Create an IBM Cloud IAM access policy to set permissions for Red Hat OpenShift on IBM Cloud (--service-name containers-kubernetes). Scope the access policy based on what you want to assign access to with the following options.

User
: CLI option: N/A
: You can assign the policy to an individual or group of users. Place this positional option immediately following the command.



* Individual user: Enter the email address of the user.
* Access group: Enter the name of the access group of users. You can create an access group with the ibmcloud iam access-group-create command. To list available access groups, run ibmcloud iam access-groups. To add a user to an access group, run ibmcloud iam access-group-user-add <access_group_name> <user_email>.



Resource group
(https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-why)
* [Configuring project-wide service binding operations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-sb)



* [What access permissions are required to configure service binding operations?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-sb-access)
* [What's the relationship between the service ID and the operator secret?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-sb-relation)
* [Configuring service bindings operations with a Code Engine autogenerated service ID](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-sb-auto)
* [Configuring service binding operations with a custom service ID](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-sb-customserviceid)
* [Removing configured service binding operations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-sb-remove)



* [Configuring project-wide access to Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr)



* [What access permissions are required for Code Engine managed access to IBM Cloud Container Registry?](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrationsprojectintegration-cr-access)
* [What's the relationship between the service ID and the registry secret?]
Click the Access policies tab, and then click Assign access.
2. Click the Account management card.
3. Select Support Center.
4. To allow the user to view, add, and edit support cases, select Administrator.
5. Click Assign.





Downgrading permissions? The action can take a few minutes to complete.





 Assigning infrastructure access through the CLI 

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).

Before you begin:



* Make sure that you are the account owner or have Super User and all device access. You can't grant a user access that you don't have.
* Review the [required and suggested classic infrastructure permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-classic-roles).



To customize classic infrastructure permissions through the CLI:



1. Check whether the credentials for classic infrastructure access for Red Hat OpenShift on IBM Cloud in the region and resource group have any missing required or suggested permissions.

ibmcloud oc infra-permissions get --region <region>

Example output if classic infrastructure access is based on an API key.

...with infrastructure access set up by linked account API key.

Example output if classic infrastructure access is based on manually set credentials.

...with infrastructure access set up by manually set IaaS credentials.
2. Get the user whose classic infrastructure credentials are used.



* API key: Check the API key that is used for the region and resource group of the cluster. Note the Name and Email of the API key owner in the output of the following command.

ibmcloud oc api-key info --cluster <cluster_name_or_ID>
* Manually-set credentials: Get the username in the output of the following command.

ibmcloud oc credential get --region <region>
Click Add to group.
6. Click the Access policies tab.
7. Click Assign access. Now, the breadcrumbs on the page are Groups / Manage Group.





3. Assign an access policy to Red Hat OpenShift on IBM Cloud.



1. Click the IAM services tile.
2. In the services drop-down list, select Kubernetes Service. You can enter text in the drop-down list instead of scrolling through the list.
3. Optional: To scope the access policy to a resource group, select the resource group from the resource group drop-down list. If you want to scope the policy to a Kubernetes namespace, make sure to clear the resource group drop-down list. You can't scope an access policy to both a Kubernetes namespace and a resource group at the same time.
4. From the Region list, select one or all regions.
5. From the Clusterstring equals drop-down list, select the cluster that you want to scope the access policy to. To scope the policy to all clusters, clear or leave the field blank.
6. From the Namespacestring equals field, enter the Kubernetes namespace that you want to scope the access policy to. Note that you can't scope an access policy to a namespace if you also scope the access policy to a resource group. Additionally, if you scope an access policy to a namespace, you must assign only a service access role. don't assign a platform access role at the same time as you assign a service access role. Assign a platform access role separately.
7. Select roles for the access policy.



* Platform access role: Grants access to Red Hat OpenShift on IBM Cloud so that users can manage infrastructure resources such as clusters, worker nodes, worker pools, Ingress application load balancers, and storage. To find a list of supported actions per role, see [platform access roles reference page](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles).
* [Service access roles](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-service-access)
* [Common use cases and roles](https://cloud.ibm.com/docs/satellite?topic=satellite-iamiam-roles-usecases)



* Consider creating a Reader service policy to IBM Cloud Satellite (and not scoped to a particular resource type or resource) so that users can view the Satellite Config resources that run in Satellite clusters, such as pods or deployments.



4. [Assign the access group](https://cloud.ibm.com/docs/account?topic=account-groupsaccess_ag) with the appropriate scope for any other IBM Cloud services that you plan to use in your Satellite location. Refer to each service documentation for the level of access that you need. Common services include:



* Red Hat OpenShift on IBM Cloud clusters: Kubernetes Service in the UI, containers-kubernetes in the API and CLI.
* IBM Cloud Container Registry for a private registry across clusters: Container Registry in the UI, container-registry in the API and CLI.
* IBM Cloud Object Storage for the backing storage for your location information: Cloud Object Storage in the UI, cos in the API and CLI.



5. [Assign the access group](https://cloud.ibm.com/docs/account?topic=account-groupsaccess_ag) with the Viewer platform access role to any resource groups that you plan to use with Satellite.







 Assigning access policy to access group by using the console 

Use the IBM Cloud IAM console to assign an access policy to an access group to manage Satellite locations, hosts, and endpoints as shown in the following example.



1. Log in to [IBM Cloud](https://cloud.ibm.com/).
2. From the menu bar, click Manage > Access (IAM).
3. Click Access groups, and then click the access group that you want to assign access to IBM Cloud Satellite.
4. Click the Access policies tab, and then click Assign access.
5.
An access group can be created to organize a set of users and service IDs into a single entity. It makes it easy for you to assign access. You can assign a single policy to the group instead of assigning the same access multiple times per individual user or service ID. Thus, you can organize groups for roles on your development project and align security and project management.

You can find information on the individual services and their available IAM access roles here:



* [Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceservice). Note that this service also provides examples for [mapping service roles to typical project roles](https://cloud.ibm.com/docs/containers?topic=containers-users).
* [Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam)
* [App ID](https://cloud.ibm.com/docs/appid?topic=appid-service-access-management)
* [IBM Cloudant](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-managing-access-for-cloudant)
* [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iam)
* [Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iam)
* [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessservice-access-roles)
* [Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam)



To get started, check out the [best practices for access management and how to define access groups](https://cloud.ibm.com/docs/account?topic=account-account_setupresource-group-strategy).





 Remove resources 

To remove the resource, delete the deployed container and then the provisioned services.
.operator("stringEquals")
.build();

ResourceAttribute serviceNameResourceAttribute = new ResourceAttribute.Builder()
.name("serviceName")
.value("container-registry")
.operator("stringEquals")
.build();

PolicyResource policyResources = new PolicyResource.Builder()
.addAttributes(accountIdResourceAttribute)
.addAttributes(serviceNameResourceAttribute)
.build();

CreatePolicyOptions options = new CreatePolicyOptions.Builder()
.type("access")
.subjects(Arrays.asList(policySubjects))
.roles(Arrays.asList(policyRoles))
.resources(Arrays.asList(policyResources))
.build();

Response<Policy> response = service.createPolicy(options).execute();
Policy policy = response.getResult();

System.out.println(policy);

policy_subjects = PolicySubject(
attributes=[SubjectAttribute(name='iam_id', value='IBMid-123453user')])
policy_roles = PolicyRole(
role_id='crn:v1:bluemix:public:container-registry::::serviceRole:Manager')
account_id_resource_attribute = ResourceAttribute(
name='accountId', value='ACCOUNT_ID')
service_name_resource_attribute = ResourceAttribute(
name='serviceName', value='container-registry')
policy_resources = PolicyResource(
attributes=[account_id_resource_attribute,
service_name_resource_attribute])

policy = iam_policy_management_service.create_policy(
type='access',
subjects=[policy_subjects],
* [Setting up builds in the internal registry to push images to IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registrybuilds_registry)
* [Using IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_iccr)
* [Understanding how to authorize your cluster to pull images from a private registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth)



* [Default image pull secret setup](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth_default)
* [Private network connection to icr.io registries](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth_private)



* [Updating existing clusters to use the API key image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagePullSecret_migrate_api_key)



* [Updating your image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryupdate-pull-secret)



* [Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Red Hat OpenShift projects](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother)



* [Copying an existing image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret)
* [Creating an image pull secret with different IAM API key credentials](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts)
oc create secret docker-registry entitled-cp-icr-io --docker-server=cp.icr.io --docker-username=cp --docker-password=<entitlement_key> --docker-email=<docker_email> -n <project>
3. Add the image pull secret to the service account of the namespace so that any container in the project can use the entitlement key to pull entitled images. For more information, see [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).

oc patch -n <project> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"entitled-cp-icr-io"}}]'
4. Create a pod in the project that builds a container from an image in the entitled registry.

oc run <pod_name> --image=cp.icr.io/<image_name> -n <project> --generator=run-pod/v1
5. Check that your container was able to successfully build from the entitled image by verifying that the pod is in a Running status.

oc get pod <pod_name> -n <project>



Wondering what to do next? You can [set up the entitled Helm chart repository](https://cloud.ibm.com/docs/openshift?topic=openshift-helm), where Helm charts that incorporate entitled software are stored. If you already have Helm installed in your cluster, run helm repo add entitled https://raw.githubusercontent.com/IBM/charts/master/repo/entitled.





 Adding a private registry to the global pull secret 

With OpenShift Container Platform, you can set up a global image pull secret that each worker node in the cluster can use to pull images from a private registry.
ibmcloud iam authorization-policy-create is cloud-object-storage Reader,Writer --source-resource-type image

For more information, see [ibmcloud iam authorization-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_authorization_policy_create).





 Granting access to a specific bucket from the CLI 

You can choose to grant authorization to a specific bucket in IBM Cloud Object Storage. The following example describes how to grant Reader access to a specific bucket for importing images from IBM Cloud Object Storage. To export an image to IBM Cloud Object Storage, you must also grant Writer access.

Before you run the command you need to know the GUID for the IBM Cloud Object Storage service instance.



1. In the [IBM Cloud console ![External link icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/launch-glyph.svg)](https://cloud.ibm.com/login), go to Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > Resource list > Storage.
2. To display the details for the IBM Cloud Object Storage service instance where your images are stored, click in the table row that is associated with the instance, in the Group, Location, Product, or Status columns, for example. Don't click the name of the service instance, which opens the Buckets page.
3. From the right panel, copy the GUID. For example, f7d4676f-f298-4cb3-8390-2fe258a5d6df.
4. Run the following command and replace $COS_INSTANCE_GUID with the GUID.
If you don't have a Red Hat account, follow the steps to [create one](https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/auth?client_id=customer-portal&redirect_uri=https%3A%2F%2Faccess.redhat.com%2Fwebassets%2Favalon%2Fj%2Fincludes%2Fsession%2Fscribe%2F%3FredirectTo%3Dhttps%253A%252F%252Faccess.redhat.com%252Ftags%252Flogin&state=cb7a0391-a189-468d-b979-aaebc5344f26&nonce=1e7e5af7-0323-46da-8a69-54d204a182e8&response_mode=fragment&response_type=code&scope=openid).

podman login registry.redhat.io
2. Log in to IBM Cloud Container Registry with the username iamapikey.

podman login us.icr.io -u iamapikey -p IAM-API-KEY







 Step 7: Create a namespace in IBM Cloud Container Registry 



1. Set the IBM Cloud Container Registry region in your CLI. This region must be the same region your cluster is in.

ibmcloud cr region-set us-south
2. Create a namespace in IBM Cloud Container Registry. This namespace is used for the OpenShift Data Foundation images.

ibmcloud cr namespace-add NAMESPACE







 Step 8: Mirror the Operator index to IBM Cloud Container Registry 



1. Copy the following ImageSetConfiguration and save it as a file called imageset.yaml.

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
registry:
imageURL: us.icr.io/NAMESPACE/redhat-operator-index
skipTLS: false