vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Set remote.gateway to the public IP address for the on-premises VPN endpoint in the remote network.
3. Choose one of the following options for the IP address for the cluster VPN endpoint:



* Public IP address of the cluster's private gateway: If your worker nodes are connected to a private VLAN only, then the outbound VPN request is routed through the private gateway to reach the internet. The public IP address of the private gateway is used for the VPN connection.
* Public IP address of the worker node where the strongSwan pod runs: If the worker node where the strongSwan pod runs is connected to a public VLAN, then the worker node's public IP address is used for the VPN connection.



* If the strongSwan pod is deleted and rescheduled onto a different worker node in the cluster, then the public IP address of the VPN changes. The on-premises VPN endpoint of the remote network must allow the VPN connection to be established from the public IP address of any of the cluster worker nodes.
* If the remote VPN endpoint can't handle VPN connections from multiple public IP addresses, limit the nodes that the strongSwan VPN pod deploys to. Set nodeSelector to the IP addresses of specific worker nodes or a worker node label. For example, the value kubernetes.io/hostname: 10.232.xx.xx allows the VPN pod to deploy to that worker node only. The value strongswan: vpn restricts the VPN pod to running on any worker nodes with that label. You can use any worker node label. To allow different worker nodes to be used with different helm chart deployments, use strongswan: <release_name>. For high availability, select at least two worker nodes.



* Public IP address of the strongSwan service: To establish connection by using the IP address of the strongSwan VPN service, set connectUsingLoadBalancerIP to true. The strongSwan service IP address is either a portable public IP address you can specify in the loadBalancerIP setting, or an available portable public IP address that is automatically assigned to the service.
* [Connecting to an AWS peer](https://cloud.ibm.com/docs/vpc?topic=vpc-aws-config)
* [Connecting to a Check Point Security Gateway peer](https://cloud.ibm.com/docs/vpc?topic=vpc-check-point-config)
* [Connecting to a Cisco ASAv peer](https://cloud.ibm.com/docs/vpc?topic=vpc-cisco-asav-config)
* [Connecting to a FortiGate peer](https://cloud.ibm.com/docs/vpc?topic=vpc-fortigate-config)
* [Connecting to a Juniper vSRX peer](https://cloud.ibm.com/docs/vpc?topic=vpc-juniper-vsrx-config)
* [Connecting to a strongSwan peer](https://cloud.ibm.com/docs/vpc?topic=vpc-strongswan-config)
* [Connecting to a Vyatta peer](https://cloud.ibm.com/docs/vpc?topic=vpc-vyatta-config)



These configurations are fully tested and supported by IBM. If you plan to use an on-premises VPN gateway peer other than those listed, IBM Support can assist in troubleshooting your configuration, but cannot guarantee a resolution.





 Checking the status of the secure connection 

You can check the status of your connection in the IBM Cloud console. On the VPN for VPC page, select your VPN gateway and click Connections from the navigation pane on the left of the page.

You can also test the connection by doing a ping from a virtual server instance in your VPC to a server in the on-premises network.
If your z/OS virtual server instance is created by using the z/OS dev and test stock image, you can refer to the [Reserved configurations](https://www.ibm.com/docs/en/wazi-aas/1.0.0?topic=vpc-configurations-in-zos-stock-images) table to add additional ports to the security group of your instance.





 Step 1. Configuring the password 

Before you can log in to a z/OS virtual server instance, you must change the password for the default user ID ibmuser.

If you are using your z/OS Wazi aaS custom images, you do not need to configure the password. You can safely ignore this step and then connect to the z/OS virtual server instance instead.



1. Log in to the z/OS UNIX shell environment by using your SSH private key and the default user ID. The vsi ip address in the following code snippets represent the private IP address of your z/OS virtual server instance.

ssh -i <path to your private key file> ibmuser@<vsi ip address>

You receive a response similar to the following example. When prompted to continue connecting, type yes.

The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx.xxx.xxx.xxx' (ECDSA) to the list of known hosts.
2. Use the tsocmd command to configure password phrases for the z/OS instance. Replace YOUR PASSWORD PHRASE with your own password phrase.

tsocmd "ALTUSER IBMUSER PHRASE('YOUR PASSWORD PHRASE') NOEXPIRE RESUME"

You must follow the password policies to enforce more secure connection:



* Must be 8 characters.
"nonce": "8zJE9pKVdXVe/nLb"
}

The payload value represents the public key that is associated with the import token. This value is base64 encoded. The nonce value is used to verify the originality of a request to the service. You need to encrypt and provide this value when you import your encryption key in a later step.
3. Decode and save the public key to a file called PublicKey.pem.

jq -r '.payload' getImportTokenResponse.json | base64 --decode -o PublicKey.pem

The public key is now downloaded to your computer in PEM format. Continue to the next step.







 Step 5. Create an encryption key 

With Key Protect, you can enable the security benefits of Bring Your Own Key (BYOK) by creating and uploading your own keys for use on IBM Cloud.

In the following step, you create a 256-bit AES symmetric key on your local computer.

This tutorial uses the OpenSSL cryptography toolkit to generate a pseudo-random key, but you might want to [explore different options](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keysplan-ahead) for generating stronger keys based on your security needs. For example, you might want to use your organization's internal key management system, backed by an on-premises hardware security module (HSM), to create and export keys.



1. In a terminal window, run the following openssl command to create a 256-bit encryption key.

openssl rand 32 > PlainTextKey.bin

Success! Your encryption key is now saved in a file called PlainTextKey.bin. Continue to the next step.







 Step 6. Encrypt the nonce 

To verify that the bits we receive are exactly the same as the bits that you send as part of a request, Key Protect requires nonce verification when you upload the symmetric key to the service.

In cryptography, a nonce serves as a session token that checks the originality of a request to protect against malicious attacks and unauthorized calls.
Refer to [Connecting to Windows instances](https://cloud.ibm.com/docs/vpc?topic=vpc-vsi_is_connecting_windows) to access the Windows Administrator's password, however, in short the following commands are used from your laptop, where the instances command returns the <INSTANCE_ID> of the virtual server:

ibmcloud is instances
ibmcloud is instance-initialization-values <INSTANCE_ID> --private-key @/.ssh/id_rsa





 Join the domain 

This task should not be started until after the AD server has been installed.

At a PowerShell prompt on the bastion host enter the following commands that enable the server to join the domain:



* The Get-DnsClientServerAddress captures the Interface Index for the IPv4 Ethernet interface, so that the DNS can be changed from the IBM Cloud DNS server to the ADDNS server. The Add-Computer command will fail if this step is missed as the server will not be able to locate the domain controller. The Add-Computer -Server only accepts FQDN.
* The Add-Computer command adds the server to the domain <domain> using the ADDNS server <ad_server_fqdn> and then restarts the server to make the change effective.



$dns = "<ADDNS_IP_Address>"
$adserver = "<ad_server_fqdn>"
$domain = "<domain>"
$user = $domain + "Administrator"
$password = "<password>"
$out=Get-DnsClientServerAddress -InterfaceAlias Ethernet -AddressFamily IPv4 | Select-Object -Property InterfaceIndex
Set-DnsClientServerAddress -InterfaceIndex $out.InterfaceIndex -ServerAddresses ($dns)
$password = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ($user, $password)
Add-Computer -DomainName $domain -Server $adserver -Restart -Credential $credential
* If the connection is inbound to the cluster from the remote network, check whether the remote VPN endpoint can re-establish the VPN connection to a different IP address in case of load balancer failure in one zone.



To get started with strongSwan in a multizone cluster, choose one of the following options.



* If you can use an outbound VPN connection, you can choose to configure only one strongSwan VPN deployment. See [Configuring one outbound VPN connection from a multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnmultizone_one_outbound).
* If you require an inbound VPN connection, the configuration settings you can use vary depending on whether the remote VPN endpoint can be configured to re-establish the VPN connection to a different public load balancer IP when an outage is detected.



* If the remote VPN endpoint can automatically re-establish the VPN connection to a different IP, you can choose to configure only one strongSwan VPN deployment. See [Configuring one inbound VPN connection to a multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnmultizone_one_inbound).
* If the remote VPN endpoint can't automatically re-establish the VPN connection to a different IP, you must deploy a separate inbound strongSwan VPN service in each zone. See [Configuring a VPN connection in each zone of a multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnmultizone_multiple).





Try to set up your environment so that you need only one strongSwan VPN deployment for an outbound or inbound VPN connection to your multizone cluster. If you must set up separate strongSwan VPNs in each zone, make sure that you plan how to manage this added complexity and increased resource usage.



 Configuring a single outbound VPN connection from a multizone cluster
If you brought your own encryption key from [Key Protect](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-key-protect), the panel provides a link to your Key Protect instance and the Encryption Key field has the name of the key.
* [Change the admin password](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-admin-password)
* [Implement or modify an IP allowlist](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-allowlisting)







 Service Credentials 

You can generate a new set of credentials for cases where you want to manually [connect an app](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-ibmcloud-app) or [external consumer](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-external-app) to an IBM Cloud service. For more information, see [Adding and viewing credentials](https://cloud.ibm.com/docs/account?topic=account-service_credentials).





 Connections 

Shows connected resources. You can use the Create connection button to bind this service to another resource.





 View docs 

The View docs link from the Actions drop list opens the main documentation page for Databases for Redis in a new tab.
]
}









 Protecting your data with customer-managed keys 

By default, Continuous Delivery encrypts your data by using keys that are internal to the Continuous Delivery service. For greater security and control, you can configure Continuous Delivery to encrypt your data by using keys that you manage. This option is available only under the Professional plan, and only at the time that you are provisioning an instance of the Continuous Delivery service. If you select your own Key Management Service, such as Key Protect or IBM Cloud® Hyper Protect Crypto Services, the following values are encrypted by using your own key instead of the encryption keys that are internal to the Continuous Delivery service.



Table 3. Values that are encrypted by using your own key

 Component Value 

 Toolchain Properties and parameters 
 Pipeline <br><br> * Property keys and values<br> * Job logs<br> * Job artifacts<br><br><br> 
 Integrations <br><br> * Slack (Slack webhook)<br> * Pagerduty (API access key, Integration key)<br> * Sauce Labs (Access key)<br> * Artifactory (API key)<br> * HashiCorp Vault (Token, Role ID, Secret ID, Password)<br> * Jenkins (Jenkins API token)<br> * JIRA (JIRA API token)<br> * Nexus (Authentication token)<br> * Rational Team Concert (Password)<br> * Security and Compliance Center (IBM Cloud API key)<br> * Sonarqube (SonarQube password or authentication token)<br><br><br> 
 IBM Cloud® DevOps Insights Attachment in test records 



The following components encrypt personal data by using only the provider-managed encryption key.



Table 4. Values that are encrypted by using the provider-managed key

 Component Value 

 Git Repos and Issue Tracking <br><br> * Issues, pull requests, and source code<br> * Personal information, such as name, email, profile picture, address, and other information from the profile page<br><br><br>
tolerations
: If the worker that you deleted was not tainted, but the only workers that remain are tainted, change this setting to allow the VPN pod to run on workers with any taints or specific taints.
4. Install the new Helm chart with your updated values.

helm install <release_name> iks-charts/strongswan -f config.yaml
5. Check the chart deployment status. When the chart is ready, the STATUS field near the top of the output has a value of DEPLOYED.

helm status <release_name>
6. Sometimes, you might need to change your on-prem settings and your firewall settings to match the changes you made to the VPN configuration file.
7. Start the VPN.



* If the VPN connection is initiated by the cluster (ipsec.auto is set to start), start the VPN on the on-prem gateway, and then start the VPN on the cluster.
* If the VPN connection is initiated by the on-prem gateway (ipsec.auto is set to auto), start the VPN on the cluster, and then start the VPN on the on-prem gateway.



8. Set the STRONGSWAN_POD environment variable.

export STRONGSWAN_POD=$(kubectl get pod -l app=strongswan,release=<release_name> -o jsonpath='{ .items[0].metadata.name }')
9. Check the status of the VPN.

kubectl exec $STRONGSWAN_POD -- ipsec status



* If the VPN connection has a status of ESTABLISHED, the VPN connection was successful. No further action is needed.
* If you are still having connection issues, see [Why can't I establish VPN connectivity with the strongSwan Helm chart?](https://cloud.ibm.com/docs/containers?topic=containers-cs_vpn_fails) to further troubleshoot your VPN connection.
*  UI
*  CLI
*  API







  Setting the Admin Password 



  Setting the Admin Password in the UI 

The IBM Cloud® Databases for PostgreSQL service is provisioned with an admin user, so you can manage PostgreSQL by using its command line tool, psql.

Set the admin password before using it to connect. To set the password through the IBM Cloud dashboard, select Manage from the service dashboard to open the management panel for your service. Open the Settings tab, and use the Change Database Admin Password pane to set a new admin password.

![The Change Database Admin Password pane in Settings](https://cloud.ibm.com/docs-content/v1/content/3505da55c475bf1edbe3eb3496324ba13941b783/databases-for-postgresql/images/settings-admin-password.png){: caption="Figure 1. The Change Database Admin Password pane in Settings" caption-side="bottom"}





  Setting the admin password through the command line 

Use the cdb user-password command from the IBM Cloud CLI cloud databases plug-in to set the admin password with the command line.

For example, to set the admin password for a deployment named "example-deployment", use the following command.

ibmcloud cdb user-password example-deployment admin <newpassword>





  Setting the admin password through the API 

The Foundation Endpoint that is shown on the Overview panel Deployment Details section of your service provides the base URL to access this deployment through the API. Use it with the /deployments/{id}/users/{username} endpoint to set the admin password.

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/admin' -H "Authorization: Bearer $APIKEY" -H "Content-Type: application/json" -d '{"password":"newrootpasswordsupersecure21"}'

For more information, see [API Reference](https://cloud.ibm.com/apidocs/cloud-databases-apiset-database-level-user-s-password).
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. If you install strongSwan in a multizone cluster, you can set local.subnet to the %zoneSubnet variable, and use the local.zoneSubnet to specify an IP address as a /32 subnet for each zone of the cluster.



4. Optional for version 2.2.0 and later strongSwan Helm charts: Enable the strongSwan service to route incoming requests from the remote network to a service that exists outside of the cluster by using the localNonClusterSubnet setting.



* The non-cluster service must exist on the same private network or on a private network that is reachable by the worker nodes.
* The non-cluster worker node can't initiate traffic to the remote network through the VPN connection, but the non-cluster node can be the target of incoming requests from the remote network.
Run amqsgetc against the alias queue to get the messages from the default queue



* amqsgetc DEV.ALIAS.QUEUE.1
* DEV.ALIAS.QUEUE.1 is our name for the alias queue



6. The terminal will prompt you for a Password



* This is your <APP_API_KEY> = 'apiKey' in the file apiKey.json



7. Terminal will now output the encrypted messages from the default queue



![Image showing the steps taken in this section, including the output from amqsgetc on the alias queue displaying the encrypted message on the default queue](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_ams_encrypted_message.png)



* Note: the message is not shown in plain text. This is because the message is encrypted on the default queue.







 Conclusion 

You have now completed this tutorial. You have enabled IBM MQ AMS on a queue, and you have demonstrated that this ensures that messages stored on the specified queue are encrypted.





 Troubleshooting 



* amqsputc returns reason code 2063



* This can occur if you have not selected a certificate for your channel
* Follow ['Select a certificate to use for AMS encryption'](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_qm_amsselectcert_mqoc_qm_ams)





![Image showing error code 2063 occurring](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_ams_2063.png)



* amqsputc returns reason code 2035
k8s-conn{2}: 172.21.0.0/16 172.30.0.0/16 === 10.91.152.xxx/26



* When you try to establish VPN connectivity with the strongSwan Helm chart, it is likely that the VPN status is not ESTABLISHED the first time. You might need to check the on-premises VPN endpoint settings and change the configuration file several times before the connection is successful.



1. Run helm uninstall <release_name> -n <namespace>
2. Fix the incorrect values in the configuration file.
3. Run helm install vpn iks-charts/strongswan -f config.yaml



You can also run more checks in the next step.
* If the VPN pod is in an ERROR state or continues to crash and restart, it might be due to parameter validation of the ipsec.conf settings in the chart's ConfigMap.



1. Check for any validation errors in the strongSwan pod logs by running oc logs $STRONGSWAN_POD.
2. If validation errors exist, run helm uninstall <release_name> -n <namespace>
3. Fix the incorrect values in the configuration file.
4. Run helm install vpn iks-charts/strongswan -f config.yaml





4. You can further test the VPN connectivity by running the five Helm tests that are in the strongSwan chart definition.

helm test vpn



* If all the tests pass, your strongSwan VPN connection is successfully set up.
* If any of the tests fail, continue to the next step.



5. View the output of a failed test by looking at the logs of the test pod.

oc logs <test_program>

Some tests have requirements that are optional settings in the VPN configuration. If some tests fail, the failures might be acceptable depending on whether you specified these optional settings. Refer to the following table for information about each test and why it might fail.

vpn-strongswan-check-config
* [Allow access to the private IP addresses of services that support private cloud service endpoints in Calico policies](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers)
* [Allow access to services' public IP addresses and to the private IP addresses of services that support private cloud service endpoints in a gateway appliance firewall](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_outbound)







 IBM Cloud® Direct Link for communication over the private network with resources in on-premises data centers 

To connect your cluster with your on-premises data center, such as with IBM Cloud Private, you can set up [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl). With IBM Cloud Direct Link, you create a direct, private connection between your remote network environments and Red Hat OpenShift on IBM Cloud without routing over the public internet.





 strongSwan IPSec VPN connection for communication over the public network with resources in on-premises data centers 

Set up a [strongSwan IPSec VPN service](https://www.strongswan.org/about.html) directly in your cluster. The strongSwan IPSec VPN service provides a secure end-to-end communication channel over the internet that is based on the industry-standard Internet Protocol Security (IPSec) protocol suite. To set up a secure connection between your cluster and an on-premises network, [configure and deploy the strongSwan IPSec VPN service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnvpn-setup) directly in a pod in your cluster.

If you plan to use a gateway appliance, set up an IPSec VPN endpoint on a gateway appliance, such as a Virtual Router Appliance (Vyatta).