vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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.

Example create secret command that uses an API key.

oc create secret generic cos-write-access --type=ibm/ibmc-s3fs --from-literal=api-key=<api_key> --from-literal=service-instance-id=<service_instance_guid>

Example create secret command that uses HMAC authentication.

oc create secret generic cos-write-access --type=ibm/ibmc-s3fs --from-literal=access-key=<access_key_ID> --from-literal=secret-key=<secret_access_key>
4. If you want to use Key Protect Encryption for buckets created with IBM Cloud Object Storage s3fs plug-in, include the keyprotect root key crn value in the secret that is used to create the PVC.

Key Protect encryption can be used only when you create new buckets. If the Key Protect root key that is used for encryption is deleted, all the files in the associated buckets are inaccessible.



1. Create a YAML file for your IBM Cloud Object Storage secret.

---
apiVersion: v1
data:
access-key: xxx
secret-key: xxx
kp-root-key-crn: <keyprotect-root-key-crn in base64 encoded format>
kind: Secret
metadata:
name: <cos-write-access>
type: ibm/ibmc-s3fs
2. Apply the secret to your cluster.

kubectl apply -f <secret_name>



api-key
If you did not grant Satellite Config access to your cluster during cluster creation time, you can still set up the access manually.

Choose from the following options.



* Admin access when you create a Satellite cluster: You can enable admin permissions when you create the cluster in the console or in the CLI by using the --enable-config-admin option in the ibmcloud oc cluster create satellite command. After creating the cluster, you must perform a one-time login by running ibmcloud ks cluster config in the command line.
* Admin access for clusters in the public cloud: See [Registering existing clusters with Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-register-openshift-clusters).
* Custom access, or access for Satellite clusters that you did not opt in for admin access: Complete the following steps.



To customize access, or to add access for Satellite clusters that you did not opt in for admin access at cluster creation.



1. [Access your Satellite cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat).
2. For each cluster in the cluster group, grant Satellite Config access to manage Kubernetes resources. Choose from the following options: cluster admin access, custom access that is cluster-wide, or custom access that is scoped to a project. 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.
![Kubernetes secure app secrets options](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_sm.png)

Figure 6. Kubernetes Secure app secrets options

For more information about managing your secrets in IBM Key Protect or HashiCorp, see [IBM Key Protect](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-tekton-ci-compliancecd-devsecops-key-protect-ci) or [HashiCorp](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-tekton-ci-compliancecd-devsecops-vault-ci).







 Step 2: Configure the deployment target 

Configure the target Kubernetes cluster to deploy the app to. After the app passes the build, test, and scan phase, the pipeline deploys the built app image to the target Kubernetes cluster. This deployment is now ready for acceptance testing or integration testing.

If the API key has the required access, the following fields automatically load by using the API key that is either created, retrieved from a vault, or manually specified. If the API key is valid, values for the Container registry region and namespace Cluster region, name, namespace, and Resource group are automatically populated. You can update any of these fields to match your configuration.



* App name: The name of the app. The default app name is hello-containers.
* IBM Cloud API Key: The API key that is used to interact with the ibmcloud CLI tool in several tasks. Use one of the following methods to specify the API key that you want to use:



* Click the key icon to import an existing API key from a secret vault of your choice.
* Copy and paste an existing API key.
* Click New to create an API key.
[Grant the service-to-service authorization in IAM](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-kmip-vmwaretutorial-kmip-s2s).
2. [Configure KMIP for VMWare with Hyper Protect Crypto Services instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-kmip-vmwaretutorial-kmip-configure).
3. [Configure a trusted connection between the vCenter Server and KMIP adapter](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-kmip-vmwaretutorial-kmip-verify).



Let's start with the service authorization process.





 Step 1: Grant the service-to-service authorization in IAM 



1. Click Manage>Access(IAM) on the menu after you log in to IBM Cloud.
2. Select Authorizations on the left navigation pane.
3. Click the Create button.
4. On the Grant a service authorization page, fill in the following information:



* Under the Source service drop-down list, select VMWare Solutions, and then select the KMIP for VMWare service instance ID.
* Under the Target service drop-down list, select Hyper Protect Crypto Services services, and then select the Hyper Protect Crypto Services instance ID.
* In the Platform access pane, select the Viewer option.
* In the Service Access pane, select the VMWare KMIP Manager option.



5. Click the Authorize button to complete the service to service authorization.







 Step 2: Configure KMIP for VMWare with Hyper Protect Crypto Services instance 



1. In the IBM Cloud for VMware Solutions console, click Resources from the left navigation pane.
2. Scroll down to the KMIP for VMware Instances table, click the instance that you want to configure the Hyper Protect Crypto Services with.
2. Create a project in your cluster called portworx.

oc create ns portworx
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
ibmcloud oc cluster service bind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE [--key SERVICE_INSTANCE_KEY] [--role IAM_SERVICE_ROLE] --service SERVICE_INSTANCE [-q]

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

Command options:

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

-n, --namespace KUBERNETES_NAMESPACE
: Required: The name of the Red Hat OpenShift project where you want to create the Kubernetes secret for your service credentials.

--key SERVICE_INSTANCE_KEY
: Optional: The name or GUID of an existing service key. When you use the service-binding command, new service credentials are automatically created for your service instance and assigned the IAM Writer service access role for IAM-enabled services. If you want to use an existing service key that you created earlier, use this option. If you define a service key, you can't set the --role option at the same time because your service keys are already created with a specific IAM service access role.

--role IAM_SERVICE_ROLE
: The IBM Cloud IAM role that you want the service key to have. This value is optional and can be used for IAM-enabled services only. If you don't set this option, your service credentials are automatically created and assigned the IAM Writer service access role. If you want to use existing service keys by specifying the --key option, don't include this option. To list available roles for the service, run ibmcloud iam roles --service <service_name>. The service name is the name of the service in the catalog, which you can get by running ibmcloud catalog search.

--service SERVICE_INSTANCE
: Required: The name of the IBM Cloud service instance that you want to bind. To find the name, run ibmcloud service list for Cloud Foundry services, and ibmcloud resource service-instances for IAM-enabled services.

-q
You might also create an API key for a [service ID](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_service_id). For more information, see [Understanding API keys](https://cloud.ibm.com/docs/account?topic=account-manapikey).



1. Create an IBM Cloud API key. Save your API key in a secure location. You can't retrieve the API key again. If you want to export the output to a file on your local machine, include the --file <path>/<file_name> option.

ibmcloud iam api-key-create <name>
2. Configure your cluster to add the API key user to your cluster RBAC policies and to set your session context to your cluster server.



1. Log in to IBM Cloud with the API key credentials.

ibmcloud login --apikey <API_key>
2. Download and add the kubeconfig configuration file for your cluster to your existing kubeconfig in /.kube/config or the last file in the KUBECONFIG environment variable. Note: If you enabled the private cloud service endpoint and want to use it for the cluster context, include the --endpoint private option. To use the private cloud service endpoint to connect to your cluster, you must be in your IBM Cloud private network or connected to the private network through a [VPC VPN connection](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example), or for classic infrastructure, a [classic VPN connection](https://cloud.ibm.com/docs/iaas-vpn?topic=iaas-vpn-getting-started) or [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl).

ibmcloud oc cluster config -c <cluster_name_or_ID> [--endpoint private]



3.
![Kubernetes secure app secrets options](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/sat_kub_secrets_manager.png)

Figure 6. Kubernetes Secure app secrets options

For more information about managing your secrets in IBM Key Protect or HashiCorp, see [IBM Key Protect](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-tekton-ci-compliancecd-devsecops-key-protect-ci) or [HashiCorp](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-tekton-ci-compliancecd-devsecops-vault-ci).







 Step 2: Configure the deployment target 

Configure the target Kubernetes cluster to deploy the app to. After the app passes the build, test, and scan phase, the pipeline deploys the built app image to the target Kubernetes cluster. This deployment is now ready for acceptance testing or integration testing.

If the API key has the required access, the following fields automatically load by using the API key that is either created, retrieved from a vault, or manually specified. If the API key is valid, values for the Container registry region and namespace Cluster region, name, namespace, and Resource group are automatically populated. You can update any of these fields to match your configuration.



* App name: The name of the app. The default app name is hello-containers.
* IBM Cloud API Key: The API key that is used to interact with the ibmcloud CLI tool in several tasks. Use one of the following methods to specify the API key that you want to use:



* Click the key icon to import an existing API key from a secret vault of your choice.
* Copy and paste an existing API key.
* Click New to create an API key.
* An additional Reader[service-to-service authorization policy](https://cloud.ibm.com/docs/account?topic=account-serviceauth) between Red Hat OpenShift on IBM Cloud and Key Protect is automatically created for your cluster, if the policy does not already exist. Without this policy, your cluster can't use all the [Key Protect features](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms-keyprotect-features).



4. Enable KMS encryption.







 Enabling KMS encryption for the cluster through the CLI 

You can enable a KMS provider, update the KMS provider instance, or update the root key through the CLI.

Setting up cross-account encryption by using a KMS in a different account is supported in the CLI or API.



1. Complete the [prerequisite steps](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms_prereqs) to create a KMS instance and root key. If you want to use cross account KMS encryption, make sure to create the KMS and root key in the account whose KMS instance you want to use.
2. Get the ID of the KMS instance that you previously created.

ibmcloud oc kms instance ls
3. Get the ID of the root key that you previously created.

ibmcloud oc kms crk ls --instance-id <KMS_instance_ID>
4. Enable the KMS provider to encrypt secrets in your cluster. Fill in the options with the information that you previously retrieved. The KMS provider's private cloud service endpoint is used by default to download the encryption keys. To use the public cloud service endpoint instead, include the --public-endpoint option. The enablement process can take some time to complete.

ibmcloud oc kms enable -c <cluster_name_or_ID> --instance-id <kms_instance_ID> --crk <root_key_ID> [--public-endpoint]
* For clusters that run Red Hat OpenShift 4.4.16_1513_openshift or later: When you enable KMS encryption, an additional Reader[service-to-service authorization policy](https://cloud.ibm.com/docs/account?topic=account-serviceauth) between Red Hat OpenShift on IBM Cloud and your KMS provider, such as Key Protect, is automatically created for your cluster, if the policy doesn't already exist. Without this policy, your cluster can't use all the [Key Protect features](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms-keyprotect-features).



* Viewer platform access role for the resource group access.



Infrastructure
: 

* Classic clusters only: Super User role or the [minimum required permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-classic-roles) for classic infrastructure.
* VPC clusters only: Administrator platform access role for [VPC Infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).



User that creates the cluster
: In addition to the API key, each individual user must have the following permissions to create a cluster.
: 

* Administrator platform access role for Kubernetes Service in the console (containers-kubernetes in the API or CLI). If your access is scoped to a resource group or region, you must also have the Viewer platform access role at the Account level to view the account's VLANs.
* Administrator platform access role for Container Registry in the console (container-registry in the API or CLI) at the Account level.
* Administrator platform access role for Cloud Object Storage in the console (cos in the API or CLI) for the standard instance that you want to use to back up the internal registry images in a VPC cluster.
* Viewer platform access role to IAM Identity Service for account management access.
* Viewer platform access role for the resource group access.



More information about assigning permissions
:
DevOps operator [Operator platform access role for a cluster](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles), [Writer service access role not scoped to a namespace (for the whole cluster)](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles), [Cloud Foundry developer space role](https://cloud.ibm.com/docs/containers?topic=containers-cloud-foundry-roles). 
 Operator or site reliability engineer [Administrator platform access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles), [Reader service access role for a cluster or region](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles) or [Manager service access role for all cluster namespaces](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles) to be able to use kubectl top nodes,pods commands. 



* Where can I find a list of security bulletins that affect my cluster?

If vulnerabilities are found in Kubernetes, Kubernetes releases CVEs in security bulletins to inform users and to describe the actions that users must take to remediate the vulnerability. Kubernetes security bulletins that affect IBM Cloud Kubernetes Service users or the IBM Cloud platform are published in the [IBM Cloud security bulletin](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security).

Some CVEs require the latest patch update for a version that you can install as part of the regular [cluster update process](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) in IBM Cloud Kubernetes Service. Make sure to apply security patches in time to protect your cluster from malicious attacks.
[Store your IBM Cloud Object Storage service credentials in a Kubernetes secret](https://cloud.ibm.com/docs/openshift?topic=openshift-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
Understanding access control for clusters 

Learn how you can set up access control for your Red Hat® OpenShift® on IBM Cloud® clusters by using various types of access control, roles, and policies.



 Access control checklist 

Use the following checklist to configure user access to your Red Hat OpenShift on IBM Cloud cluster.



 IBM Cloud access control 

Your clusters use IBM Cloud Identity and Access Management (IAM) as the identity provider to control access to the cluster.



1. [Understand how roles, users, and resources in your account](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewaccess_policies) can be managed.
2. [Set the API key](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewapi_key) for all the regions and resource groups that you want to create clusters in.
3. Invite users to your account and [assign them IBM Cloud IAM roles](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the service (containers-kubernetes in the API or CLI, and Kubernetes Service in the console).

Do not assign IBM Cloud IAM platform access roles at the same time as a service access role. You must assign platform and service access roles separately.
4. To allow users to bind services to the cluster or to view logs that are forwarded from cluster logging configurations, [grant users Cloud Foundry roles](https://cloud.ibm.com/docs/account?topic=account-mngcf) for the org and space that the services are deployed to or where logs are collected.
5. If you use Kubernetes namespaces to isolate resources within the cluster, grant access to namespaces by [assigning users IBM Cloud IAM service access roles for the namespaces](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms).
6.
For more information, see [Removing user permissions](https://cloud.ibm.com/docs/containers?topic=containers-usersremoving).

Consider using a functional ID user for the API key owner instead of a personal user. In case the person leaves the team, the functional ID user remains the API key owner. Keep in mind that you can't use a service ID to set the API key.





 How can I lock down my cluster if my API key becomes compromised? 

If an API key that is set for a region and resource group in your cluster is compromised, [delete it](https://cloud.ibm.com/docs/account?topic=account-userapikeydelete_user_key) so that no further calls can be made by using the API key as authentication. For more information about securing access to the Kubernetes API server, see the [Kubernetes API server and etcd](https://cloud.ibm.com/docs/containers?topic=containers-securityapiserver) security topic.







 Ensuring that the API key or infrastructure credentials owner has the correct permissions 

To ensure that all infrastructure-related actions can be completed in the cluster, the user whose credentials you want to set for the API key must have the proper permissions. Consider using a functional ID user for the API key owner instead of a personal user. In case the person leaves the team, the functional ID user remains the API key owner. Note that you can't use a service ID to set the API key.



1. Log in to the [IBM Cloud console](https://cloud.ibm.com/).
2. To make sure that all account-related actions can be successfully performed, verify that the user has the correct IBM Cloud IAM platform access roles.



1. From the menu bar, select Manage > Access (IAM), and then click the Users page.
2. Click the name of the user who you want to set the API key for or whose credentials you want to set for the API key, and then click the Access policies tab.
3.