vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* 3 Satellite hosts that represent the EC2 instances in AWS, attached to the location and assigned to the Satellite location control plane.
* 3 Satellite hosts that represent the EC2 instances in AWS, attached to the location, unassigned, and available to use for services like an Red Hat OpenShift on IBM Cloud cluster. If you added more than 6 hosts, the number of hosts equals the number that you specified minus the three that are assigned to the control plane.



Check out the actual [Terraform code](https://github.com/terraform-ibm-modules/terraform-ibm-satellite/releases/tag/v1.0.2) that was used to create the resources.





 Security considerations 

The AWS resources are created with relatively open security groups, and the EC2 instances are assigned public IP addresses. This might not be suitable for scenarios other than a quick proof-of-concept or a demo. Changing the security group and removing IP addresses affect the Satellite and Red Hat OpenShift operations and might make the cluster inoperable. Be aware of the following considerations:



* The AWS EC2 hosts that are in the Satellite location have public IP addresses and are accessible from the public network.
* TCP Ports 80 and 443 of the cluster nodes and control plane nodes are open for connections from any IP address. Port 443 is used for Red Hat® OpenShift® console access over HTTPS.
* Port range 30000-32767 is open for TCP/UDP connection from any IP address for Satellite internal connection and management.
* SSH access to the hosts is not available from outside, and the SSH access with root user ID is locked. However, other user accounts might be enabled for connections from within the VPC.









 Step 2: Create the Red Hat OpenShift cluster, attach the workers, and fix the DNS 



1. Inside your clone of the repository, copy the file .envrc-template to .envrc.
2. Complete each of the templated environment variables. Follow the instructions that are included within the file.
3. If you are not using direnv, type source .envrc to load .envrc into your terminal's environment.
To address your evolving needs as a financial institution, IBM continuously validates these controls with global Councils of CSOs, CTOs, and CIOs from major banks, insurance providers, and regulatory advisors.<br><br>The IBM Cloud for Financial Services profile provides you with a set of pre-configured automated goals that are mapped to the [IBM Cloud Framework for Financial Services control requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-control-requirements). The results of these tests help you validate compliance when you are using one of the [references architectures](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-reference-architecture-overview) for the IBM Cloud for Financial Services. [![Note icon](https://cloud.ibm.com/docs-content/v1/content/icons/note_icon.svg)](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-fs-change-log) 
 IBM Cloud Kubernetes Service Benchmark Validate the configuration of your IBM Cloud Red Hat OpenShift clusters. [![Note icon](https://cloud.ibm.com/docs-content/v1/content/icons/note_icon.svg)](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-iks-profile) 
 IBM Cloud Security Best Practices Controls Secure your resources to meet industry and IBM Cloud best practices. [![Note icon](https://cloud.ibm.com/docs-content/v1/content/icons/note_icon.svg)](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-ibm-sec-best-practices-change-log) 
 Red Hat OpenShift Kubernetes OCP4 profile Validate the configuration of your IBM Cloud Red Hat OpenShift clusters. [!
Encrypt data with IBM Key Protect You can [set up IBM Key Protect encryption keys](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_encryption) that are secured by FIPS 140-2 Level 2 certified cloud-based hardware security modules (HSMs) to protect the data in your volumes. You can choose between using one encryption key to encrypt all your volumes in a cluster or using one encryption key for each volume. Portworx uses this key to encrypt data at rest and during transit when data is sent to a different worker node. 
 Built-in snapshots and cloud backups You can save the current state of a volume and its data by creating a [Portworx snapshot](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-snapshots/). Snapshots can be stored on your local Portworx cluster or in the cloud. 
 Integrated monitoring You can view the health of your Portworx cluster, including the number of available storage nodes, volumes and available capacity, and analyze your data in [Prometheus, Grafana, or Kibana](https://docs.portworx.com/install-with-other/operate-and-maintain/monitoring/). 







 Integration with Red Hat OpenShift on IBM Cloud 

If you have a classic Red Hat OpenShift on IBM Cloud cluster, you can choose worker node flavors that are optimized for SDS usage and that come with one or more raw, unformatted, and unmounted local disks that you can use to store your data. Portworx offers best performance when you use [SDS worker node machines](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds) that come with 10Gbps network speed. However, you can install Portworx on non-SDS worker node flavors in classic clusters, but you might not get the performance benefits that your app requires.
* OwnerReferencesPermissionEnforcement
* PodTolerationRestriction
* openshift.io/JenkinsBootstrapper
* openshift.io/BuildConfigSecretInjector
* openshift.io/ImageLimitRange
* openshift.io/RestrictedEndpointsAdmission
* openshift.io/ImagePolicy
* openshift.io/IngressAdmission
* openshift.io/ClusterResourceQuota
* MutatingAdmissionWebhook
* ValidatingAdmissionWebhook



: 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 from the optional admission controllers that Red Hat OpenShift on IBM Cloud provides. Container image security enforcement: Install [Portieris](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec) to 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 aren't entirely removed, they might block all actions that you want to perform on the cluster.





 Red Hat OpenShift version 4 worker node components 

Review the following components in the customer-managed worker nodes of your Red Hat OpenShift on IBM Cloud cluster.

These components run on your worker nodes because you are able to use them with the workloads that you deploy to your cluster. For example, your apps might use an operator from the OperatorHub that runs a container from an image in the internal registry. You are responsible for your usage of these components, but IBM provides updates for them in the worker node patch updates that you choose to apply.

In OpenShift Container Platform 4, many components are configured by a corresponding operator for ease of management. The following table discusses these operators and components together, to focus on the main functionality the component provides to the cluster.

Single tenancy
: [Master components](https://cloud.ibm.com/docs/openshift?topic=openshift-service-architectureservice-architecture-4-master), including the API server and etcd, have three replicas and are spread across zones for even higher availability. Masters include the same components as described in the Classic cluster architecture for version 4 clusters. The master and all the master components are dedicated only to you, and are not shared with other IBM customers.

Worker node
: With Red Hat OpenShift on IBM Cloud, the virtual machines that your cluster manages are instances that are called worker nodes. These worker nodes virtual machines and all the worker node components are dedicated to you only and are not shared with other IBM customers. However, the underlying hardware is shared with other IBM customers. For more information, see [Virtual machines](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesvm). You manage the worker nodes through the automation tools that are provided by Red Hat OpenShift on IBM Cloud, such as the API, CLI, or console. Unlike classic clusters, you don't see VPC compute worker nodes in your infrastructure portal or separate infrastructure bill, but instead manage all maintenance and billing activity for the worker nodes from Red Hat OpenShift on IBM Cloud.
: Worker nodes include the same [components](https://cloud.ibm.com/docs/openshift?topic=openshift-service-architectureservice-architecture-4-workers) as described in the Classic cluster architecture for version 4 clusters. Red Hat OpenShift on IBM Cloud worker nodes run on the Red Hat Enterprise Linux 7 operating system.
: When you run oc get nodes, you might notice that the ROLES of your worker nodes are marked as both master,worker. These nodes are worker nodes in IBM Cloud, and don't include the master components that are managed by IBM. Instead, these nodes are marked as master because they run OpenShift Container Platform components that are required to set up and manage default resources within the cluster, such as the OperatorHub and internal registry.

Cluster networking
Ensure that the Red Hat OpenShift PKI certificate file permissions are set to 644 or more restrictive Kubernetes > Red Hat OpenShift 
 1.1.21 Ensure that the Kubernetes PKI key file permissions are set to 600 Ensure that the Red Hat OpenShift PKI key file permissions are set to 600 Kubernetes > Red Hat OpenShift 
 1.2.4 Ensure that the --kubelet-https option is set to true Use https for kubelet connections. No option specified for Red Hat OpenShift. 
 1.2.5 Ensure that the --kubelet-client-certificate and --kubelet-client-key options are set as appropriate. Ensure that the kubelet uses certificates to authenticate No option specified for Red Hat OpenShift. 
 1.2.6 Ensure that the --kubelet-certificate-authority option is set as appropriate. Verify that the kubelet certificate authority is set as appropriate No option specified for Red Hat OpenShift. 
 1.2.8 Ensure that the --authorization-mode option includes Node. Verify that the Node authorizer is enabled No option specified for Red Hat OpenShift. 
 1.2.9 Ensure that the --authorization-mode option includes RBAC. Verify that RBAC is enabled No option specified for Red Hat OpenShift. 
 4.1.5 Ensure that the kubelet.conf file permissions are set to 644 or more restrictive. Ensure that the --kubeconfig kubelet.conf file permissions are set to 644 or more restrictive. Different wording for the same approach. 
 4.1.6 Ensure that the kubelet.conf file ownership is set to root:root. Ensure that the --kubeconfig kubelet.conf file ownership is set to root:root. Different wording for the same approach. 
 4.1.9 Ensure that the kubelet configuration file has permissions set to 644 or more restrictive. Ensure that the kubelet --config configuration file has permissions set to 644 or more restrictive. Different wording for the same approach.
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. For more information, see [Configuring security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc).

What else can I do to protect my container?
: Limit the number of privileged containers. Containers run as a separate Linux process on the compute host that is isolated from other processes. Although users have root access inside the container, the permissions of this user are limited outside the container to protect other Linux processes, the host file system, and host devices. Some apps require access to the host file system or advanced permissions to run properly. You can run containers in privileged mode to allow the container the same access as the processes running on the compute host.
: Keep in mind that privileged containers can cause huge damage to the cluster and the underlying compute host if they become compromised. Try to limit the number of containers that run in privileged mode and consider changing the configuration for your app so that the app can run without advanced permissions.

If you want to block privileged containers from running in your cluster, consider setting up custom [security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scccustomize_sccs).

Apply OS security settings to pods
: Red Hat OpenShift [4.4.26_1521_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4426_1521), [4.3.38_1542_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4338_1542), and [3.11.286_1570_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311286_1570).





 8 October 2020 

Ingress ALB change log
: Updated the [Kubernetes Ingress image build to 0.35.0_474_iks](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelog0_35_0).





 6 October 2020 

CLI change log
: Updated the Red Hat OpenShift on IBM Cloud CLI plug-in change log page for the [release of version 1.0.178](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog10).

Ingress secret expiration synchronization
: Added a troubleshooting topic for when Ingress secret expiration dates are out of sync or are not updated.

Internal Red Hat OpenShift container image registry
: Added a troubleshooting topic for when you [can't push images to the internal registry from outside the VPC network](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-app-ocr-vpc-push).





 1 October 2020 

Default version
: The default version for clusters is now 4.4.

Ingress ALB change log
infra_count Enter the number of infrastructure nodes that you want to create. Infrastructure nodes are used to run infrastructure-related pods, such as router or registry pods. 1 
 master_count Enter the number of master nodes that you want to create. The master runs the API server, controller manager server, and etcd database instance. n/a 
 pool_id The Red Hat pool ID that is linked to the subscription that you set up with Red Hat. Do not enter this information here. Instead, follow the steps in [Lesson 3](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-redhatdeploy_openshift) to retrieve your pool ID and provide the pool ID during the OpenShift installation. n/a 
 rhn_password The [Red Hat Network password](https://access.redhat.com/solutions/253273)![External link icon](https://cloud.ibm.com/docs-content/v1/content/4cd6263f39a034d265ddb4b0a5e6d50c55d13ee8/ibm-cloud-provider-for-terraform/icons/launch-glyph.svg) to access the OpenShift project. You can enter this information here or provide it as part of your OpenShift deployment in [Lesson 2](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-redhatprovision_infrastructure). n/a
They can easily deploy the research app to Frankfurt clusters to comply with the local European regulation. They also deploy the app within the United States clusters to ensure availability and recovery locally. They also spread the research workload across multizone clusters in Frankfurt to ensure that the European app is available and also balances the workload efficiently. Because researchers are uploading sensitive data with the research-sharing app, the app’s clusters are hosted in regions where stricter regulations apply.

Developers focus on domain problems, by using existing tools: Instead of writing unique ML code, ML logic is snapped into apps, by binding IBM Cloud services to clusters. Developers are also freed up from infrastructure management tasks because IBM takes care of Kubernetes and infrastructure upgrades, security, and more.

Compute, storage, and apps run in public cloud with secure access to research data across the globe, as warranted. Compute in clusters is tamper-proof and isolated to bare metal.

Technical solution:



* Red Hat OpenShift on IBM Cloud
* IBM Cloud® Functions
* IBM Cloudant
* IBM® Secure Gateway for IBM Cloud®





 Step 1: Containerize apps by using microservices 



* Create a Node.js app or deploy an example.
* Structure apps into a set of cooperative microservices within Red Hat OpenShift on IBM Cloud based on functional areas of the app and its dependencies.
* Deploy research apps to containers in Red Hat OpenShift on IBM Cloud.
* Provide standardized DevOps dashboards through Kubernetes.
* Enable scaling compute resources for batch and other research workloads that run infrequently.
* Use IBM® Secure Gateway for IBM Cloud® to maintain secure connections to existing on-premises databases.







 Step 2: Use secure and performance driven compute 



* ML apps that require higher-performing compute are hosted on Red Hat OpenShift on IBM Cloud on Bare Metal. This ML cluster is centralized, so each regional cluster doesn't have the expense of bare metal workers; Kubernetes deployments are easier too.
* Vulnerability Advisor provides image, policy, container, and packaging scanning vulnerability scanning.







 Step 3: Ensure global availability
For more information, about the description of ibm_container_worker_pool_zone_attachment argument reference such as public_vlan_id, private_vlan_id values, refer to [registry documentation of ibm_container_worker_pool_zone_attachment](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/container_worker_pool_zone_attachmentargument-reference).
7. Update the Terraform on IBM Cloud state file. When you run this command, Terraform on IBM Cloud automatically verifies that all the resources in the state file exist in IBM Cloud. Missing resources are removed from the state file.

terraform refresh







 What's next? 

Great job! You successfully created a multizone IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud cluster, added a worker pool, and removed the default worker pool from your cluster. Explore the learning paths for administrators in [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-learning-path-admin) and [Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-learning-path-admin) to learn how you can further protect your cluster, add persistent storage, set up integrations, add logging and monitoring capabilities, and more.
IBM Cloud Satellite implements controls commensurate with the following security standards:



* International Organization for Standardization (ISO 27001, ISO 27017, ISO 27018)







 What IBM Cloud services can I use with Satellite? 

For a complete list of IBM Cloud services that you can deploy to your Satellite location, see Satellite-enabled IBM Cloud services.

Keep in mind that each service might:



* Be available for Satellite locations that are managed from select IBM Cloud regions only, such as from Washington, DC or London.
* Have its own [limitations for use in Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-requirementsreqs-services).







 What managed add-ons can I use with Red Hat OpenShift clusters in my Satellite location? 

See the [Red Hat OpenShift on IBM Cloud documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-managed-addonsaddons-satellite).
Configure monitoring for a VPC virtual server instance.
6. Set up a custom Grafana dashboard.







 Before you begin 



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







 Step 1: Provision Red Hat® OpenShift® on IBM Cloud® 

To capture metrics from workloads running outside of Red Hat OpenShift on IBM Cloud (such as a virtual server instance), you need to provision an instance of Red Hat OpenShift on IBM Cloud if you don't already have one.



1. [Provision Red Hat® OpenShift® on IBM Cloud®](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_tutorial) within the workload VPC where you plan to install the monitoring service. Use the following configuration:





* Red Hat OpenShift on IBM Cloud version: 4.6.x
* Worker zones: User defined subnet in each zone of the region
* Worker nodes per zone: 1
* Flavor: mx2.4x32 - 4 vCPU, 32 GB Memory
* Master service endpoint: Private endpoint only







 Step 2: Provision a Red Hat OpenShift on IBM Cloud worker pool 



1. Use a separate worker pool for the monitoring stack to keep the monitoring stack resources distinct from other workload resources. [Provision a new worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersvpc_pools) with the following configuration:



* Worker zones: User defined subnet in each zone of the region
* Worker nodes per zone: 1
* Flavor: mx2.4x32 - 4 vCPU, 32 GB Memory



2. After provisioning completes, [access the Red Hat OpenShift on IBM Cloud cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clustervpc_private_se).
3. Taint the worker pool.
By using this TLS tunnel, you can securely access IBM Cloud services in your location and use them with the same security and compliance standards as in IBM Cloud. For more information, see [Connecting Satellite locations with services outside of locations by using endpoints](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloud). 
 Control and monitor network traffic to services. With Satellite Link, you can control network access to apps, services, and servers that run in IBM Cloud, public cloud providers, or in your on-premises data center. Configure these apps, services, and servers as sources for your Satellite endpoints. All network traffic that is sent through an endpoint is automatically captured and can be reviewed by the user. 
 Consistently deploy Kubernetes resources across multiple locations. Use a single dashboard to manage the deployment of Kubernetes resources across cloud, on-premises, and edge environments with Satellite Config and gain global visibility into your apps and Kubernetes operations. For more information, see [Deploying Kubernetes resources across clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig). 
 Centralize your monitoring and logging. IBM Cloud Satellite is integrated with IBM Cloud Monitoring, IBM Log Analysis, and IBM Cloud Activity Tracker. You can view the metrics and logs for the apps that run in your location, the IBM Cloud services that you use, or the events that happen in your location from a single location. 



For more information about Satellite, how it works and the service benefits, see the [Satellite product page](https://www.ibm.com/cloud/satellite).





 Common use cases for Satellite 

This use case is applicable to all industries.



 Deploying Red Hat OpenShift environment as a managed service wherever it is needed 

Frequent version upgrades and function modifications that require Kubernetes and Red Hat OpenShift skills are performed remotely through IBM Cloud managed services. The same services can be deployed wherever they are needed to process data close to its source to reduce latency.

Pain points:
: It is hard to secure and maintain skills for running Red Hat OpenShift internally.