vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Your responsibilities with using Red Hat OpenShift on IBM Cloud 

Learn about cluster management responsibilities that you have when you use Red Hat® OpenShift® on IBM Cloud®. For overall terms of use, see [Cloud Services terms](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-termsterms).



 Overview of shared responsibilities 

Red Hat OpenShift on IBM Cloud is a managed service in the [IBM Cloud shared responsibility model](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-shared-responsibilities). Review the following table of who is responsible for particular cloud resources when using Red Hat OpenShift on IBM Cloud. Then, you can view more granular tasks for shared responsibilities in [Tasks for shared responsibilities by area](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_ikstask-responsibilities).

If you use other IBM Cloud products such as Object Storage, responsibilities that are marked as yours in the following table, such as disaster recovery for Data, might be IBM's or shared. Consult those products' documentation for your responsibilities.



Table 1. Responsibilities by resource.

 Resource [Incident and operations management](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_iksincident-and-ops) [Change management](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_ikschange-management) [Identity and access management](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_iksiam-responsibilities) [Security and regulation compliance](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_ikssecurity-compliance) [Disaster Recovery](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_iksdisaster-recovery)
Ensure that workload hosts have outbound access to IBM Cloud public endpoints. For more information, see [Accessing external resources](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-connectivity-to-external).







 (Optional) Configure virtual network flow rules within Red Hat OpenShift on IBM Cloud 



1. Configure virtual network flow rules within Red Hat OpenShift on IBM Cloud. In addition to the network flow controls implemented within the IaaS layer of the Satellite location, you can use virtual networking features of Red Hat OpenShift on IBM Cloud to control network flows within and into your cluster. You can use [Kubernetes network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-kube-policies) or [Calico network policies](https://projectcalico.docs.tigera.io/security/protect-hosts) to define network flow restrictions for each workload deployed on your Red Hat OpenShift on IBM Cloud cluster.







 Related controls in IBM Cloud Framework for Financial Services 

The following IBM Cloud Framework for Financial Services controls below are most related to this guidance. However, in addition to following the guidance here, do your own due diligence to ensure you meet the requirements.



Table 1. Related controls in IBM Cloud Framework for Financial Services

 Family Control 

 Access Control (AC) [AC-20 Use of External Information Systems](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-ac-20) 
 Security Assessment and Authorization (CA) [CA-3 System Interconnections](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-ca-3)
Multizone region (MZR) - IBM Cloud Kubernetes Service and Red Hat OpenShift migration (Experimental)
: Experimental users can now discover and migrate their IBM Cloud Kubernetes Service or Red Hat OpenShift clusters from multiple data centers to a multizone region (MZR) in VPC. This is an experimental feature that is available for evaluation and testing purposes and might change without notice. There are no warranties, SLAs, or support provided, and experimental features are not intended for production use. For more information, see [Considerations for IBM Cloud Kubernetes Service and Red Hat OpenShift migration](https://cloud.ibm.com/docs/wanclouds-vpc-plus?topic=wanclouds-vpc-plus-migration-considerationskubernetes-migration).





 December 2021 

Single availability zone (SAZ) - IBM Cloud Kubernetes Service and Red Hat OpenShift migration (Experimental)
: Experimental users can now discover and migrate their IBM Cloud Kubernetes Service or Red Hat OpenShift clusters in single data center to a single availability zone (SAZ) in VPC. This is an experimental feature that is available for evaluation and testing purposes and might change without notice. There are no warranties, SLAs, or support provided, and experimental features are not intended for production use. For more information, see [Considerations for IBM Cloud Kubernetes Service and Red Hat OpenShift migration](https://cloud.ibm.com/docs/wanclouds-vpc-plus?topic=wanclouds-vpc-plus-migration-considerationskubernetes-migration).





 June 2021 

Dedicated hosts
: When you migrate a classic virtual server instance from a dedicated host to IBM Cloud VPC, you now have the option to continue to migrate it as a single-tenant model (dedicated host) or change it to a shared-tenant model (public). For more information, see [Dedicated hosts](https://cloud.ibm.com/docs/wanclouds-vpc-plus?topic=wanclouds-vpc-plus-migration-considerationsdedicated-hosts).

Data migration for block and file storage
About Ingress 

This information is for clusters that run Red Hat OpenShift version 4 only.

Ingress is a service that balances network traffic workloads in your cluster by forwarding public or private requests to your apps. You can use Ingress to expose multiple app services to the public or to a private network by using a unique public or private domain.

In your cluster, the Red Hat OpenShift Ingress controller is a layer 7 load balancer which implements an HAProxy Ingress controller. A layer 4 LoadBalancer service exposes the Ingress controller so that the Ingress controller can receive external requests that come into your cluster. The Ingress controller then forwards requests to app pods in your cluster based on distinguishing layer 7 protocol characteristics, such as headers.



 What are the components of Ingress? 

In clusters that run Red Hat OpenShift version 4, Ingress consists of three components: an Ingress operator, an Ingress controller, and Route resources.



 Ingress operator 

The [Red Hat OpenShift Ingress operator](https://docs.openshift.com/container-platform/4.11/networking/ingress-operator.html) implements routing rules that are applied to all incoming traffic for the apps in your cluster.

Ingress controllers are managed by the Ingress operator. During cluster creation, the default Ingress controller is registered with the default Ingress subdomain for your cluster in the format <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. When you register your app with this subdomain by creating an Route resource, the Ingress controller ensures that requests to your app through this subdomain are properly proxied to your app pods. To see the default Ingress controller in your cluster, run oc describe ingresscontroller/default -n openshift-ingress-operator.

If you want to register your app with a different domain, you can [create a custom Ingress controller](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4&interface=uiingress-controller) that implements routing rules for a custom domain instead.





 Ingress controller
The EFK stack that is deployed in Red Hat OpenShift on IBM Cloud can also be used to aggregate application and infrastructure logs from virtual server instances. The following instructions describe how to install and configure Fluentd on a virtual server instance so that it can forward its logs to an Elasticsearch cluster.



 Preparing the Elasticsearch cluster to receive logs 

Fluentd should use a Red Hat OpenShift on IBM Cloud private endpoint when sending log data to the Elasticsearch cluster.

To enable the Elasticsearch cluster to receive logs from a Fluentd client running outside of the Red Hat OpenShift on IBM Cloud cluster, you must create a route to the Elasticsearch service.



1. Navigate to the Red Hat OpenShift on IBM Cloud web console.
2. Select Networking → Routes.
3. Select Project openshift-logging
4. Click Create Route.



1. Select an intuitive name, such as elasticsearch.
2. Select Elasticsearch for the service.
3. Select 9200 → restapi (TCP) as the Target Port
4. Select Secure route.
5. Select Re-encrypt for TLS Termination.
6. Select None for Insecure Traffic.
7. Set the Destination CA Certificate to the ElasticSearch CA ([reference](https://docs.openshift.com/container-platform/4.1/logging/config/efk-logging-elasticsearch.htmlefk-logging-elasticsearch-exposing_efk-logging-elasticsearch)). You can retrieve the certificate with the following command:

$ oc extract secret/elasticsearch --to=. --keys=admin-ca -n openshift-logging
8. The other fields, including the other certificate and key fields, can be left blank.



5. Click Create.
6. After the route is created, note the hostname for the route. You can find the hostname at following path: Networking → Routes → Elasticsearch.
Service instance ibm_service_instance The service instance segment identifies the instance the metric is associated with 
 Service instance name ibm_service_instance_name The user-provided name of the service instance, which might not be unique across regions in the account 











 Setting up monitoring for clusters 

You cannot currently use the Red Hat OpenShift on IBM Cloud console or the observability plug-in CLI (ibmcloud ob) to enable monitoring for Satellite clusters. You must manually deploy monitoring agents to your cluster to forward metrics to Monitoring.

To set up monitoring for Red Hat OpenShift clusters that run in your Satellite location, see [Deploying a monitoring agent in a Red Hat OpenShift cluster](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent_openshift).
: LocalStorageCapacityIsolation=false

4.4
: ExperimentalCriticalPodAnnotation=true
: LocalStorageCapacityIsolation=false

4.3
: ExperimentalCriticalPodAnnotation=true
: LocalStorageCapacityIsolation=false





 Global settings 

Because Red Hat OpenShift on IBM Cloud is a managed service, many OpenShift Container Platform global settings are set up for you. You can configure some global settings, but other global settings you can only review, and any changes are overwritten. For more information, see [Comparison between clusters that run in IBM Cloud and standard OCP](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_ovcompare_ocp). You can also review the control plane components in the [Red Hat OpenShift on IBM Cloud Toolkit](https://github.com/openshift/ibm-roks-toolkit) project on GitHub.

Configurable global settings:



* Image.InternalRegistryHostname
* Image.AllowedRegistriesForImport For an example, see [Adding a private registry to the global pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_global_pull_secret).
* Build.BuildControllerConfig
* Project.RequestMessage
* Project.RequestTemplateName



Read-only custom resource definitions in the config.openshift.io resource group:



* APIServer
* Authentication
* ClusterVersion
* DNS
* FeatureGate
* Image
* Infrastructure
* Ingress
* Network
* OAuth
* Proxy
* Scheduler
The NSX Controller uses Unicast mode with virtual tunnel endpoints (VTEPS) to provide MAC learning and other functions to allow VXLAN Broadcast, Unknown unicast, and Multicast (BUM) traffic within a logical switch. The unicast mode replicates all the BUM traffic locally on the host and requires no physical network configuration outside of Layer 3 connectivity between VTEPS. NSX Controllers are deployed by the NSX Manager as a minimum set of three controller nodes, and various other nodes to support (distributed) Layer 3 routing services. All of the nodes are deployed as virtual machines and are managed by the NSX Manager on an ESX Management Cluster at IBM Cloud.





 NSX Edge 

NSX Edge provides network edge security and gateway services to isolate a virtualized network. You can install an NSX Edge either as a logical (distributed) router or as a services gateway. The NSX Edge logical (distributed) router provides East-West distributed routing with tenant IP address space and data path isolation. Virtual machines or workloads that reside on the same host on different subnets can communicate with one another without having to traverse a traditional routing interface. The NSX Edge Gateway connects isolated stub networks to shared (uplink) networks by providing common gateway services such as DHCP, VPN, NAT, dynamic routing, and Load Balancing. Common deployments of NSX Edge include in the DMZ, VPN extranets, and multi-tenant cloud environments where the NSX Edge creates virtual boundaries for each tenant.
If Private Network was selected for HCX Network Connection, a port group that is named SDDC-DPortGroup-HCX-Private is created on the private Distributed Virtual Switch (DVS).
3. An HCX activation key is ordered from VMware.
4. For vCenter Server with NSX-T instances, the firewall rules and network address translation (NAT) rules are configured to allow inbound and outbound HTTPS traffic to and from the HCX Manager.
5. For vCenter Server with NSX-V instances, a pair of NSX Edge Services Gateways (ESGs) for the HCX management traffic is deployed and configured:



* Public and private uplink interfaces are configured by using the ordered subnets.
* The ESGs are configured as a pair of extra large edge appliances with High Availability (HA) enabled.
* The firewall rules and network address translation (NAT) rules are configured to allow inbound and outbound HTTPS traffic to and from the HCX Manager.
* The load balancer rules and resource pools are configured. These rules and resource pools are used to forward HCX-related inbound traffic to the appropriate virtual appliances of HCX Manager and vCenter Server (with embedded Platform Services Controller).
* An SSL certificate to encrypt the HCX-related inbound HTTPS traffic that is coming through the ESGs is applied.



The HCX management edge is dedicated to the HCX management traffic between the on-premises HCX components and the cloud-side HCX components. Do not modify the HCX management edge or use it for HCX network extensions. Instead, create separate edges for network extensions. In addition, if you use a firewall or you disable the HCX management edge communications to the private IBM management components or the internet, the HCX functions might be impacted.
6. The HCX Manager is deployed, activated, and configured:



* The HCX Manager is registered with vCenter Server.
* The HCX Manager, vCenter Server (with embedded Platform Services Controller), and NSX Manager are configured.
* The HCX Compute and Network profiles are created.



7. The hostname and IP address of the HCX Manager is registered with the DNS server of vCenter Server.
Will the Hardware Firewall protect the Virtual Machines running on my hypervisor? 

No. Portable IPs are used for the VMs in a hypervisor environment and portable IPs are not protected by the hardware firewall. A FortiGate Security Appliance is recommended.





 What are the grayed out ports in my Windows Firewall? 

IBM Cloud offers many different services that you can utilize with your server including Evault, SNMP and Nagios monitoring. These services require that our internal systems communicate with your server to some degree. The grayed out ports you see in the Exceptions list are ports open on the internal network port only. They are still blocked on the public (internet) network connection. Since the internal network is a secured network having these ports open is considered secure.

These ports generally cannot be modified; however, if you reset the firewall rules, it will clear them from the Exceptions list. Please beware that resetting the firewall rules may have an adverse affect not only on these additional services but also could cause other issues as well with your server depending on its current configuration.





 What Hardware Firewall options are available for 10Gbps servers? 

FSA 10G is the only option to support 10Gbps servers for both public and private traffic. If 10Gbps is only required on the private network (for database, backup, storage, etc), then customers can request a downgrade of only their public uplinks and order any of the Hardware Firewall products.





 What IP ranges do I allow through the firewall? 

For the list of IP addresses and IP ranges to allow through the firewall, go [here](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=cloud-infrastructure-ibm-cloud-ip-ranges).





 What VPN options are included with each firewall product? 

Not all firewalls offer VPN and not all VPN options are the same. The general options for VPN are:



* Each customer receives unlimited SSL VPN connections to our private network. These connections can be established by clicking the VPN link at the top of the page while logged into the IBM Cloud console.
* IBM Cloud also offers a basic multi-tenant IPsecVPN service.
Best practices and requirements for software as a service 

These best practices summarize some of the most important technical principles for SaaS providers based on the [control requirements](https://cloud.ibm.com/docs/framework-financial-services-controls) and implementation guidance of the IBM Cloud Framework for Financial Services. These best practices are not a replacement for the information provided in the [Control Implementation Overview templates](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutcontrol-implementation-overview-templates), which are still the definitive guides to the controls and required evidence for application providers.

If you're a software provider, see [Best practices for software](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practices-software).



 1. Use an approved reference architecture 

Requirement: Deploy and manage IBM Cloud resources as defined by an approved reference architecture.

Purpose & value: The quickest path toward meeting the controls of the IBM Cloud Framework for Financial Services is to use one of the pre-defined, single-tenant reference architectures. These architectures are designed to facilitate implementing the other requirements and best practices such as network isolation, security function isolation, high availability, backup and recovery, encryption, audit logging, compliance monitoring, etc.

A key aspect of the framework is to separate user workloads from system management functionality and isolate security functions from non-security functions. One of the most important features of the reference architectures is the definition of physical and logical separation between the edge, management, and workload planes. It is your responsibility to ensure that separation stays in place.

Implementation guidance: Explore and choose one of the supported reference architectures for the IBM Cloud for Financial Services:



* [IBM Cloud® Virtual Private Cloud reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-about), with options for using one or both of:
This connection is established and operated by the IBM Cloud team and you have no direct access or control.

When this connection is established, the BGP is configured by the IBM Cloud team in the following way:



* The Power Systems Virtual Server router advertises your Power Systems Virtual Server subnets to the router in the VPC infrastructure.



* The router in the VPC infrastructure advertises only your IBM Cloud VPC subnets to the Power Systems Virtual Server router.
* The router in the VPC infrastructure filters the following networks from the BGP advertisements coming from the Power Systems Virtual Server router because these IP addresses are used by the endpoint networks: 169.254.0.0/16, 224.0.0.0/4, 166.9.0.0/16, and any IP ranges that are assigned to your IBM Cloud VPC subnets.





3. Identify the IBM Cloud VPC subnets and the IP address schema that is assigned to you when you ordered VPC services. The XCR connects to the endpoint networks by using the VPC implicit router that provides routing functions to each VPC, and allows each VPC to have access to its own copy of the IPv4 address space. The Multi-Protocol Label Switching (MPLS) VPN works with Direct Link and classic infrastructure environments. For more information, see [Network isolation, data packet flow, and the role of an implicit router in a VPC](https://www.ibm.com/cloud/architecture/content/course/advanced-networking-for-vpc/design-develop-and-deploy/). You cannot access some endpoint networks (services and infrastructure services) from your Power Systems Virtual Server subnets. The types of endpoint networks are as follows:



* Service endpoints - Allows connection to IBM Cloud services available through DNS names in the cloud.ibm.com domain and resolves to 166.9.x.x addresses.
* Infrastructure services - Allows connection to IBM Cloud services from the adn.networklayer.com domain and resolves to 161.26.0.0/16 addresses. Services that you can reach include:
where CIDR1, 2 are IP addresses of the form a.b.c.d/e



If the private endpoint is enabled by using the CLI, the next time you update the private IP allowlist, you can omit --service-endpoints private.

Switching IP allowlists disable any allowed IP address not in the new list. Applications accessing the cluster from those addresses lose access to the cluster.





 Retrieving endpoint information 

The endpoint information for your service instance is specific to the network type. Service instances with both public and private networking selected have an endpoint for each.

You can retrieve the endpoint information for the required network type by using the --service-endpoint option of the service-key-create CLI command as follows:

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





 Accessing the IBM Event Streams console 

The console continues to be accessible if private only networking is selected.







 Configuring context-based restrictions 

You can define rules that limit the network locations that connections are accepted from. For example, by network type, IP ranges, VPC, or from other services. For more information, see [What are context-based restrictions?](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis)

When context-based restrictions rules are defined against an Event Streams instance, the following rules apply:



* Admin REST API, REST Producer API, Schema Registry API, and Kafka client calls are under the scope of context-based restrictions rules that are created against an Event Streams instance.
* The Administration functions for the service instance itself (for example the IBM Cloud CLI service-instance-create, service-instance-delete or service-instance-update commands, or equivalent) are not under the scope of the context-based restrictions rules that are created against an Event Streams instance.





 Managing context-based restrictions settings 

Creating context-based restrictions rules is a two-step process:



1. Create a network zone with list of allowed IP addresses, allowed VPCs, or reference a service.