vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Set your command line context for the cluster by using the Link endpoint and download the TLS certificates and permission files for the administrator. For more information, see the [CLI documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_config).

ibmcloud oc cluster config -c <cluster_name_or_ID> --endpoint link --admin







 Accessing clusters from the public network 

If your hosts have public network connectivity, and you want to access your cluster from your local machine without being connected to your hosts' private network, you can optionally update your cluster's subdomain and location's DNS record to use the public IP addresses of your hosts.

For most location setups, the private IP addresses of your hosts are registered for the location's DNS record so that you can access your cluster only if you are connected to your cloud provider's private network.

For example, if you use Amazon Web Services, Google Cloud Platform, or Microsoft Azure hosts, or if your hosts' default network interface is private, your location's DNS record is accessible only on the private network.

To run kubectl or oc commands against your cluster or access the Red Hat OpenShift web console, you must be connected to your hosts' private network, such as through VPN access. However, if you want to access your cluster from the public network, such as to test access to your cluster from your local machine, you can change the DNS records for your location and cluster subdomains to use your hosts' public IPs instead.

Making your location and cluster subdomains available outside of your hosts' private network to your authorized cluster users is not recommended for production-level workloads.



1. Review the location subdomains and check the Records for the private IP addresses of the hosts that are registered in the DNS for the subdomain.

ibmcloud sat location dns ls --location <location_name_or_ID>
2. Retrieve the matching public IP addresses of your hosts.

ibmcloud sat host ls --location <location_name_or_ID>
3.
: Specify the IBM Cloud zone ID that you chose earlier and that you want to use to create your cluster.

--flavor <flavor>
: Specify the flavor for your worker node that you chose earlier.

--hardware <shared_or_dedicated>
: Specify with the level of hardware isolation for your worker node. Use dedicated to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. This value is optional for VM standard clusters. For bare metal flavors, specify dedicated.

--public-vlan <public_vlan_id>
: If you already have a public VLAN set up in your IBM Cloud infrastructure account for that zone, enter the ID of the public VLAN that you retrieved earlier. If you don't have a public VLAN in your account, don't specify this option. IBM Cloud Kubernetes Service automatically creates a public VLAN for you. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

--private-vlan <private_vlan_id>
: If you already have a private VLAN set up in your IBM Cloud infrastructure account for that zone, enter the ID of the private VLAN that you retrieved earlier. If you don't have a private VLAN in your account, don't specify this option. IBM Cloud Kubernetes Service automatically creates a private VLAN for you. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

--name <name>
: Specify a name for your cluster. The name must start with a letter, can contain letters, numbers, periods (.), and hyphen (-), and must be 35 characters or fewer.
ibmcloud ks ingress domain create --cluster CLUSTER [--is-default] [--domain DOMAIN] [--hostname HOSTNAME] [--ip IP] [--output OUTPUT] [-q] [--secret-namespace NAMESPACE]

-c, --cluster CLUSTER
: Required. The name or ID of the cluster where you want to create the domain.

--is-default
: Optional. Include this option to set the relevant domain as the default domain for the cluster.

--domain DOMAIN
: The domain to create or add to your cluster. This can be a domain that exists in your provider account, or a new domain.

--hostname HOSTNAME
: Optional. For VPC clusters. The hostname to register for the domain.

--ip IP
: Optional. The IP addresses to register for the domain.

--output OUTPUT
: Optional: Prints the command output in JSON format.

--secret-namespace NAMESPACE
: Optional. The namespace that the domain TLS secret is created in. If no namespace is specified, the secret is created in the default namespace.





 Setting up domains with IBM Cloud Internet Services 

Follow the steps to create a domain with IBM Cloud Internet Services.



 Set up service-to-service authorization 

Creating a domain with IBM Cloud Internet Services requires you to [set up service-to-service authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauth&interface=uicreate-auth) for your IBM Cloud Internet Services instance. Set the source service as Kubernetes Service, and the target as Internet services. Assign the Manager role.





 Create a domain 

Create a new domain, or specify an existing domain that you want to add to your cluster. To specify an existing domain, include the full domain name with the external provider zone, such as exampledomain.externalzone.com. To create a new domain, you must still include the external provider zone, but you can customize the subdomain portion, such as custom.exampledomain.externalzone.com.
Note that you cannot delete a cluster's default domain. If you want to delete the domain that is currently registered as the default, you must first [assign a different default domain](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-domainsingress-domain-manage-default).

If you delete a domain that is registered with the IBM internal provider, you cannot reuse the domain name.

For more details and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=uiingress-domain-rm).

ibmcloud oc ingress domain rm --cluster CLUSTER --domain DOMAIN





 Updating a domain's IP addresses or hostname 

You can update a domain's registered IP addresses (for classic clusters) or hostname (for VPC clusters) after the domain is created or added to the cluster. This command updates all the resources in your cluster with the specified IP addresses or hostnames and changes your app URLs.

For more information and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=uiingress-domain-update).

Note that when you add IP addresses or hostnames, you must include any IPs or hostnames that are currently registered to the domain. The domain updates with the exact values specified, so any current IP addresses or hostnames are overwritten if they are not included. For example, if 52.137.182.166 is currently registered to your domain and you want to add 52.137.182.270, you must specify --ip 52.137.182.166 --ip 52.137.182.270 in the command.

ibmcloud oc ingress domain update --cluster CLUSTER --domain DOMAIN [--hostname HOSTNAME] [--ip IP]





 Changing a cluster's default domain
* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



--service-subnet
: All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your services. The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges: - 172.17.0.0 - 172.17.255.255 - 172.21.0.0 - 172.31.255.255 - 192.168.0.0 - 192.168.254.255 - 198.18.0.0 - 198.19.255.255 Note that the pod and service subnets can't overlap.

--disable-public-service-endpoint
: Include this option in your command to create your VPC cluster with a private cloud service endpoint only. If you don't include this option, your cluster is set up with a public and a private cloud service endpoint. The service endpoint determines how your Kubernetes master and the worker nodes communicate, how your cluster access other IBM Cloud services and apps outside the cluster, and how your users connect to your cluster. For more information, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters).

--kms-account-id <KMS_acount_ID>
: Optional: Must be included if the --kms-instance-id and --crk options are provided and the KMS instance resides in an account different from the cluster's account, otherwise it can be omitted.
"value": "<namespace_name>"
}
]
}
]
}
Show more



Table 1. Understanding options for service access role policy

 Component Description 

 subjects.attributes Enter the IBM Cloud IAM details for the individual user or access group that you previously retrieved.<br><br><br><br> * For individual users, set iam_id for the name field. Enter the previously retrieved ibmUniqueId for the value field.<br> * For access groups, set access_group_id for the name field. Enter the previously retrieved ID for the value field.<br><br><br> 
 roles.role_id Choose the [IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles) that you want to assign. Possible values are:<br><br><br><br> * crn:v1:bluemix:public:iam::::serviceRole:Manager<br> * crn:v1:bluemix:public:iam::::serviceRole:Writer<br> * crn:v1:bluemix:public:iam::::serviceRole:Reader<br><br><br> 
 resources.attributes Configure the scope of the policy to your account, cluster, and namespace. Leave the "name" fields as given in the example, and enter certain "value" fields as follows.<br><br><br><br> * For "accountId": Enter your IBM Cloud account ID that you previously retrieved.<br> * For "serviceName": Leave the service name as given: containers-kubernetes.<br> * For "serviceInstance": Enter your cluster ID. For multiple clusters, separate with a comma. To get your cluster ID, run ibmcloud ks cluster ls.<br> * For "namespace": Enter a Kubernetes namespace in your cluster.
When you create the cluster, the cluster master is automatically created in your Satellite location control plane, and your worker pool is automatically assigned available hosts that match your worker node request.
11. Wait for the cluster to reach a Normal state.

If you don't have any available and matching hosts in your Satellite location, the cluster is still created but enters a Warning state. [Attach hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) to your Satellite location so that hosts can be assigned as worker nodes to the worker pool. If the hosts are not automatically assigned, you can also manually [assign Satellite hosts to your cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-assign-manual). Ensure that hosts are assigned as worker nodes in each zone of your default worker pool.
12. From the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift), verify that your cluster reaches a Normal state.
13. [Access your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat) to access the Red Hat OpenShift web console or to run oc and kubectl commands from the CLI. If you enabled Satellite Config access, you must complete this step to synchronize the permissions.

If your location hosts have private network connectivity only, or if you use Amazon Web Services, Google Cloud Platform, or Microsoft Azure hosts, you must be connected to your hosts' private network, such as through VPN access, to connect to your cluster and access the Red Hat OpenShift web console. Alternatively, if your hosts have public network connectivity, you can test access to your cluster by changing your cluster's and location's DNS records to [use your hosts' public IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clustersat_public_access).
14.
Controlling traffic with network policies 

Classic clusters

This network policy information is specific to classic clusters. For network policy information for VPC clusters, see [Controlling traffic with security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group).

Every Red Hat® OpenShift® on IBM Cloud® cluster comes with a network plug-in called Calico. Default network policies secure the public network interface of every worker node in the cluster.

You can use Calico and Kubernetes to create network policies for a cluster. With Kubernetes network policies, you can specify the network traffic that you want to allow or block to and from a pod within a cluster. To set more advanced network policies such as blocking inbound (ingress) traffic to network load balancer (NLB) services, use Calico network policies.

Kubernetes network policies
: [Kubernetes network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) specify how pods can communicate with other pods and with external endpoints. Both incoming and outgoing network traffic is allowed or blocked based on protocol, port, and source or destination IP addresses. Traffic can also be filtered based on pod and namespace labels. You can apply Kubernetes network policies by using oc commands or the Kubernetes APIs.

Calico network policies
: [Calico network policies](https://docs.tigera.io/calico/latest/reference/resources/networkpolicy) are a set of the Kubernetes network policies. You can apply Calico policies by using the calicoctl command line. Calico policies add the following features.



* Allow or block network traffic on specific network interfaces regardless of the Kubernetes pod source or destination IP address or CIDR.
* Allow or block network traffic for pods across namespaces.
* [Block inbound traffic to Kubernetes LoadBalancer or NodePort services](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesblock_ingress).
If you plan to connect your cluster to on-premises networks through IBM Cloud® Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods.
: When you choose a subnet size, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on. The subnet that you choose must be within one of the following ranges.



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. If you use custom-range subnets for your worker nodes, you must [ensure that your worker node subnets don't overlap with your cluster's pod subnet](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc-ip-range).

--service-subnet SUBNET
: All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your services. The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges.



* 172.17.0.0 - 172.17.255.255
Use a name that is unique across regions. The cluster name and the region in which the cluster is deployed form the fully qualified domain name for the Ingress subdomain. To ensure that the Ingress subdomain is unique within a region, the cluster name might be truncated and appended with a random value within the Ingress domain name.

--zone <zone>
: Specify the IBM Cloud zone where you want to create your cluster. Make sure that you use a zone that matches the metro city location that you selected when you created your VPC and that you have an existing VPC subnet for that zone. For example, if you created your VPC in the Dallas metro city, your zone must be set to us-south-1, us-south-2, or us-south-3. To list available VPC cluster zones, run ibmcloud oc zone ls --provider vpc-gen2. Note that when you select a zone outside of your country, you might require legal authorization before data can be physically stored in a foreign country.

--vpc-id <vpc_ID>
: Enter the ID of the VPC that you created earlier. To retrieve the ID of your VPC, run ibmcloud oc vpcs.

--subnet-id <subnet_ID>
: Enter the ID of the VPC subnet that you created earlier. When you create a VPC cluster from the CLI, you can initially create your cluster in one zone with one subnet only. To create a multizone cluster, [add more zones with the subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workers) that you created earlier to your cluster after the cluster is created. To list the IDs of your subnets in all resource groups, run ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone>.

--flavor <worker_flavor>
: Enter the worker node flavor that you want to use.
If the attribute is a single string instead, Contains determines whether the value that is provided is contained in the string attribute in the login message. group contains “Admins” 
 In Short notation for multiple Equal operators. Compares the value in the login message attribute with the list of potential values in this rule. Boolean or numbers are converted to a string before comparison. jobRole in [“Manager”,”Director”,”Team-Lead”] 







 Example 

The following table includes values for each of the fields for a dynamic rule or a trusted profile condition. In this example, users who are identified as managers within the federated IdP are mapped to an IBM Cloud access group or trusted profile that has specific access set for only managers.



Table 2. Example values

 Field Value 

 Name Manager 
 Identity provider https://idp.example.org/SAML2 
 Session duration in hours 12 
 Allow users when (attribute name) isManager 
 Comparator Equals 
 Value true 







 Compute resource attribute names 

To establish trust with a compute resource in a trusted profile, you can use the IBM Cloud console, IBM Cloud CLI, or the IAM API. If you select All service resources and add conditions to filter the compute resource instances that can apply the profile, the conditions are built based on the following resource attributes.



 Kubernetes and Red Hat OpenShift attribute names 



Table 3. Kubernetes and Red Hat OpenShift attribute names

 IBM Cloud console name CLI and API name Description 

 Resource group ID resource_group_id The ID of the resource group that contains this cluster. You can identify the resource group of a cluster by using its overview page in the IBM Cloud Console. 
 Resource group name resource_group_name The name of the resource group that contains this cluster. 
 Service instance service_instance The ID of this cluster. You can retrieve this value from the cluster's overview page in the IBM Cloud Console as "Cluster ID" or using the IBM Cloud CLI. 
 Location location Location of the cluster derived from its cloud resource name. 
 Namespace namespace Namespace of the service account that is used to retrieve a Compute Resource token and get an IAM token.
General information 

The information that you specify for a new VMware vSphere® instance is based on a cluster configuration template.



  Cluster configurations 



*  You can specify settings for an instance and place the order, or save the settings as a configuration template without placing an order.
*  You can also select a saved configuration template to further update it, and then save it as a new configuration template.







  Cluster name 

The cluster name is set to vss-xx by default, where xx represents two randomly generated alphabetic characters.

You can also specify a cluster name that meets the following requirements:



*  Only lowercase alphabetic, numeric, and dash (-) characters are allowed.
*  The cluster name must start with a lowercase alphabetic character.
*  The cluster name must end with a lowercase alphabetic or numeric character.
*  The maximum length of the cluster name is 10 characters.
*  The cluster name must be unique within your account.







  Related links 



*  [Licensing](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_orderinginstances-licensing-settings)
*  [Procedure to order VMware vSphere instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_orderinginstances-procedure)
Optional: Remap cluster subnets by using the localSubnetNAT setting. Network Address Translation (NAT) for subnets provides a workaround for subnet conflicts between the cluster network and on-premises remote network. You can use NAT to remap the cluster's private local IP subnets, the pod subnet (172.30.0.0/16), or the pod service subnet (172.21.0.0/16) to a different private subnet. The VPN tunnel sees remapped IP subnets instead of the original subnets. Remapping happens before the packets are sent over the VPN tunnel as well as after the packets arrive from the VPN tunnel. You can expose both remapped and non-remapped subnets at the same time over the VPN. To enable NAT, you can either add an entire subnet or individual IP addresses.



* If you add an entire subnet in the format 10.171.42.0/24=10.10.10.0/24, remapping is 1-to-1: all the IP addresses in the internal network subnet are mapped over to external network subnet and vice versa.
* If you add individual IP addresses in the format 10.171.42.17/32=10.10.10.2/32,10.171.42.29/32=10.10.10.3/32, only those internal IP addresses are mapped to the specified external IP addresses.



3. Optional for version 2.2.0 and later strongSwan Helm charts: Hide all the cluster IP addresses behind a single IP address by setting enableSingleSourceIP to true. This option provides one of the most secure configurations for the VPN connection because no connections from the remote network back into the cluster are permitted.



* This setting requires that all data flow over the VPN connection must be outbound regardless of whether the VPN connection is established from the cluster or from the remote network.
* If you install strongSwan into a single-zone cluster, you must set local.subnet to only one IP address as a /32 subnet.