vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Log in to the IBM Cloud console](https://cloud.ibm.com/login/).
2. Go to Menu > Resource List to view a list of your resources.
3. From your IBM Cloud resource list, select your provisioned instance of Key Protect.
4. On the Instance policies page, use the Policies table to browse the policies in your Key Protect instance.
5. Click the ⋯ icon to open a list of options for the policy that you want to disable.
6. From the options menu, click Disable policy and confirm the policy was disabled in the updated Policies table.







 Disabling dual authorization for your Key Protect instance with the API 

As an instance manager, disable an existing dual authorization policy for a Key Protect instance by making a PUT call to the following endpoint.

https://<region>.kms.cloud.ibm.com/api/v2/instance/policies?policy=dualAuthDelete



1. [Retrieve your authentication credentials to work with the API](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-api).

To enable and disable dual authorization policies, you must be assigned a Manager access policy for your Key Protect instance. To learn how IAM roles map to Key Protect service actions, check out [Service access roles](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles).
2. Disable an existing dual authorization policy for your Key Protect instance by running the following curl command.
Use Hyper Protect Crypto Services for TLS offload for all data that is that is requested from outside of IBM Cloud (inbound traffic to IBM Cloud) and protected by a certificate which is signed by a public Certificate Authority. Configure any web servers to use TLS offload to set up the session, so that the private key never leaves Hyper Protect Crypto Services.

More detailed guidance can be found in the Cryptographic Requirements appendix of the Control Implementation Overview Template for whichever reference architecture you are using.

Implementation guidance:



* [VPC reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-at-rest)
* [Satellite reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-at-rest)



Most Relevant Controls:



Table 11. Related controls for data encryption

 Family Control
Describes the Import your own key settings.

 Setting Description 

 Key type The [type of key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryptionkey-types) that you would like to manage in Key Protect. Select the Root key button. 
 Name A human-readable alias for easy identification of your key. Length must be within 2 - 90 characters (inclusive). <br> <br>To protect your privacy, ensure that the key name does not contain personally identifiable information (PII), such as your name or location. Note that key names do not need to be unique. 
 Key material The base64-encoded key material, such as an existing key-wrapping key, that you want to store and manage in the service. For more information, check out [Base64 encoding your key material](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-root-keyshow-to-encode-root-key-material). Ensure that the key material is 16, 24, or 32 bytes long, and corresponds to 128, 192, or 256 bits in length. The key must also be base64-encoded. 
 Key alias Optional. [Key aliases](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-key-alias) are ways to describe a key that allow them to be identified and grouped beyond the limits of a display name. Keys can have up to five aliases. 
 Key ring Optional. [Key rings](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grouping-keys) are groupings of keys that allow those groupings to be managed independently as needed. Every key must be a part of a key ring. If no key ring is selected, keys are placed in the default key ring. Note that to place the key you're creating in a key ring, you must have the Manager role over that key ring.
* Create Calico host network policies to isolate your cluster on the [public network](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers_public) and on the [private network](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers).
* If you use a gateway appliance, such as a Virtual Router Appliance (VRA), [open up the required ports and IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_inbound) in the public firewall to permit inbound traffic to networking services. If you also have a firewall on the private network, [allow communication between worker nodes and let your cluster access infrastructure resources over the private network](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_private).



* VPC clusters:



* [Back up your internal image registry to IBM Cloud Object Storage.](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycos_image_registry)
* Expose your apps with [public networking services](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningopenshift_routers) or [private networking services](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningprivate_access).
* Connect your cluster with services in private networks outside of your IBM Cloud account or with resources in other VPCs by [setting up the IBM Cloud VPC VPN](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaas).
You want to limit API requests to private networks for security reasons. All Hyper Protect Crypto Services API requests must originate from within the IBM Cloud.

After the network access policy is set to private-only, you cannot make any Hyper Protect Crypto Services API calls from the public network, including the API to change the policy. Make sure that the private environment is set up before setting the network access policy to private-only.

There are several ways for you to update the network settings. However, before you update the network access policy, you need to initialize the service instance first. See [Initializing service instances with the IBM Cloud TKE CLI plug-in](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm) or [Initializing service instances using smart cards and the Management Utilities](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm-management-utilities) for instructions.



* When you [provision a service instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-provision), you can choose between the private-only and public-and-private options using either the IBM Cloud console or CLI.
* [Manage and update the network settings](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-managing-network-access-policies) after you provision and initialize the service instance.

After you enable a private-only network, you are not able to perform further key management actions in the IBM Cloud console. Use either the CLI or API to switch between a private-only network and a public-and-private network instead.



The instance access policy, which controls access to the instance from either public or private IP addresses, is not enforced after the ibmcloud resource service-instance-delete (NAME | ID) command to delete the instance is issued.

After you enable the following network settings, both the key management operations using key management service API and the cryptographic operations using GREP11 and PKCS #11 APIs are affected.







 Before you begin 



1.
6. Click Create access policy. After you read the warning, choose Enable.
7. Now all objects in this bucket are publicly accessible!







 Disable public access 



1. From anywhere in the IBM Cloud [console](https://cloud.ibm.com/), select the Manage menu, and the Access (IAM).
2. Select Access groups from the navigation menu.
3. Select Public Access to see a list of all public access policies currently in use.
4. Find the policy that corresponds to the bucket you want to return to enforced access control.
5. From the list of actions on the far right of the policy entry, choose Remove.
6. Confirm the dialog box, and the policy is now removed from the bucket.









 Allowing public access on individual objects 

To make an object publicly accessible through the REST API, an x-amz-acl: public-read header can be included in the request. Setting this header bypasses any [IAM policy](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-iam-overview) checks and allow for unauthenticated HEAD and GET requests. For more information about endpoints, see [Endpoints and storage locations](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints).

Additionally, [HMAC credentials](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-uhc-hmac-credentials-main) make it possible to allow [temporary public access that uses pre-signed URLs](https://cloud.ibm.com/docs/services/cloud-object-storage/hmac?topic=cloud-object-storage-presign-url).



 Upload a public object
From the menu bar, select Manage > Access (IAM).
3. In the side navigation, select Authorizations. Click Create.
4. In the Source service menu, select the service of the deployment. For example, watsonx.data.
5. In the Source service instance menu, select All service instances.
6. In the Target service menu, select Key Protect or Hyper Protect Crypto Services.
7. In the Target service instance menu, select the service instance to authorize.
8. Enable the Reader role. Click Authorize.







 Using the key encryption key 

After you grant watsonx.data deployments permission to use your keys, you supply the key name or CRN in Key Protect or Hyper Protect Crypto Services when you provision a deployment. The deployment uses your encryption key to encrypt your data.
Integrating your data and keys 

The data that you store in Db2 when using the Standard or Enterprise plan is encrypted by default by using randomly generated keys. If you need to control the encryption keys, you can use [IBM Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-services) or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started)to create, add, and manage encryption keys. Then, you can associate those keys with your Db2 on Cloud deployment to encrypt your Db2 databases.

IBM Key Protect helps you provision encrypted keys for apps across IBM Cloud services. As you manage the lifecycle of your keys, you can benefit from knowing that your keys are secured by FIPS 140-2 Level 3 certified cloud-based hardware security modules (HSMs) that protect against the theft of information.

Hyper Protect Crypto Services is a single-tenant, dedicated HSM that is controlled by you. The service is built on FIPS 140-2 Level 4-certified hardware, the highest offered by any cloud provider in the industry.

To get started, you need to provision a [Key Protect](https://cloud.ibm.com/catalog/services/key-protect) instance or a [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hs-crypto) instance on your IBM Cloud account.



 Creating or adding a key in the key management service 

To add a key in Key Protect, navigate to your instance of Key Protect and [generate or enter a key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial).

To add a key in Hyper Protect Crypto Services, navigate to your instance of Hyper Protect Crypto Services and [generate a key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started).





 Granting service authorization 

Authorize Key Protect for use with Db2 on Cloud deployments:



1. Open your IBM Cloud dashboard.
[Decide if you want to store the Key Protect root key CRN in a customized storage class or in a Kubernetes secret](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-blockvpc-customize-default). Then, follow the steps to create a customized storage class or a Kubernetes secret.

Example customized storage class.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: <storage_class_name> Enter a name for your storage class.
provisioner: vpc.block.csi.ibm.io
parameters:
profile: "5iops-tier"
csi.storage.k8s.io/fstype: "ext4"
billingType: "hourly"
encrypted: "true"
encryptionKey: "<encryption_key>"
resourceGroup: ""
zone: ""
tags: ""
generation: "gc"
classVersion: "1"
reclaimPolicy: "Delete"
Show more

encrypted
: In the parameters, enter true to create a storage class that sets up encryption for your Block Storage for Classic volumes. If you set this option to true, you must provide the root key CRN of your Key Protect service instance that you want to use in parameters.encryptionKey.

encryptionKey
: In the parameters, enter the root key CRN that you retrieved earlier.

Example Kubernetes secret.

apiVersion: v1
kind: Secret
type: vpc.block.csi.ibm.io
metadata:
name: <secret_name>
namespace: <namespace_name>
stringData:
encrypted: <true_or_false>
data
encryptionKey: <encryption_key>

name
: Enter a name for your secret.

namespace
: Enter the namespace where you want to create your secret.

encrypted
: In the parameters, enter true to set up encryption for your Block Storage for Classic volumes.
Instead, use [Kubernetes secrets](https://cloud.ibm.com/docs/openshift?topic=openshift-securitypi), such as an image pull secret for registry credentials. You can then reference these secrets in your deployment YAML file.

Secret encryption
: You can encrypt the Kubernetes secrets that you create in your cluster by using a key management service (KMS) provider. To get started, see [Encrypt secrets by using a KMS provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkeyprotect) and [Verify that secrets are encrypted](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionverify_kms).

Pod traffic management
: [Kubernetes network policies](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesisolate_services) protect pods from internal network traffic. For example, if most or all pods don't require access to specific pods or services, and you want to ensure that pods by default can't access those pods or services, you can create a Kubernetes network policy to block ingress traffic to those pods or services. Kubernetes network policies can also help you enforce workload isolation between namespaces by controlling how pods and services in different namespaces can communicate. For clusters that run Kubernetes 1.21 and later, the service account tokens that pods use to communicate with the Kubernetes API server are time-limited, automatically refreshed, scoped to a particular audience of users (the pod), and invalidated after the pod is deleted. To continue communicating with the API server, you must design your apps to read the refreshed token value on a regular basis, such as every minute. For more information, see [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md).
Depending on your use case and security requirements, the key management service that is most suited for your organization's needs can vary. To learn more about which key management solution is best for you, see [How is Hyper Protect Crypto Services different from Key Protect?](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-basicsfaq-differentiators-key-protect)





 Enabling customer-managed keys for Secrets Manager 

If you choose to work with a key that you manage, you must ensure that valid IAM authorization is assigned to the instance of Secrets Manager that you're working with. To create that authorization, you can use the following steps.



1. Create an instance of [Key Protect](https://cloud.ibm.com/catalog/services/key-protect) or [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hs-crypto).
2. [Generate or import a root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) to your key management service instance.

When you use Key Protect or Hyper Protect Crypto Services to create a root key, the service generates cryptographic key material that is rooted in cloud-based HSMs. Be sure that the name of your key does not contain any personal information such as your name or location.
3. Grant service access to Key Protect or Hyper Protect Crypto Services.

You must be the account owner or an administrator for the instance of the key management service that you're working with. You must also have at least Viewer access for the Secrets Manager service.



1. Go to Manage > Access IAM > Authorizations.
2. Select the Secrets Manager service as the source service.
3. Select the instance of the Key Protect or Hyper Protect Crypto Services as the target service.
4. Select the key that you created in the previous steps.
5. Assign the Reader role.
6. Click Authorize to confirm the authorization.
2. Click Services, then click your Key Protect instance.
3. Find your root key on the Actions Menu, then click View CRN.
4. Click the Copy button to copy the CRN.



2. Create the secret in your cluster.

oc apply -f secret.yaml
3. Verify that your secret was created.

oc get secrets



15. Choose between the following options to create a Block Storage for Classic instance that encrypts data with your root key.



* [Create a custom storage class that references your Key Protect secret](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageencrypt_custom_sc).
* [Define the secret in a PVC and use one of the provided storage classes](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storagepvc_encrypt_label).







 Encrypting volume data by using a custom storage class 

You can deploy apps that use encrypted volumes by first creating a custom storage class.

The following steps explain how to create a custom, encrypted storage class that you can use to create multiple encrypted block storage instances with the same configuration. If you want to create an encrypted PVC by using one of the IBM-provided storage classes, you can do this by [referencing the Key Protect credentials directly in your PVC](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storagepvc_encrypt_label).



1. [Decide on a storage configuration](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_predefined_storageclass).
2. Create a custom storage class that provisions an encrypted block storage instance by using one of the IBM-provided storage classes as the basis. You can retrieve the details a storage class by running oc get storageclass <storageclass_name> -o yaml.
If you're using Hyper Protect Crypto Services, see the [Hyper Protect Crypto Services information](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) for corresponding instructions.



1. Provision the [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provision) service.

Provisioning a new Key Protect service instance ensures that it includes the most recent updates that are required for customer-managed encryption of your resources.
2. [Create](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) or [import](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-root-keys) a customer root key (CRK) in IBM Key Protect.

Plan ahead for importing keys by [reviewing your options for creating and encrypting key material](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keysplan-ahead). For added security, you can enable the secure import of the key material by using an [import token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keysusing-import-tokens) to encrypt your key material before you bring it to the cloud.
3. From IBM Cloud Identity and Access Management (IAM), [authorize access](https://cloud.ibm.com/docs/account?topic=account-serviceauthserviceauth) between Cloud Block Storage or Cloud File Storage (source service) and Key Protect(target service) for volumes. For custom images, authorize between Image Service for VPC (source service) and IBM Cloud Object Storage (target service). Specify reader access for the role.

You might need to upgrade your account to a Pay-as-you-go account to complete this set.
* For the Authentication field, select sha256.
* For the Encryption field, select aes256.
* For the DH Group field, select 19.
* For the Key lifetime field, specify 86400.



3. When you create the VPN connection in your VPC, select this custom IKE policy.







 Creating a custom IPsec policy for Check Point Security Gateway 

To use a custom IPsec policy in VPN for VPC:



1. On the VPN for VPC page in the IBM Cloud console, select the IPsec policies tab.
2. Click New IPsec policy and specify the following values:



* For the Authentication field, select sha256.
* For the Encryption field, select aes256.
* For the Key lifetime field, specify 3600.



3. When you create the VPN connection in your VPC, select this custom IPsec policy.







 Ensuring NAT-T is always on 

Make sure that the NAT-T feature is enabled on your on-premises VPN device. The following list shows the default behaviors:



* NAT-T is enabled when a NAT device is detected.
* offer_nat_t_initator is set to false (initiator sends NAT-T traffic).
* offer_nat_t_responder_for_known_gw is set to true (responder accepts NAT-T traffic from known gateways).
* force_nat_t is set to false (forces NAT-T, even if there is no NAT-T device).



It is recommended to change these default settings to the following:



* Enable NAT-T.
* Set offer_nat_t_initator to true.
* If you know that there's no NAT device in the environment, set force_nat_t to true.



You can view and change these variables by using the GuiDBedit Tool. Refer to the Check Point documentation for your particular version to confirm these steps.



1. In the upper-left pane, click TABLE > Network Objects > network_objects.
2. In the upper-right pane, select the applicable Security Gateway object.
Go to your instance of Hyper Protect Crypto Services and [create a root key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-create-root-keys) or [import an existing root key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-import-root-keys).







 Step 2. Grant service authorization 

Authorize Hyper Protect Crypto Services for use with Hyper Protect DBaaS for PostgreSQL service instances:



1. Go to the IBM Cloud console.
2. From the menu bar, click Manage > Access (IAM).
3. In the side navigation, click Authorizations.
4. Click Create.
5. In the Source service menu, select Hyper Protect DBaaS for PostgreSQL.
6. In the Source service instance menu, select All service instances.
7. In the Target service menu, select Hyper Protect Crypto Services.
8. In the Target service instance menu, select the service instance to authorize.
9. Enable the Reader role.
10. Click Authorize.



If you want to remove an authorization, see [Removing access](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesremoving-access-console).





 Step 3. Create a Hyper Protect DBaaS for PostgreSQL instance with the Hyper Protect Crypto Services Key 

When you [create a Hyper Protect DBaaS for PostgreSQL service instance](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-postgresql?topic=hyper-protect-dbaas-for-postgresql-gettingstartedcreating-a-database-cluster-introduction), select your Hyper Protect Crypto Services instance and root key.

The new Hyper Protect DBaaS for PostgreSQL service instance uses your Hyper Protect Crypto Services root key to protect your data encryption key.