vania-janet/multiturn-rag-retrieval-data huggingface dataset:
This setup is called a [multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmz-clusters) and ensures that your app is accessible, even if a worker node or an entire zone is not available.

To protect against an entire region failure, create [multiple clusters and spread them across IBM Cloud regions](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmultiple-clusters-glb). By setting up a network load balancer (NLB) for your clusters, you can achieve cross-region load balancing and cross-region networking for your clusters.

If you have data that must be available, even if an outage occurs, make sure to store your data on [persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan).

For more information about how to achieve high availability for your cluster, see [High availability for Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-haha).
* What options do I have to secure my cluster?

You can use built-in security features in Red Hat OpenShift on IBM Cloud 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 Red Hat OpenShift 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 Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-securitysecurity).
* What access policies do I give my cluster users?
: You can now specify up to five security groups to attach to workers when you create a VPC cluster. For more information, see [Adding VPC security groups to clusters and worker pools during create time](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uivpc-sg-cluster-workers).





 27 April 2022 

New! Red Hat OpenShift on IBM Cloud 4.10
: You can create or [update clusters to version 4.10](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_410). With Red Hat OpenShift on IBM Cloud version 4.10, you get the latest features, as well as component updates on Red Hat OpenShift on IBM Cloud.

Master fix pack update
: Red Hat OpenShift on IBM Cloud [4.10.9_1515_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_410).

Worker node fix pack update
: Red Hat OpenShift on IBM Cloud [4.10.10_1516_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_410).





 26 April 2022 

CLI change log update
: The [CLI change log](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog) is updated for version 1.0.403.





 25 April 2022 

Worker node fix pack
1. From the [IBM Cloud console](https://cloud.ibm.com/) menu bar, click Manage > Access (IAM).
2. From the Users tab, click the user that you want to assign permissions.
3. Click Access policies > Assign access +.
4. Click Account management.
5. From the What type of access do you want to assign? drop-down menu, select License and Entitlement.
6. Select at least the Editor platform access role, then click Add.



3. [Assign the Cloud Pak entitlement to your IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-software-license).
4. Continue to [create the Cloud Pak instance](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_cloud_paksoc_cloud_paks_add).







 FAQs for Cloud Pak on Red Hat OpenShift on IBM Cloud 

Review frequently asked questions for IBM Cloud Paks on Red Hat OpenShift on IBM Cloud clusters. For questions about Cloud Paks that run on other distributions such as on-premises, Red Hat OpenShift Dedicated, or OpenShift Container Platform on different cloud providers, consult those cloud providers' documentation.



 How do I install a Cloud Pak in my Red Hat OpenShift on IBM Cloud cluster? How do I access it later? 

Cloud Paks are integrated with the IBM Cloud catalog so that you can quickly configure and install the all the Cloud Pak components into an existing or new Red Hat OpenShift cluster. When you install the Cloud Pak, the Cloud Pak is provisioned with [Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started) and a Schematics workspace is created for you. You can use the workspace later to access information about your Cloud Pak installation. You access your Cloud Pak services from the Cloud Pak URL.
Locations 

You can deploy Red Hat® OpenShift® on IBM Cloud® clusters worldwide. When you create a cluster, its resources remain in the location that you deploy the cluster to. To work with your cluster, you can access the service via a global API endpoint.

Zoom

![Red Hat OpenShift on IBM Cloud locations](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/locations.svg)

Figure 1. Red Hat OpenShift on IBM Cloud locations

This image is an artistic representation and does not reflect actual political or geographic boundaries.



 Red Hat OpenShift on IBM Cloud locations 

IBM Cloud resources are organized into a hierarchy of geographic locations. Red Hat OpenShift on IBM Cloud is available in a subset of these locations, including worldwide multizone regions and single zone regions. Other IBM Cloud services might be available globally or within a specific location.

ibmcloud oc locations



 How locations are organized 

The following image is used as an example to explain how Red Hat OpenShift on IBM Cloud locations are organized. For more information, see [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations).

Zoom

![Organization of Red Hat OpenShift on IBM Cloud locations](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_regions_hierarchy.png)

Figure 1. Organization of Red Hat OpenShift on IBM Cloud locations



Organization of Red Hat OpenShift on IBM Cloud locations.

 Type Example Description 

 Geography North America (na) An organizational grouping that is based on geographic continents. 
 Country Canada (ca) The location's country within the geography. 
 Metro For example, Dallas (dal). The name of a city where 1 or more data centers are located.
The Red Hat OpenShift on IBM Cloud pods that are running the Elasticsearch, Kibana, and Fluentd components are assigned to a worker pool that is dedicated to logging. A dedicated worker pool prevents logging operations from stealing resources from pods that are running other applications. Worker pools are not shown in the diagram.

Instances of the Elasticsearch server are configured to run in all three of the region's zones. The Elasticsearch cluster is configured to replicate data, which is stored in shards, to a second server in the cluster.

The logging stack that is running in each VPC can also be used to collect application logs from virtual server instances that are using Fluentd. You can collect logs from virtual server instances by using [Fluentd's Elasticsearch plug-in](https://docs.fluentd.org/output/elasticsearch) to forward logs to the logging stack that is running in the Red Hat OpenShift on IBM Cloud cluster.

When you configure Red Hat OpenShift on IBM Cloud for both operational logging and operational monitoring, the worker nodes can be shared. You can use the same worker pool for both logging and monitoring. You can use the same taint tag to steer monitoring and logging pods to the shared worker pool.

To implement your operational logging solution, you need to complete the following high-level steps:



1. Provision an instance of Red Hat OpenShift on IBM Cloud
2. Configure the worker pool in your Red Hat OpenShift on IBM Cloud cluster.
3. Install the Elasticsearch Operator within your Red Hat OpenShift on IBM Cloud cluster.
4. Install the Cluster Logging Operator within your Red Hat OpenShift on IBM Cloud cluster.
5. Create a cluster logging instance.
6. Set up virtual server instance logging with Fluentd.







 Before you begin 



* You have a [VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started) provisioned.
* Subnets are provisioned across three zones within a region.







 Step 1: Provision Red Hat® OpenShift® on IBM Cloud®
After the initial certificate rotation, certificates are renewed every 30 days. You must establish a process to approve the CSRs for every certificate rotation. According to Red Hat®, you can approve CSRs when they reach 80% of their expiration period, which is approximately 25 days into the lifespan of the CSRs.

If you do not approve CSRs in time and the certificates expire, you can recover from expired control plane certificates and get the Red Hat OpenShift cluster operational again. For more information, see [Recovering from expired control plane certificates](https://docs.openshift.com/container-platform/4.7//backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-3-expired-certs.html).





 Resizing your Red Hat OpenShift VMs post-deployment 



1. Log in to the bastion VM by using SSH.
2. Become the root user: sudo -i
3. Shut down the target VM: ssh core@<vm-ip> sudo shutdown -h 0
4. After the VM is powered off, resize the VM in vCenter Server.
5. Power on the VM.
6. In the Red Hat OpenShift console, go to Compute > Nodes and wait for the VM that was restarted to be back in a Ready state.
7. Complete the previous steps for all VMs.







 Changing the SSH key on the Red Hat OpenShift bastion VM 

The SSH key pair that is generated during installation is on the Red Hat OpenShift bastion VM. The location of the SSH key pair is displayed on the Red Hat OpenShift service details page. This SSH key was installed on all cluster VMs to allow SSH logins from the bastion without requiring a password.

It is recommended that a new SSH key pair is generated and used to replace the existing key. To generate a new SSH key pair, use the instructions in the Red Hat article about [updating an SSH key](https://access.redhat.com/solutions/4510281).
ibm-system-service-accounts Resources in the ibm-system namespace that use a service account in the namespace Same priority as kube-system namespace service accounts 
 tigera-operator-service-accounts Resources in the tigera-operator namespace that use a service account in the namespace Same priority as kube-system namespace service accounts 



You can create your own flow schema and priorities, but don't modify the default settings. Unexpected results might occur in your cluster when you modify API request priorities.

Follow the steps to review the flow schemas and priority levels set by Red Hat OpenShift on IBM Cloud.



1. List all flow schemas in your cluster, including those set by Red Hat OpenShift on IBM Cloud, and their corresponding priority levels .

oc get flowschemas
2. Review the details of a particular flow schema including which resources can make prioritized API requests, what type of API requests can be made, and what objects the requests can modify.

oc describe flowschema <flow-schema-name>





 Viewing Red Hat OpenShift on IBM Cloud created priority level configurations 

Red Hat OpenShift on IBM Cloud sets a custom priority level configuration for the apiserver-health resource.

Use the following commands to view details about the configuration.

oc get prioritylevelconfiguration apiserver-health

oc describe prioritylevelconfiguration apiserver-health
* Communication process: When you manage multiple tenants, consider setting up a communication process so that tenants know where to go when an issue with the cluster exists, or when they need more resources for their services. This communication process also includes informing your tenants about all changes in the cluster setup or planned updates.



Although single-tenant and multi-tenant clusters come with roughly the same costs, single-tenant clusters provide a higher level of isolation than the projects in a multi-tenant cluster. For better workload isolation, use single-tenant clusters.

[Kubernetes network policies](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesisolate_services) protect pods from internal network traffic. For example, if most or all pods don't require access to specific pods or services, and you want to ensure that pods by default can't access those pods or services, you can create a Kubernetes network policy to block ingress traffic to those pods or services. Kubernetes network policies can also help you enforce workload isolation between namespaces by controlling how pods and services in different namespaces can communicate.

How can I control pod permissions?
: To control pod permissions within or across projects, Red Hat OpenShift on IBM Cloud uses security context constraints (SCCs). By default, every cluster is set up with [Red Hat OpenShift SCCs](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs) and a set of [IBM-provided SCCs](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccibm_sccs) that you can assign to service accounts, pods, deployments, or projects to limit the permissions within the cluster. If you don't explicitly assign an SCC, your pods use the restricted SCC. Red Hat OpenShift SCCs are stricter than the default pod security policies in community Kubernetes clusters. You might need to modify an app that runs in a community Kubernetes cluster so that this app can run in Red Hat OpenShift.
* UI
* CLI
* API







 Protecting Red Hat OpenShift on IBM Cloud resources with context-based restrictions 

Context-based restrictions give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud® resources based on the context of access requests. Access to Red Hat OpenShift on IBM Cloud resources can be controlled with context-based restrictions and identity and access management policies.

These restrictions work with traditional IAM policies, which are based on identity, to provide an extra layer of protection. Unlike IAM policies, context-based restrictions don't assign access. Context-based restrictions check that an access request comes from an allowed context that you configure. Since both IAM access and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials. For more information, see [What are context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis).

A user must have the Administrator role on the Red Hat OpenShift on IBM Cloud service to create, update, or delete rules. And a user must have either the Editor or Administrator role on the Context-based restrictions service to create, update, or delete network zones.

Any Activity Tracker or audit log events generated come from the context-based restrictions service, and not Red Hat OpenShift on IBM Cloud. For more information, see [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor).

Attempts to access the cluster control plane, which can be restricted by using the Cluster API type, do not generate Activity Tracker or audit log events.



 How Red Hat OpenShift on IBM Cloud integrates with context-based restrictions 

You can create context-based restrictions (CBR) for Red Hat OpenShift on IBM Cloud resources or for specific APIs. With Context-based restrictions, you can protect the following resources.

Protect Red Hat OpenShift on IBM Cloud resources
Monitoring a Red Hat OpenShift cluster 

Use this tutorial to learn how to configure a Red Hat® OpenShift® cluster to forward metrics to the IBM Cloud® Monitoring service. You can monitor clusters in IBM Cloud, on-prem, and in other clouds.

To configure a cluster to forward metrics, you must install a monitoring agent onto each worker node in your Red Hat OpenShift cluster by using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/). The monitoring agent uses an access key (token) to authenticate with the IBM Cloud Monitoring instance. The monitoring agent acts as a data collector. It automatically collects metrics such as worker node CPU and worker node memory usage, HTTP traffic into and out of your containers, and data about several infrastructure components. In addition, the agent can collect custom application metrics by using either a Prometheus-compatible scraper or a StatsD facade.

Zoom

![Components overview on the IBM Cloud](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/infrastructure/images/openshift.png)

Components overview

For example, to configure your Red Hat OpenShift cluster to forward metrics to your IBM Cloud Monitoring instance, you can deploy the agent by using Helm or a script:



* [Helm](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent-deploy-openshift-helm)
* [Script](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent_openshift)



The Monitoring agent automatically collects the following types of system metrics per host:



* System hosts metrics provide information about CPU, memory, and storage usage metrics, that you can use to analyze the performance and resource utilization of all your processes.
* File and File System metrics provide information about files and file system that you can use to analyze file interactions that occur in your system.
When you create a cluster, Red Hat OpenShift on IBM Cloud automatically installs the default [Kubernetes admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) in a particular order in the Red Hat OpenShift master, which can't be changed by the user. Review the order of default admission controllers by cluster version in the [kube-apiserver component reference information](https://cloud.ibm.com/docs/containers?topic=containers-service-settingskube-apiserver).

You can [install your own admission controllers in the cluster](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/admission-webhooks) or choose an optional admission controller, such as [Portieris](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec). With Portieris, you can block container deployments from unsigned images.

If you manually installed admission controllers and you don't want to use them anymore, make sure to remove them entirely. If admission controllers are not entirely removed, they might block all actions that you want to perform on the cluster.





 What else can I do to secure my API server? 

You can restrict connections to the master nodes by enabling the private cloud service endpoint, and creating a subnet allowlist. This combination provides the greatest degree of isolation.. Note that your options for service endpoints vary based on your cluster's Red Hat OpenShift version and infrastructure provider. For more information about service endpoints, see worker-to-master and user-to-master communication in [classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworkeruser-master) and [VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-workeruser-master).
Configuring security context constraints 

With security context constraints (SCCs), you can control the actions and access that pods within your Red Hat® OpenShift® on IBM Cloud® cluster can perform. For more information about SCCs, see the [Red Hat OpenShift docs](https://docs.openshift.com/container-platform/4.11/authentication/managing-security-context-constraints.html).

Why do I set security context constraints?
: As a cluster admin, you want to control what happens in your cluster, especially actions that affect the cluster's security or readiness. Security context constraints can help you control what actions and access the pods in your container have, such as the usage of privileged containers, root namespaces, host networking and ports, volume types, host file systems, Linux permissions such as read-only or group IDs, and more.

Can I also add users or system groups to SCCs?
: For user access to your cluster resources, don't use SCCs. Instead, see [Assigning cluster access](https://cloud.ibm.com/docs/openshift?topic=openshift-users) to set IBM Cloud IAM and infrastructure permissions.
: For system groups such as system:authenticated, these groups already are assigned to SCCs. You can see which groups are assigned to an SCC by describing the SCC. If you change the SCC that a system group is assigned to, default components that belong to the system group might experience errors due to the change in permissions.

Are any SCCs set by default?
: By default, Red Hat OpenShift on IBM Cloud clusters include a standard set of [Red Hat OpenShift SCCs](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs).
After you are done testing your free cluster, you can [copy your configuration files and redeploy them to a standard cluster](https://cloud.ibm.com/docs/containers?topic=containers-update_appcopy_apps_cluster).
* What container platforms are available for my cluster?

With IBM Cloud, you can create clusters for your containerized workloads from two different container management platforms: the IBM version of community Kubernetes and Red Hat OpenShift on IBM Cloud. The container platform that you select is installed on your cluster master and worker nodes. Later, you can [update the version](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) but can't roll back to a previous version or switch to a different container platform. If you want to use multiple container platforms, create a separate cluster for each.

For more information, see [Comparison between Red Hat OpenShift and community Kubernetes clusters](https://cloud.ibm.com/docs/containers?topic=containers-cs_ovopenshift_kubernetes).

Kubernetes
: [Kubernetes](https://kubernetes.io/) is a production-grade, open source container orchestration platform that you can use to automate, scale, and manage your containerized apps that run on an Ubuntu operating system. With the [IBM Cloud Kubernetes Service version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionscs_versions), you get access to community Kubernetes API features that are considered beta or higher by the community. Kubernetes alpha features, which are subject to change, are generally not enabled by default. With Kubernetes, you can combine various resources such as secrets, deployments, and services to securely create and manage highly available, containerized apps.

Red Hat OpenShift
: Red Hat OpenShift on IBM Cloud is a Kubernetes-based platform that is designed especially to accelerate your containerized app delivery processes that run on a Red Hat Enterprise Linux 7 operating system.