vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Configure one strongSwan VPN Helm chart](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnvpn_configure). When you follow the steps in that section, ensure that you specify the following settings.



* ipsec.auto: Change to add. Connections are inbound to the cluster.
* loadBalancerIP: Do not specify an IP address. Leave this setting blank.
* zoneLoadBalancer: Specify a public load balancer IP address for each zone where you have worker nodes. [You can check to see your available public IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetsreview_ip) or [free up a used IP address](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetsfree).
* local.id: If the remote VPN endpoint requires you to set the local.id option (leftid value in ipsec.conf) to the public IP address of the VPN IPSec tunnel, set local.id to %loadBalancerIP. This value automatically configures the leftid value in ipsec.conf to the load balancer IP address that is used for the connection.



2. In your remote network firewall, allow outgoing IPSec VPN connections to the public IP addresses you listed in the zoneLoadBalancer setting.







 Configuring an inbound VPN connection in each zone of a multizone cluster 

When you require incoming VPN connections and the remote VPN endpoint can't re-establish the VPN connection to a different IP, you must deploy a separate strongSwan VPN service in each zone.

The remote VPN endpoint must be updated to establish a separate VPN connection to a load balancer in each of the zones. Additionally, you must configure zone-specific settings on the remote VPN endpoint so that each of these VPN connections is unique. Ensure that these multiple incoming VPN connections remain active.
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.



* If you choose to select an IP address using the loadBalancerIP setting, the cluster must have at least one available public load balancer IP address. [You can check to see your available public IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-subnetsreview_ip) or [free up a used IP address](https://cloud.ibm.com/docs/containers?topic=containers-subnetsfree).
The VPN tunnel endpoint (router) forwards the request to the on-premises server or mainframe, depending on the destination IP address that was specified in step 2. The necessary data is sent back over the VPN connection to myapp through the same process.







 strongSwan VPN service considerations 

Before using the strongSwan Helm chart, review the following considerations and limitations.



* The strongSwan Helm chart is supported only for classic clusters, and is not supported for VPC clusters. For VPN information for VPC clusters, see [Setting up VPC VPN connectivity](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaas).
* The strongSwan Helm chart requires NAT traversal to be enabled by the remote VPN endpoint. NAT traversal requires UDP port 4500 in addition to the default IPSec UDP port of 500. Both UDP ports need to be allowed through any firewall that is configured.
* The strongSwan Helm chart does not support route-based IPSec VPNs.
* The strongSwan Helm chart supports IPSec VPNs that use pre-shared keys, but does not support IPSec VPNs that require certificates.
* The strongSwan Helm chart does not allow multiple clusters and other IaaS resources to share a single VPN connection.
* The strongSwan Helm chart runs as a Kubernetes pod inside of the cluster. The VPN performance is affected by the memory and network usage of Kubernetes and other pods that are running in the cluster. If you have a performance-critical environment, consider using a VPN solution that runs outside of the cluster on dedicated hardware.
* The strongSwan Helm chart runs a single VPN pod as the IPSec tunnel endpoint. If the pod fails, the cluster restarts the pod. However, you might experience a short down time while the new pod starts and the VPN connection is re-established. If you require faster error recovery or a more elaborate high availability solution, consider using a VPN solution that runs outside of the cluster on dedicated hardware.
The VPN tunnel endpoint (router) forwards the request to the on-premises server or mainframe, depending on the destination IP address that was specified in step 2. The necessary data is sent back over the VPN connection to myapp through the same process.







 strongSwan VPN service considerations 

Before using the strongSwan Helm chart, review the following considerations and limitations.



* The strongSwan Helm chart is supported only for classic clusters, and is not supported for VPC clusters. For VPN information for VPC clusters, see [Setting up VPC VPN connectivity](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaas).
* The strongSwan Helm chart requires NAT traversal to be enabled by the remote VPN endpoint. NAT traversal requires UDP port 4500 in addition to the default IPSec UDP port of 500. Both UDP ports need to be allowed through any firewall that is configured.
* The strongSwan Helm chart does not support route-based IPSec VPNs.
* The strongSwan Helm chart supports IPSec VPNs that use pre-shared keys, but does not support IPSec VPNs that require certificates.
* The strongSwan Helm chart does not allow multiple clusters and other IaaS resources to share a single VPN connection.
* The strongSwan Helm chart runs as a Kubernetes pod inside of the cluster. The VPN performance is affected by the memory and network usage of Kubernetes and other pods that are running in the cluster. If you have a performance-critical environment, consider using a VPN solution that runs outside of the cluster on dedicated hardware.
* The strongSwan Helm chart runs a single VPN pod as the IPSec tunnel endpoint. If the pod fails, the cluster restarts the pod. However, you might experience a short down time while the new pod starts and the VPN connection is re-established. If you require faster error recovery or a more elaborate high availability solution, consider using a VPN solution that runs outside of the cluster on dedicated hardware.
* The strongSwan Helm chart does not provide metrics or monitoring of the network traffic flowing over the VPN connection.
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.
* You must list the CIDRs of the non-cluster subnets in the local.subnet setting.









 Step 5: Access remote network resources over the VPN connection 

Determine which remote network resources must be accessible by the cluster over the VPN connection.



1. Add the CIDRs of one or more on-premises private subnets to the remote.subnet setting. Note: If ipsec.keyexchange is set to ikev1, you can specify only one subnet.
2. Optional for version 2.2.0 and later strongSwan Helm charts: Remap remote network subnets by using the remoteSubnetNAT 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 remote network's IP subnets to a different private subnet. Remapping happens before the packets are sent over the VPN tunnel. Pods in the cluster see the remapped IP subnets instead of the original subnets. Before the pods send data back through the VPN tunnel, the remapped IP subnet is switched back to the actual subnet that is being used by the remote network. You can expose both remapped and non-remapped subnets at the same time over the VPN.







 Step 6 (optional): Enable monitoring with the Slack webhook integration 

To monitor the status of the strongSwan VPN, you can set up a webhook to automatically post VPN connectivity messages to a Slack channel.



1. Sign in to your Slack workspace.
2.
Securing the FortiGate Security Appliance 1 Gbps 

You can configure the FortiGate Security Appliance (FSA) 1 Gbps to meet security and compliance requirements. IBM© Cloud provides a VDOM Administrator account with a randomly assigned password. You can rotate that password, create read-only users, and restrict access based on "Trusted Hosts," which accepts traffic only from specified source IPs (up to three).

To complete these activities:



1.  From your browser, open the [IBM Cloud UI Console ![External link icon](https://cloud.ibm.com/docs-content/v1/content/icons/launch-glyph.svg)](https://cloud.ibm.com/classic/security/firewalls/multivlan/provision) and log in to your account.
2.  Follow the How to [Manage the FortiGate Security Appliance](https://cloud.ibm.com/docs/fortigate-1g?topic=fortigate-1g-managing-the-fortigate-security-appliance-1gbps) instructions to find the credentials.
3.  Log in to the appliance, and navigate to System > Admin > Administrators. All access and changes are logged.
4.  To configure individual interfaces, navigate to System > Network > Interfaces.

You can restrict access to the administrative interfaces to just the protocols they require (typically HTTPS and SSH, which provides in-transit encryption). For extra security, you can also disable external access to the administrative interface. You can accomplish this by enabling the appropriate protocols on the "inside" interface (the interface that a customer's public VLAN resides on). You can also disable all protocols on the "outside" interface (the interface that public internet traffic is received from). This additional security measure requires a server that is positioned inside the VLAN from which to administer the FSA.
To create a password stash file, run the following commands and replace <normal_user_api_key> by the API key of the normal user that you created.

su - db2inst1
db2credman -stash -password "<normal_user_api_key>" -to /pkcs11/pkcs11_pw.sth
4. To update the Db2 configuration, run the following command as user db2inst1:

db2 update dbm cfg using keystore_location /pkcs11/keystore.conf keystore_type pkcs11
5. To set the environment variable DB2_DEK_MAC_TYPE, run the following commands as user db2inst1 and restart DB2:

db2 terminate
db2stop
export DB2_DEK_MAC_TYPE=HMAC
db2start

You need to specify the environment variable DB2_DEK_MAC_TYPE=HMAC before you start Db2. If you use Db2 on Windows, you need to set the Db2 profile variable by using the following command:

db2set -g DB2_DEK_MAC_TYPE=HMAC
6. To create an encrypted database, run the following commands:

db2 create db cryptdb1 encrypt

This command prints the following information:

DB20000I The CREATE DATABASE command completed successfully.
7. To test the encrypted database, run the following commands:

db2 connect to cryptdb1
db2 "create table test (id int not null, data varchar(100))"
db2 "insert into test values (1, 'This is a secret text')"
db2 "select * from test"

This command prints the following information:

ID DATA
* If pods in the cluster must access services on the remote on-premises network and applications in the remote on-premises network must access services in the cluster, configure the localSubnetNAT and remoteSubnetNAT settings listed in the second bullet point. Note that if a pod in the cluster initiates a request to the remote on-premises network, you must add logic to the pod so that it can select which VPN connection to use to access the services on the remote on-premises network.



3. Configure the remote VPN endpoint software to establish a separate VPN connection to the load balancer IP in each zone.









 Configuring the strongSwan Helm chart 

Before you install the strongSwan Helm chart, you must decide on your strongSwan configuration.

Before you begin



* Install an IPSec VPN gateway in your on-premises data center.
* Ensure you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the default namespace.
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster). All strongSwan configurations are permitted in standard clusters.





 Step 1: Get the strongSwan Helm chart 

Install Helm and get the strongSwan Helm chart to view possible configurations.



1. [Follow the instructions](https://cloud.ibm.com/docs/openshift?topic=openshift-helminstall_v3) to install the version 3 Helm client on your local machine.
2. Save the default configuration settings for the strongSwan Helm chart in a local YAML file.

helm show values iks-charts/strongswan > config.yaml
3. Open the config.yaml file.







 Step 2: Configure basic IPSec settings 

To control the establishment of the VPN connection, modify the following basic IPSec settings.
* [Allow access to the private IP addresses of services that support private cloud service endpoints in Calico policies](https://cloud.ibm.com/docs/containers?topic=containers-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/containers?topic=containers-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 IBM Cloud Kubernetes Service without routing over the public internet.





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



* Worker nodes that are connected to public and private VLANs: 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/containers?topic=containers-vpnvpn-setup) directly in a pod in your cluster.
* Worker nodes connected to a private VLAN only: Set up an IPSec VPN endpoint on a gateway appliance, such as a Virtual Router Appliance (Vyatta).
$ AAD1=My-Secret-Password
$ AAD2=My-Verification-Phrase

 wrap the plaintext DEK with the root key and AAD
$ CIPHERTEXT=$(ibmcloud kp key wrap $KEY_ID -a "$AAD1,$AAD2" --output json | jq -r '.["Ciphertext"]')

$ echo $CIPHERTEXT

eyJjaXBoZXJ0ZXh0IjoiL1pQUzRLbUxQ ...<redacted>... ZjA2ODhjN2JiIn0=

 unwrap the ciphertext and reveal the original DEK
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT -a $AAD1,$AAD2

Unwrapping key...
OK
Plaintext Rewrapped Plaintext
H4ZfQe66aKcxirfCdNZ/3Na0JECP6HsAM3yclKmIfPQ=

 this should fail (missing some of the AAD)
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT -a $AAD1

Unwrapping key...
FAILED

 this should fail (AAD is in a different order)
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT -a $AAD2,$AAD1

Unwrapping key...
FAILED







 Required parameters 



* KEY_ID_OR_ALIAS

The v4 UUID or alias of the root key that you want to use for wrapping. You cannot wrap a standard key.
* -i, --instance-id

The IBM Cloud instance ID that identifies your Key Protect instance.

You can set an environment variable instead of specifying -i with the following command: $ export KP_INSTANCE_ID=<INSTANCE_ID>.







 Optional parameters 



* -a, --aad

The additional authentication data (AAD) that is used to further secure a key.
Unwrapping key...
OK
Plaintext Rewrapped Plaintext
H4ZfQe66aKcxirfCdNZ/3Na0JECP6HsAM3yclKmIfPQ=

 this should fail (missing some of the AAD)
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT -a $AAD1

Unwrapping key...
FAILED

 this should fail (AAD is in a different order)
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT -a $AAD2,$AAD1

Unwrapping key...
FAILED







 Required parameters 

KEY_ID
: The ID of the root key that you used for the initial wrap request.





 Optional parameters 

-a, --aad
: The additional authentication data (AAD) that was used to further secure a key. You can provide up to 255 strings, each delimited by a comma. If you supplied AAD on wrap, you must specify the same AAD, in the same order, on unwrap.

Important: The Key Protect service does not save additional authentication data. If you supply AAD, save the data to a secure location to ensure that you can access and provide the same AAD during subsequent unwrap requests.







 kp key wrap 

[Wrap a data encryption key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-wrap-keys) (DEK) using a root key that is stored in the Key Protect instance. A DEK is typically used to encrypt "other" pieces of information.

When you wrap a DEK with a root key, Key Protect combines the strength of multiple algorithms to protect the privacy and the integrity of your encrypted data.

You cannot wrap a standard key, that is, a key created using the -s parameter (ibmcloud kp key create my-key-name -s).

ibmcloud kp key wrap KEY_ID
-i, --instance-id INSTANCE_ID
[-a, --aad ADDITIONAL_DATA]
If you brought your own encryption key from [Key Protect](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-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-etcd?topic=databases-for-etcd-admin-password)
* [Implement or modify an IP allowlist](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-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-etcd?topic=databases-for-etcd-ibmcloud-app) or [external consumer](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-external-app) to an IBM Cloud service. [Learn more](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 etcd in a new tab.
Whenever the following snippets call for a passphrase or password, you can use a key from Key Protect by using copy & paste or some shell scripting.

When using IBM Cloud Object Storage with Key Protect, a root key is used to encrypt buckets, so only the provisioning and the creation of the root key steps are necessary.

You can provision Key Protect from the IBM Cloud Dashboard or by using the API. After you provision a Key Protect instance, you can create (or import) a customer-managed root key. This root key never leaves the HSM but it is used to encrypt and decrypt other keys. When the root key is available, you can create (or import) a standard key to directly encrypt and decrypt data. For more information about using Key Protect, see the following topics:



* [Creating or importing keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial)
* A data encryption key (DEK) should only be stored in encrypted (wrapped) format. Key Protect performs this wrapping by encrypting it with the root key.



* [Retrieving a wrapped key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-wrap-keys&interface=ui)
* [Retrieving a wrapped key via the API](https://cloud.ibm.com/apidocs/key-protectwrapkey)



* Once retrieved, the wrapped DEK can be stored on the local file system, and unwrapped only when the key is needed for some file system operation (mounting, encryption, etc).



* [Unwrapping a wrapped key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-unwrap-keys&interface=ui)
* [Unwrapping a wrapped key via the API](https://cloud.ibm.com/apidocs/key-protectunwrapkey)
Use the following command to disable password authentication: sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config.
4. Use the following command to disable root login: sudo sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin no/g' /etc/ssh/sshd_config.
5. Restart SSH with command sudo systemctl restart ssh.







 Related links 



* [Cyber recovery with Veeam architecture overview](https://cloud.ibm.com/docs/vmwaresolutions/?topic=vmwaresolutions-veeam-cr-sa-overview)