vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Then, in your cluster's account, save the API key credentials in an image pull secret for each cluster and cluster project.

The following steps create an API key that stores the credentials of an IBM Cloud IAM service ID. Instead of using a service ID, you might want to create an API key for a user ID that has an IBM Cloud IAM service access policy to IBM Cloud Container Registry. However, make sure that the user is a functional ID or have a plan in case the user leaves so that the cluster can still access the registry.



1. List available Red Hat OpenShift projects in your cluster, or create a project to use where you want to deploy containers from your registry images.

oc get projects

Example output

default Active
ibm-cert-store Active
ibm-system Active
kube-public Active
kube-system Active

To create a project

oc new-project <project_name>
2. Create an IBM Cloud IAM service ID for your cluster that is used for the IAM policies and API key credentials in the image pull secret. Be sure to give the service ID a description that helps you retrieve the service ID later, such as including both the cluster and project name.

ibmcloud iam service-id-create <cluster_name>-<project>-id --description "Service ID for IBM Cloud Container Registry in Red Hat OpenShift on IBM Cloud cluster <cluster_name> project <project>"
3. Create a custom IBM Cloud IAM policy for your cluster service ID that grants access to IBM Cloud Container Registry.

ibmcloud iam service-policy-create <cluster_service_ID> --roles <service_access_role> --service-name container-registry [--region <IAM_region>] [--resource-type namespace --resource <registry_namespace>]

cluster_service_ID
: Required. Replace with the <cluster_name>-<kube_namespace>-id service ID that you previously created for your Kubernetes cluster.

--service-name container-registry
: Required. Enter container-registry so that the IAM policy is for IBM Cloud Container Registry.
Set the Source account for This account if the cluster you want to authorize accessing KMS resides in the current account, otherwise if the cluster located under a different account, select Other account and provide the account ID.
2. Set the Source service to Kubernetes Service.
3. Set the Target service to your KMS provider, such as Key Protect.
4. Include at least Reader service access.
5. Enable the authorization to be delegated by the source and dependent services.



* Required service access policy for Cloud Block Storage and the KMS provider



1. Set the Source account for This account if the cluster you want to authorize accessing KMS resides in the current account, otherwise if the cluster located under a different account, select Other account and provide the account ID.
2. Set the Source service to Cloud Block Storage.
3. Set the Target service to your KMS provider, such as Key Protect.
4. Include at least Reader service access.





Red Hat OpenShift on IBM Cloud automatically creates a service-to-service delegation policy for the Cloud Block Storage service in the IBM-managed service account to the KMS provider instance under the account where the KMS instance and CRK reside. This delegation policy is required so that the VPC infrastructure can encrypt the boot volume of the worker nodes in the IBM-managed service account with your customer-provided root key of the KMS provider.
3. Create a cluster or worker pool that includes the account where the KMS instance resides, the KMS provider instance and root key. Each worker node in the worker pool then is encrypted by the KMS provider that you manage. Each worker pool in your cluster can use the same KMS instance and root key, the same KMS instance with different root keys, or different instances.



* Creating a cluster: Only the default worker pool's nodes are encrypted. After you create the cluster, if you create more worker pools, you must enable encryption in each pool separately.
To access your IBM Cloud Object Storage service instance to read and write data, you must securely store the service credentials in a Kubernetes secret. The IBM Cloud Object Storage plug-in uses these credentials for every read or write operation to your bucket.

Follow these steps to create a Kubernetes secret for the credentials of an IBM Cloud Object Storage service instance. If you plan to use a local Cloud Object Storage server or a different s3 API endpoint, create a Kubernetes secret with the appropriate credentials.

Before you begin:



* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* Make sure that you have the Manager service access role for the cluster.



To create a secret for your IBM Cloud Object Storage credentials:



1. Retrieve the apikey, or the access_key_id and the secret_access_key of your [IBM Cloud Object Storage service credentials](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-cos-understandservice_credentials). Note that the service credentials must be enough for the bucket operations that your app needs to perform. For example, if your app reads data from a bucket, the service credentials you see in your secret must have Reader permissions at minimum. If you want to integrate Key Protect encryption when creating new buckets from PVCs in your cluster, you must to include the root key CRN when creating your [IBM Cloud Object Storage secret](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-cos-understandcreate_cos_secret). Note that Key Protect encryption can't be added to existing buckets.
2. Get the GUID of your IBM Cloud Object Storage service instance.

ibmcloud resource service-instance <service_name> | grep GUID
3. Create a Kubernetes secret to store your service credentials. When you create your secret, all values are automatically encoded to base64. In the following example, the secret name is cos-write-access.
Managing access for apps in compute resources 

This tutorial guides you through the steps to centrally manage fine-grained authorization for all applications that are running in a compute resource without creating service IDs or managing the API key lifecycle for applications. By completing this tutorial, you learn how to create a trusted profile, establish trust with compute resources based on specific attributes, and define a policy to assign access to resources.

By using trusted profiles, you can establish a flexible, secure way for apps that are running on a compute resource to access other IBM Cloud® resources. All compute resource instances that share certain attributes, such as name, namespace, tags, or location, are mapped to a common profile and can share access to IBM Cloud resources. This common identity makes it possible to give the applications within various compute resources access to an external resource one time, rather than cluster-by-cluster.

You must enable the "Service Account Token Volume Projection" on the Kubernetes cluster to apply the trusted profile identity. For more information, see [Authorizing pods in your cluster to IBM Cloud services with IAM trusted profiles](https://cloud.ibm.com/docs/containers?topic=containers-pod-iam-identity&interface=ui)

Let's say that you are the lead developer on a project for your team that is planning to run a new chatbot app on an IBM Cloud® Kubernetes Service cluster. You want the app to have access to IAM-enabled services but without storing credentials in the code. Your manager has given you an administrator access in the account to create trusted profiles and give your runtime environments access to the resources you need to build the chatbot app.



 Before you begin 



* This tutorial might incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.
* Make sure you have the following access:



* Administrator role in the account to create a trusted profile
* Administrator role on the specific resources to which you are assigning access



* Create a cluster that runs IBM Cloud Kubernetes Service Version 1.21 or later.
[Store your IBM Cloud Object Storage service credentials in a Kubernetes secret](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandcreate_cos_secret)).
3. From the ibm-object-storage-plugin, navigate to the templates directory and list available files. OS X and Linux

cd templates && ls

Windows

chdir templates && dir
4. Open the provisioner-sa.yaml file and look for the ibmcloud-object-storage-secret-readerClusterRole definition.
5. Add the name of the secret that you created earlier to the list of secrets that the plug-in is authorized to access in the resourceNames section.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: ibmcloud-object-storage-secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["<secret_name1>","<secret_name2>"]
verbs: ["get"]
6. Save your changes and navigate to your working directory.



10. Install the ibm-object-storage-plugin in your cluster. When you install the plug-in, pre-defined storage classes are added to your cluster. If you completed the previous step for limiting the IBM Cloud Object Storage plug-in to access only the Kubernetes secrets that hold your IBM Cloud Object Storage service credentials and you are still targeting the templates directory, change directories to your working directory. To set a limit on how much storage is available for the bucket, set the --set quotaLimit=trueVPC clusters only: To enable authorized IPs on VPC, set the --set bucketAccessPolicy=true option.



If you don't set the --set quotaLimit=true option during installation, you can't set quotas for your PVCs.

Example helm ibmc install commands for OS X and Linux
Classic infrastructure

View the pod security policy configuration for a cluster's Kubernetes API server. Note that pod security policies are not available in clusters that run version 1.25 or later.

ibmcloud oc cluster master pod-security policy get --cluster CLUSTER [--output OUTPUT] [-q]

Minimum required permissions
: Viewer platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example cluster master pod-security policy get command 

ibmcloud oc cluster master pod-security policy get --cluster mycluster







 ibmcloud oc cluster master pod-security set 

Virtual Private Cloud

Classic infrastructure

Set and enable the [pod security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission&interface=ui) for a cluster's Kubernetes API server.

ibmcloud oc cluster master pod-security set --cluster CLUSTER [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example cluster master pod-security set command 

ibmcloud oc cluster master pod-security set --cluster mycluster







 ibmcloud oc cluster master pod-security unset 

Virtual Private Cloud

Classic infrastructure

Remove the [pod security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission&interface=ui) configuration for a cluster's Kubernetes API server.
* 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 ks api-key info --cluster <cluster_name_or_ID>
* Manually-set credentials: Get the username in the output of the following command.

ibmcloud ks credential get --region <region>



Need to change the infrastructure credential owner? Check out the ibmcloud ks api-key reset[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_reset) or the ibmcloud ks credential set[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_set).
3. List the users in your classic infrastructure account and note the id of the user whose credentials are set manually or by the API key.

ibmcloud sl user list
4. List the current classic infrastructure permissions that the user has. Note the KeyName of the permission that you want to change.

ibmcloud sl user permissions <user_id>
5. Edit the permission of the user. For the --enable option, enter true to assign the permission or false to remove the permission.

ibmcloud sl user permission-edit <user_id> --permission <permission_keyname> --enable (true|false)

To assign or remove user access to all permissions:

ibmcloud sl user permission-edit <user_id> --permission ALL --enable (true|false)
6. For individual required or suggested permissions, see the [Infrastructure roles](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles) table.
* [ibmcloud ks infra-permissions get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliinfra_permissions_get)







 ibmcloud ks kms 

[View and configure Key Management Service integrations](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliks_kms).



* kms crk: List and configure the root keys for a Key Management Service instance.



* [ibmcloud ks kms crk ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliks_kms_crk_ls)



* [ibmcloud ks kms enable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliks_kms_enable)
* kms instance: View and configure available Key Management Service instances.



* [ibmcloud ks kms instance ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliks_kms_instance_ls)









 ibmcloud ks quota 

[View the quota and limits for cluster-related resources in your IBM Cloud account](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_quota).



* [ibmcloud ks quota ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_quota_ls)







 ibmcloud ks subnets 

[List available portable subnets in your IBM Cloud infrastructure account](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_subnets).





 ibmcloud ks vlan
3. Create a Kubernetes secret named px-ibm in the portworx project of your cluster to store your IBM Key Protect information.



1. Create a configuration file for your Kubernetes secret with the following content.

apiVersion: v1
kind: Secret
metadata:
name: px-ibm
namespace: portworx
type: Opaque
data:
IBM_SERVICE_API_KEY: <base64_apikey>
IBM_INSTANCE_ID: <base64_guid>
IBM_CUSTOMER_ROOT_KEY: <base64_rootkey>
IBM_BASE_URL: <base64_endpoint>

metadata.name
: Enter px-ibm as the name for your Kubernetes secret. If you use a different name, Portworx does not recognize the secret during installation.

data.IBM_SERVICE_API_KEY
: Enter the base64 encoded IBM Key Protect or Hyper Protect Crypto Services API key that you retrieved earlier.

data.IBM_INSTANCE_ID
: Enter the base64 encoded service instance GUID that you retrieved earlier.

data.IBM_CUSTOMER_ROOT_KEY
: Enter the base64 encoded root key that you retrieved earlier.

data.IBM_BASE_URL
: IBM Key Protect: Enter the base64 encoded API endpoint of your service instance.
: Hyper Protect Crypto Services: Enter the base64 encoded Key Management public endpoint.
2. Create the secret in the portworx project of your cluster.

oc apply -f secret.yaml
3. Verify that the secret is created successfully.

oc get secrets -n portworx



4. If you set up encryption before your installed Portworx, you can now [install Portworx in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_deploy).
Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--c, --cluster CLUSTER
: Required. The name or ID of the cluster.

--name NAME
: Required. The name of the secret to add the field to.

--field CRN
: Required. The secret CRN to add to the field. You can specify more than one field at a time. For more information, see [Managing non-TLS secret fields](https://cloud.ibm.com/docs/containers?topic=containers-secretsnon-tls-field).



* To pull in the secret with the default field name for the secret type, use the default field option: --field <crn>. This option is available for all non-TLS secret types.
* To specify the field name, use the named field option: --field name=<crn>. This option is available for arbitrary and IAM credential secret types.
* To use the IBM Cloud Secrets Manager secret as the prefix, use the prefixed field option: --field prefix=<crn>. This option is available for IAM credential, username and password, and key value secret types.



--namespace NAMESPACE
: Required. The namespace that the secret is deployed to.

-q
: Optional: Do not show the message of the day or update reminders.

Example to add default, named, and prefixed fields to a set of IAM credentials:
* [ibmcloud ks api-key reset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_reset)







 ibmcloud ks credential 

[Set and unset credentials that allow you to access the IBM Cloud classic infrastructure portfolio through your IBM Cloud account](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicredential).



* [ibmcloud ks credential get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credential_get)
* [ibmcloud ks credential set classic](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_set)
* [ibmcloud ks credential unset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_unset)







 ibmcloud ks infra-permissions 

[View information about infrastructure permissions that allow you to access the IBM Cloud classic infrastructure portfolio through your IBM Cloud account](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliinfra-commands).



* [ibmcloud ks infra-permissions get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliinfra_permissions_get)







 ibmcloud ks kms 

[View and configure Key Management Service integrations](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliks_kms).



* kms crk: List and configure the root keys for a Key Management Service instance.
You can manage service-to-service authorizations at any time by visiting Manage > Security > Identity and Access and choosing Authorizations. 
 kms_key_crn This parameter is required if you use the kms_instance_crn parameter. Otherwise, it must not be supplied in the CLI command. The kms_key_crn parameter is set to the CRN of the encryption key that is stored in the Key Protect instance that is defined by the kms_instance_crn parameter. 



The following example command includes the extra parameters.

ibmcloud resource service-instance-create cloudant-dedicated-with-byok cloudantnosqldb dedicated-hardware us-south -p '{"location":"dallas", "hipaa":"false", "kms_instance_crn": "crn:v1:bluemix:public:kms:us-south:a/abcdefg7df5907a4ae72ad28d9f493d6:888a5a41-543c-4ca7-af83-74da3bb8f711::", "kms_key_crn": "crn:v1:bluemix:public:kms:us-south:a/abcdefg7df5907a4ae72ad28d9f493d6:888a5a41-543c-4ca7-af83-74da3bb8f711:key:0123c653-f904-4fe7-9fdb-5097e1ed85db"}'





 Step 4: Provisioning a Standard plan instance on a Dedicated Hardware environment with the IBM Cloud CLI 



1. Log in to use the IBM Cloud CLI. For more information about how to log in and set a target resource group, see [log in to your IBM Cloud account](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-creating-an-ibm-cloudant-instance-on-ibm-cloud-by-using-the-ibm-cloud-clilogging-in-to-your-ibm-cloud-account).
2.
The owner of the API key that is used to access the IBM Cloud infrastructure portfolio does not have the required permissions to perform the action, or might be pending deletion.

As the user, follow these steps:



1. If you have access to multiple accounts, make sure that you are logged in to the account where you want to work with IBM Cloud Kubernetes Service.
2. Run ibmcloud ks api-key info --cluster <cluster_name_or_ID> to view the current API key owner that is used to access the IBM Cloud infrastructure portfolio.
3. Run ibmcloud account list to view the owner of the IBM Cloud account that you currently use.
4. Contact the owner of the IBM Cloud account and report that the API key owner has insufficient permissions in IBM Cloud infrastructure or might be pending to be deleted.



As the account owner, follow these steps:



1. Review the [required classic permissions in IBM Cloud infrastructure](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access) to perform the action that previously failed. For the VPC infrastructure provider, the API key owner must have the Administrator platform access role.
2. Fix the permissions of the API key owner or create a new API key by using the [ibmcloud ks api-key reset --region <region>](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_reset) command.
3. If you or another account admin manually set IBM Cloud infrastructure credentials in your account, run [ibmcloud ks credential unset --region <region>](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_unset) to remove the credentials from your account.
By default, Kubernetes requires every request to go through several stages before access to the API server is granted.

Authentication
: Validates the identity of a registered user or service account.

Authorization
: Limits the permissions of authenticated users and service accounts to ensure that they can access and operate only the cluster components that you want them to.

Admission control
: Validates or mutates requests before they are processed by the Kubernetes API server. Many Kubernetes features require admission controllers to properly function.





 What does IBM Cloud Kubernetes Service do to secure my API server and etcd data store? 

The following image shows the default cluster security settings that address authentication, authorization, admission control, and secure connectivity between the Kubernetes master and worker nodes.

Zoom

![Describes the security stages when you access the Kubernetes API server.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_security_apiserver_access.png)

Figure 1. Security stages when accessing the Kubernetes API server

Review the following security features for Kubernetes API server and etcd.

Fully managed and dedicated Kubernetes master
: Every cluster in IBM Cloud Kubernetes Service is controlled by a dedicated Kubernetes master that is managed by IBM in an IBM-owned IBM Cloud account. The Kubernetes master is set up with the following dedicated components that are not shared with other IBM customers.



* etcd data store: Stores all Kubernetes resources of a cluster, such as Services, Deployments, and Pods. Kubernetes ConfigMaps and Secrets are app data that is stored as key value pairs so that they can be used by an app that runs in a pod. Data in etcd is stored on the local disk of the Kubernetes master and is backed up to IBM Cloud Object Storage. Data is encrypted during transit to IBM Cloud Object Storage and at rest.