vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The service ID that is created with the cluster is named cluster-<cluster_ID> and is used in the default Kubernetes namespace. If you created another service ID such as to access a different Kubernetes namespace or to modify IBM Cloud IAM permissions, you customized the description.

ibmcloud iam service-ids

Example output

UUID Name Created At Last Updated Description Locked
ServiceId-aa11... <service_ID_name> 2019-02-01T19:01+0000 2019-02-01T19:01+0000 ID for <cluster_name> false
ServiceId-bb22... <service_ID_name> 2019-02-01T19:01+0000 2019-02-01T19:01+0000 Service ID for IBM Cloud Container Registry in Kubernetes cluster <cluster_name> namespace <namespace> false
2. Verify that the service ID is assigned at least an IBM Cloud IAM Reader[service access role policy for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-usercreate). If the service ID does not have the Reader service access role, [edit the IAM policies](https://cloud.ibm.com/docs/account?topic=account-serviceidsupdate_serviceid). If the policies are correct, continue with the next step to see if the credentials are valid.

ibmcloud iam service-policies <service_ID_name>

Example output

Policy ID: a111a111-b22b-333c-d4dd-e555555555e5
Roles: Reader
Resources:
Service Name container-registry
Service Instance
Region
Resource Type namespace
Resource <registry_namespace>
3. Check if the image pull secret credentials are valid.



1. Get the image pull secret configuration. If the pod is not in the default namespace, include the -n option.

kubectl get secret <image_pull_secret_name> -o yaml [-n <namespace>]
2.
A custom resource definition allows you to create resource types that do not come preinstalled with Red Hat OpenShift on IBM Cloud such an IBM Cloud service. Operators manage the lifecycle of resources and create Custom Resource Descriptors, CRDs, allowing you to manage custom resources the native "Kubernetes" way.



1. In the Administrator perspective, and click Operators > OperatorHub.
2. Find the IBM Cloud Operator, and click Install.
3. Keep the default options and click Install.
4. You may need to wait a few seconds and refresh for the operator to show the status as Succeeded.







 Create a Cloudant Service and Bind using the CRDs 

Click on the IBM Cloud Operator to open it. Scroll down to the Prerequisites section.

An API key with the appropriate permissions to create a IBM Cloudant database is required in this section. The API key is going to be stored in a Kubernetes Secret resource. This will need to be created using the shell. There are instructions in the Prerequisites section of the installed operator. Steps:



1. Use the same resource group and region that is associated with your cluster.

ibmcloud target -g <resource_group> -r <region>

To see the the resource groups in your account, run ibmcloud resource groups command
2. Verify that it looks something like this. CF API endpoint, Org and Space can be empty, Resource group matches your cluster:

API endpoint: https://cloud.ibm.com
Region: us-south
User: YOU@us.ibm.com
Account: YOURs Account (32cdeadbeefdeadbeef1234132412343) <-> 1234567
Resource group: YOUR resource group
CF API endpoint:
Org:
Space:
3. Use the helper script provided by IBM to create the following resources:



* IBM Cloud API key that represents you and your permissions to use IBM Cloud
* Kubernetes Secret named secret-ibm-cloud-operator in the default namespace. This secret has the keys api-key and region.
[Expose an app in IBM Cloud Kubernetes Service by using NodePort](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/nodeport.svg)

Figure 1. Expose an app by using NodePort



1. A request is sent to your app by using the public IP address of your worker node and the NodePort on the worker node.
2. The request is automatically forwarded to the NodePort service's internal cluster IP address and port. The internal cluster IP address is accessible inside the cluster only.
3. kube-proxy routes the request to the Kubernetes NodePort service for the app.
4. The request is forwarded to the private IP address of the pod where the app is deployed. If multiple app instances are deployed in the cluster, the NodePort service routes the requests between the app pods.



The public IP address of the worker node is not permanent. When a worker node is removed or re-created, a new public IP address is assigned to the worker node. You can use the NodePort service for testing the public access for your app or when public access is needed for a short amount of time only. When you require a stable public IP address and more availability for your service, expose your app by using a [network load balancer (NLB) service](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer) or [Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about).





 Enabling access to an app by using a NodePort service 

Expose your app as a Kubernetes NodePort service.

Because worker nodes in VPC clusters don't have a public IP address, you can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection.
Likewise, if your database uses both [public and private endpoints](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-service-endpoints), your public endpoint is used by default. Therefore, if you want to select the private endpoint, first you need to create a service key for your database so Kubernetes can use it when binding to the database. You set up a service key by using the command:

ibmcloud resource service-key-create <your-private-key> --instance-name <your_database_deployment> --service-endpoint private

The private service endpoint is selected with --service-endpoint private. After that, you bind the database to the Kubernetes cluster through the private endpoint by using the command

ibmcloud ks cluster service bind <your_cluster_name> default <your_database_deployment> --key example-private-key
5. Verify that the Kubernetes secret was created in your cluster namespace. Kubernetes uses secrets to store confidential information like the IBM Cloud Identity and Access Management (IAM) API key and the URL that the container uses to gain access. To set the cluster as the context for this session and then get the API key for accessing the instance of your deployment, run the following commands

ibmcloud ks cluster config --cluster <cluster_name_or_ID>

Then

kubectl get secrets --namespace=default

Save the name of the secret that was generated when you bound your_database_name to your Kubernetes service.
6. If you haven't already, clone the app in one of the available languages to your local environment from your console by using the following command

git clone -b <language> git@github.com:IBM-Cloud/clouddatabases-helloworld-kubernetes-examples.git
7. cd into this newly created directory, and cd into the database folder. The code for connecting to the service, and reading from and updating the database can be found in server.js.
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.
* Generate a new api-key if you don’t have an existing API key.



You can immediately save the generated API key to an existing secrets vault of your choice.
* Satellite Cluster group name: The name of the cluster group that was created in Satellite. Your app is deployed to this cluster group.
* Cluster namespace: If the cluster namespace does not exist in the clusters within the cluster group, the toolchain creates it.



Zoom

![Kubernetes secure app deployment target details for Rolling or Blue-Green](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/kub_setup_satellite_dep_target.png)

Figure 7. Kubernetes secure app Rolling deployment target details





 Step 3: Add optional tool integrations 

You can add the IBM Cloud® DevOps Insights tool integration to your toolchain without any additional configuration.

[DevOps Insights](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-di_working) is included in the created toolchain. You do not need to provide any configuration steps for DevOps Insights. The continuous integration pipeline automatically uses the DevOps Insights instance that is included in the toolchain. DevOps Insights aggregates code, test, build, and deployment data to provide visibility into the velocity and quality of all of your teams and releases.

Click Continue.





 Step 4: Complete the toolchain setup 

On the Summary page, click Create. Several steps run automatically to set up your toolchain.
[IBM Blockchain Platform](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/IBP-Diagram.svg)

Figure 1. The IBM Blockchain Platform components



* IBM Blockchain Platform Console (UI): This is the console that allows you to create and manage your blockchain components. After you provision a service instance in IBM Cloud, you can deploy an instance of the IBM Blockchain console and link it to your Kubernetes cluster on IBM Cloud. Then you can use the console to create and manage your blockchain components in your Kubernetes cluster. There is no charge for the console.
* Hyperledger Fabric Components: The console is used to create and manage blockchain components that are based on Hyperledger Fabric v2.2.10 Certificate Authority, peer, and ordering service images. These components are deployed into your Kubernetes cluster and storage is provisioned for them using the default storage class when they are deployed.







 Considerations 

Before you deploy the console, ensure that you understand the following considerations:



* IBM Blockchain Platform for IBM Cloud is built with Hyperledger Fabric v2.2.10.
* You have the option to link your IBM Blockchain Platform service instance to a free Kubernetes cluster for evaluation of the offering, however capacity and performance are limited, none of your data can be migrated, and the cluster is deleted after 30 days.
* You are responsible for the management of health monitoring, security, and logging of your Kubernetes cluster. See this [information](https://cloud.ibm.com/docs/containers?topic=containers-responsibilities_iks) for details on what IBM Cloud manages and what you are responsible for.
* You are also responsible for monitoring the resource usage of your Kubernetes cluster by using the Kubernetes dashboard. If you need to increase storage capacity of your cluster, see this information on how to modify your existing volume:
Data <br><br> * Maintain [platform-level standards](https://cloud.ibm.com/docs/overview?topic=overview-security) so that your data can be stored with controls commensurate to leading international security compliance standards.<br> * Provision clusters with Kubernetes components installed so that you can access the Kubernetes API to help manage your app data, such as with secrets and configmaps.<br> * Integrate with IBM Cloud services that you can use to store and manage your data, such as IBM Cloud Databases or Object Storage.<br> * Integrate with IBM Watson services that you can use to maximize the insights and use of your data with the latest artificial intelligence technology.<br><br><br> <br><br> * Maintain responsibility for your data and how your apps consume the data.<br><br><br>
[Expose an app in IBM Cloud Kubernetes Service by using NodePort](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/nodeport.svg)

Figure 1. Expose an app by using NodePort



1. A request is sent to your app by using the public IP address of your worker node and the NodePort on the worker node.
2. The request is automatically forwarded to the NodePort service's internal cluster IP address and port. The internal cluster IP address is accessible inside the cluster only.
3. kube-proxy routes the request to the Kubernetes NodePort service for the app.
4. The request is forwarded to the private IP address of the pod where the app is deployed. If multiple app instances are deployed in the cluster, the NodePort service routes the requests between the app pods.



The public IP address of the worker node is not permanent. When a worker node is removed or re-created, a new public IP address is assigned to the worker node. You can use the NodePort service for testing the public access for your app or when public access is needed for a short amount of time only. When you require a stable public IP address and more availability for your service, expose your app by using a [network load balancer (NLB) service](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer) or [Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about).





 Enabling access to an app by using a NodePort service 

Expose your app as a Kubernetes NodePort service.

Because worker nodes in VPC clusters don't have a public IP address, you can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection.
* What options do I have to secure my cluster?

You can use built-in security features in IBM Cloud Kubernetes Service to protect the components in your cluster, your data, and app deployments to ensure security compliance and data integrity. Use these features to secure your Kubernetes API server, etcd data store, worker node, network, storage, images, and deployments against malicious attacks. You can also leverage built-in logging and monitoring tools to detect malicious attacks and suspicious usage patterns.

For more information about the components of your cluster and how you can meet security standards for each component, see [Security for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-securitysecurity).
* What access policies do I give my cluster users?

IBM Cloud Kubernetes Service uses Cloud Identity and Access Management (IAM) to grant access to cluster resources through IAM platform access roles and Kubernetes role-based access control (RBAC) policies through IAM service access roles. For more information about types of access policies, see [Pick the correct access policy and role for your users](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewaccess_roles).

The access policies that you assign users vary depending on what you want your users to be able to do. You can find more information about what roles authorize which types of actions on the [User access reference page](https://cloud.ibm.com/docs/containers?topic=containers-access_reference) or in the following table's links. For steps to assign policies, see [Granting users access to your cluster through IBM Cloud IAM](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).



Types of roles you might assign to meet different use cases.

 Use case Example roles and scope
These certificates are never shared across clusters or across Kubernetes master components.

Need to revoke existing certificates and create new certificates for your cluster? Check out [Rotating CA certificates in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-securitycert-rotate).

Connectivity to worker nodes
: Although Kubernetes secures the communication between the master and worker nodes by using the https protocol, no authentication is provided on the worker node by default. To secure this communication, IBM Cloud Kubernetes Service automatically sets up an Konnectivity connection between the Kubernetes master and the worker node when the cluster is created.

Fine-grained access control
: As the account administrator you can [grant access to other users for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-usersusers) by using IBM Cloud Identity and Access Management (IAM). IBM Cloud IAM provides secure authentication with the IBM Cloud platform, IBM Cloud Kubernetes Service, and all the resources in your account. Setting up proper user roles and permissions is key to limiting who can access your resources and to limiting the damage that a user can do when legitimate permissions are misused. You can select from the following pre-defined user roles that determine the set of actions that the user can perform:



* Platform access roles: Determine the cluster and worker node management-related actions that a user can perform in IBM Cloud Kubernetes Service.
* Service access roles: Determine the [Kubernetes RBAC role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) that is assigned to the user and the actions that a user can run against the Kubernetes API server. With RBAC roles, users can create Kubernetes resources, such as app deployments, namespaces, or configmaps.
For more information on granting access in IAM to the KMS provider, see the [Key Protect user access documentation](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-access) or [Hyper Protect Crypto Services user access documentation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessplatform-mgmt-roles).



* For example, to create an instance and root key, you need at least the Editor platform and Writer service access roles for your KMS provider.
* If you plan to use an existing KMS instance and root key, you need at least the Viewer platform and Reader service access roles for your KMS provider.



* An additional Reader[service-to-service authorization policy](https://cloud.ibm.com/docs/account?topic=account-serviceauth) between IBM Cloud Kubernetes Service 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/containers?topic=containers-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/containers?topic=containers-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 ks kms instance ls
3. Get the ID of the root key that you previously created.
[Create an IAM service policy](https://cloud.ibm.com/docs/cli/reference/ibmcloud?topic=cli-ibmcloud_commands_iamibmcloud_iam_service_policy_create) to grant your service ID access to your Key Protect instance. The following command grants your service ID Reader access to your Key Protect instance. The Reader access role is the minimum service access role that your service ID must have to retrieve Key Protect keys. For more information, see [Managing user access for Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-access).

ibmcloud iam service-policy-create <service_ID_name> --roles Reader --service-name kms --service-instance <service_instance_GUID>
9. Create another IAM service access policy to give your service ID access to your cluster. The following command grants the Viewer platform access role and the Writer service access role to your service ID for your cluster. You can retrieve your cluster ID by running ibmcloud oc cluster get <cluster_name>.

ibmcloud iam service-policy-create <service_ID_name> --roles Writer,Viewer --service-name containers-kubernetes --service-instance <cluster_ID>
10. If you already have the ibmcloud-block-storage-plugin Helm chart installed, you must remove the Helm chart and install a new version.

If you installed the plug-in without using Helm, you must manually remove the block storage plug-in deployment and all associated resources before installing a new version.

helm uninstall <name> <namespace>
11. Install the ibmcloud-block-storage-plugin Helm chart.

helm install <name> iks-charts/ibmcloud-block-storage-plugin
12. Create an ibm-block-secrets namespace.

oc create ns ibm-block-secrets
13. Create a role binding in the ibm-block-secrets namespace for the block storage plug-in.
You don't have to enable encryption at the cluster level, but you might want to so that you manage the encryption of cluster secrets.
2. Make sure that you have [service authorization policies in IBM Cloud IAM](https://cloud.ibm.com/iam/authorizations), created under the account where the KMS instance resides, with the following details:



* Required service access policy for Kubernetes Service 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 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.





IBM Cloud Kubernetes Service 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.