vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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.
2. 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, Db2.
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 your Db2 on Cloud deployments permission to use your keys, you supply the key name or CRN in [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keys) or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-keys) when you provision a deployment. The deployment uses your encryption key to encrypt your data.

If you provision a deployment through the CLI or API, the key needs to be identified by its full CRN, not just its ID. A CRN is in the format crn:v1:<...>:key:<id>.





 Deleting the deployment
You can use a root key that you manage in [Key Protect](https://cloud.ibm.com/catalog/services/key-protect) or [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hs-crypto). 





 About customer-managed keys 

Secrets Manager uses envelope encryption to implement customer-managed keys. Envelope encryption describes encrypting one encryption key with another encryption key. The key used to encrypt the actual data is known as a

data encryption key (DEK). The DEK itself is never stored but is wrapped by a second key that is known as the key encryption key (KEK) to create a wrapped DEK. To decrypt data, the wrapped DEK is unwrapped to get the DEK. This process is possible only by accessing the KEK, which in this case is your root key that is stored in your key management service.

You can encrypt the data that you store in Secrets Manager by using the Bring Your Own Key process (BYOK), which is supported by Key Protect. With this multi-tenant service, you can import your encryption keys from the on-premises hardware security modules (HSM), then manage the keys. If you would like exclusive control of the entire key hierarchy, which includes the master key, you can use the Keep Your Own Key (KYOK) process, which is supported by Hyper Protect Crypto Services. With KYOK, in addition to the BYOK capabilities, you have the technical assurance that even IBM cannot access your keys. [Learn more](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-basicsfaq-differentiators-KYOK).

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)
For more information, see [Inviting users to an account](https://cloud.ibm.com/docs/account?topic=account-iamuserinv).
3. From the options menu, click Assign access.
4. Click Access policy.
5. Under Service, select Hyper Protect Crypto Services and click Next.
6. Under Resources, select resources that you want to assign access to and click Next:



* If you want to assign the user access to all the Hyper Protect Crypto Services instances under your account, select All resources.
* If you want to assign the user access to part of the Hyper Protect Crypto Services resources under you account, select Specific resources and add the corresponding conditions based on your needs. For example, select the Service Instance ID and specify the instance from the list.



7. Under Roles and actions, choose a combination of [platform and service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessroles) to assign access for the user and click Next.



* Check the box for at least the Viewer role under Platform access.
* Check the box for the corresponding custom role that you set up in [Step 1](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grant-pkcs11-ui-accessstep1-create-custom-roles-pkcs11-ui) based on your needs.



If you don't have any custom roles, you can select the existing IAM roles that cover the actions that you want to assign to the user. You can view the specific actions that correspond to the role by clicking the number.
8. (Optional) Under Conditions (optional), click Review to check the access policy.
9. After confirmation, click Add > Assign.







 What's next
* Make a [plan for your virtual private endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-considerations).
* Ensure that [correct access controls](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-configuring-acls) are set for your virtual private endpoint.
* Understand the [limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations-vpe) of having a virtual private endpoint.
* Understand how to [view details](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-viewing-details-of-an-endpoint-gateway) about a virtual private endpoint.







 Setting up a VPE for Hyper Protect Crypto Services 

When you create a VPE gateway by using the CLI or API, you must specify the [Cloud Resource Name (CRN)](https://cloud.ibm.com/docs/account?topic=account-crn) of the region in which you want to connect to Hyper Protect Crypto Services. Review the following table for the available regions and CRNs to create your VPE gateways.



Table 1. Available region endpoints and CRNs for creating VPE gateways

 Hyper Protect Crypto Services feature Supported endpoints CRN 

 Key management service api.private.au-syd.hs-crypto.cloud.ibm.com crn:v1:bluemix:public:hs-crypto:au-syd:::endpoint:api.private.au-syd.hs-crypto.cloud.ibm.com 
 Key management service api.private.eu-de.hs-crypto.cloud.ibm.com crn:v1:bluemix:public:hs-crypto:eu-de:::endpoint:api.private.eu-de.hs-crypto.cloud.ibm.com
Create a [service ID](https://cloud.ibm.com/docs/account?topic=account-serviceids), [API key](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeys), and [access policy](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources) that allows access to either Hyper Protect Crypto Services and Red Hat OpenShift on IBM Cloud or Key Protect and Red Hat OpenShift on IBM Cloud. Make a note of the API that you create.



[Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



1. List your namespaces to determine whether you have an openshift-storage namespace. If you don't have an openshift-storage namespace, create it.

oc get namespaces | grep openshift-storage



1. Create an openshift-storage namespace in your cluster. The driver pods are deployed to this namespace. Copy the following YAML and save it as os-namespace.yaml on your local machine.

apiVersion: v1
kind: Namespace
metadata:
labels:
openshift.io/cluster-monitoring: "true"
name: openshift-storage
2. Create the openshift-storage namespace by using the YAML file that you saved.

oc create -f os-namespace.yaml
3. Verify that the namespace is created.

oc get namespaces | grep storage



2. Encode both the ID of your root key and the API key of the service ID that you created to base64.

printf "ROOT-KEY-ID" | base64

printf "SERVICE-ID-API-KEY" | base64
3. Create the Kubernetes secret in the openshift-storage namespace that uses your Hyper Protect Crypto Services credentials.



1.
Key Protect integration 

The data that you store in IBM® Db2® Warehouse on Cloud is encrypted by default 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) to create, add, and manage encryption keys. Then, you can associate those keys with your Db2 Warehouse on Cloud deployment to encrypt your Db2 databases.

To get started, you need [Key Protect](https://cloud.ibm.com/catalog/services/key-protect) provisioned on your IBM Cloud account.



  Creating or adding 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).





  Granting service authorization 

Authorize Key Protect for use with Db2 Warehouse on Cloud deployments:



1.  Open your IBM Cloud dashboard.
2.  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, Db2 Warehouse.
5.  In the Source service instance menu, select All service instances.
6.  In the Target service menu, select Key Protect.
7.  In the Target service instance menu, select the service instance to authorize.
8.  Enable the Reader role. Click Authorize.







  Using the Key Protect key 

After you grant your Db2 Warehouse instance permission to use your keys, you supply the Key Protect information on the Console Administration -> Security -> Manage Keys tab. You must provide the name of the Key Protect instance and the key that was created in the "Creating or adding a key in Key Protect" section. After the information is provided, you then migrate the instance to Key Protect managed keys.
Restrict access to resources by using Cloud IAM access policies by defining IAM policies to control which users within your account have access to the data. <br>[Learn more about controlling access through IAM](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iam). 







 Security and regulation compliance 



Table 4. Responsibilities for security and regulation compliance

 Task IBM Responsibilities Your Responsibilities 

 Encrypt data Encrypt data in motion and at rest per compliance specifications. Ensure encryption of archived data by configuring a COS bucket that has full control over the data encryption keys that are used. [IBM Cloud® Object Storage provides several options to encrypt your data.](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-encryption) 
 Meet security and compliance objectives Maintain controls that are commensurate to various industry compliance standards such as SOC2, PCI, HIPAA and Privacy Shield. Set up and maintain security and regulation compliance for your apps and data. This includes: <br>[Defining the account management strategy](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-adoptionadoption_account) <br>[Configuring the accounts settings for compliance](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-adoptionadoption_acc_settings) <br>[Define IAM Strategy](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-adoptionadoption_iam) <br>[Define the notification strategy](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-adoptionadoption_alerts) 







 Disaster recovery 



Table 5. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Restore functionality for Activity Tracker[] Automatically recover and restart Activity Tracker components after any disaster event.
[Transparent Database Encryption by using the standard PKCS #11 API](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/hs-crypto/images/pkcs-database.svg)

Figure 1. Transparent Database Encryption by using the standard PKCS #11 API

In this setup, the Oracle Database is to call operations to manage the TDE master encryption keys on the Hyper Protect Crypto Services PKCS #11 library. The Hyper Protect Crypto Services PKCS #11 library interacts with your Hyper Protect Crypto Services instance, which provides the best of class technology for storing and managing your TDE master encryption keys.





 Before you begin 

To complete this tutorial, you need to meet the following prerequisites:



* [Sign up an IBM Cloud account](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-signing_required_accountssigning_required_accounts-cloud).
* [Provision a Hyper Protect Crypto Services instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-provision).







 Task flow 

To complete this solution, let's walk through the following steps:



1. [Initialize your Hyper Protect Crypto Services instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-tde-pkcs11tutorial-tde-initialize).
2.

[Set up the Hyper Protect Crypto Services PKCS #11 library in your Oracle Database environment](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-tde-pkcs11tutorial-tde-pkcs11-setup).
3.
For proper protection and encryption, store personal information in [secrets](https://kubernetes.io/docs/concepts/configuration/secret/) instead.
: For centralized management of all your secrets across clusters and injection at application runtime, try [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-tutorial-kubernetes-secrets).

Use a Kubernetes imagePullSecret to store image registry credentials
: Do not store personal information in container images or registry namespaces. For proper protection and encryption, store registry credentials in [Kubernetes imagePullSecrets](https://cloud.ibm.com/docs/containers?topic=containers-registryother) and other personal information in [secrets](https://kubernetes.io/docs/concepts/configuration/secret/) instead. Remember that if personal information is stored in a previous layer of an image, deleting an image might not be sufficient to delete this personal information.

To set up encryption for your secrets, see [Encrypting Kubernetes secrets by using a key management service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect).





 Kubernetes security bulletins 

If vulnerabilities are found in Kubernetes, Kubernetes releases CVEs in security bulletins to inform users and to describe the actions that users must take to remediate the vulnerability. Kubernetes security bulletins that affect IBM Cloud Kubernetes Service users or the IBM Cloud platform are published in the [IBM Cloud security bulletin](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security).

Some CVEs require the latest patch update for a Kubernetes version that you can install as part of the regular [cluster update process](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) in IBM Cloud Kubernetes Service. Make sure to apply security patches in time to protect your cluster from malicious attacks.
Configure RBAC for an application 

Role-Based Access Control (RBAC) allows you to create policies that specify permissions for groups of users who access a Data Security Broker Shield. To configure RBAC, you need to add and manage user's client addresses, user IDs to defined groups. You need to map each user group to a permission (such as READ, READ_WRITE, or MASK) and a column in a table. In other words, RBAC policies determine who can see what data.

This RBAC configuration process is divided among four tasks:



1. Specify RBAC Configuration
2. Add User Groups
3. Create an RBAC policy
4. Apply an RBAC policy to columns





 Specify RBAC configuration 

To specify RBAC configuration for an application, complete the following steps:



1. In Data Security Broker Manager, navigate to Applications, select an application from the list, and click Encrypt to access the Encryption Schema Builder.
2. In the Data Protection Policies section, expand RBAC and select RBAC Configuration.
3. In the RBAC Configuration window on the right, click Complete Configuration.
4. In the window on the right, select a Mode from the drop-down list:



* Disable switches off RBAC for the whole application. Definitions of policies and groups do not change but the shield does not use these policies. You can select this mode to start and define users and policies.
* Supported switches on RBAC but does not require it for all connections to the Shield.
* Required switches on RBAC and requires it for all sessions or transactions on the Shield. If the session or transaction is not found in a defined RBAC Policy, then that session is dropped by the Shield.



5. Select an option for User Determination from the drop-down list:



* SESSION signifies that the users connecting to the Shield are determined by the session user ID, as defined in the specified User Groups.
* SQL_COMMENT_RAW signifies that users connecting to the Shield are determined by user IDs specified in SQL comments. An SQL Comment Prefix field appears. This field defines the prefix string for SQL Comments containing the User ID.
* [Create fine-grained personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-tokencreating-a-fine-grained-personal-access-token).
* [Restrict access by fine-grained personal access tokens](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organizationrestricting-access-by-fine-grained-personal-access-tokens).
* [Create personal access tokens (classic)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-tokencreating-a-personal-access-token-classic).
* [Restrict access by personal access tokens (classic)](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organizationrestricting-access-by-personal-access-tokens-classic).







 Can I run the terraform init -backend-config="KEY=VALUE" option through CLI? 

Schematics does not support you the ability to edit the Terraform [backend configuration](https://developer.hashicorp.com/terraform/language/settings/backends/configurationpartial-configuration). Schematics internally manages the [state-file](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-referencestate-file-cmds), in its own COS bucket, that are encrypted by using [envelop encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption).
Enabling network access to your Key Protect instance with the console 

If you prefer to enable a dual authorization policy on your instance by using a graphical interface, you can use the IBM Cloud console.

After the network access policy is set to private-only the UI cannot be used for any Key Protect actions.

Keys in a private-only instance will not be shown in the UI and any Key Protect actions in the UI will return an unauthorized error (HTTP status code 401).

After creating a Key Protect instance, complete the following steps to create a network access policy:



1. [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. Click the Instance policies link on the left side of the page.



* Find the Network access allowed panel (on the top-right side of the page).
* Change the policy by selecting either Public and private (default) or Private only from the dropdown.
* Click Save or Cancel (whichever is appropriate).









 Enabling network access to your Key Protect instance with the API 

As an admin, enable a network access policy for a Key Protect instance by making a PUT call to the following endpoint. See these API references to [set](https://cloud.ibm.com/apidocs/key-protectset-instance-policies) and [list](https://cloud.ibm.com/apidocs/key-protectlist-instance-policies) instance policies.

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



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

To change a network access policy, you must be assigned a Manager access policy for your Key Protect instance.
* [Create a Hyper Protect Crypto Services with Unified Key Orchestrator instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-provision&interface=uiprovision-uko) in us-east and [initialize the service instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-initialize-instance-mode).







 Task flow 

To complete this solution, let's walk through the following steps:



1. [Deploy Key Protect on Satellite](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-uko-satellitetutorial-uko-satellite-deploy-kp).
2. [Connect Unified Key Orchestrator to Key Protect on Satellite](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-uko-satellitetutorial-uko-satellite-connect-uko-kp).
3. [Manage Key Protect keys through Unified Key Orchestrator](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-uko-satellitetutorial-uko-satellite-manage-kp-keys).



Let's start with the deployment of Key Protect on Satellite.





 Step 1: Deploy Key Protect on Satellite 

Deploy Key Protect on Satellite by following [the instruction](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-ui-deploy).





 Step 2: Connect Unified Key Orchestrator to Key Protect on Satellite 

After you deploy Key Protect on Satellite, you can now connect Unified Key Orchestrator to Key Protect to have a unified key management experience.



1. [Log in to the Hyper Protect Crypto Services instance](https://cloud.ibm.com/login).
2. Click Target keystores from the navigation and click Add keystore.
3. Under Vault, select a vault for the keystore for access control, and click Next.
* The bytes of data, for example 32 bytes for 256 bits, must be encoded by using base64 encoding.



4. Give the key a name that you can recognize and click Import key. Make sure that the key name does not contain personal information, such as your name or location.











 Step 3. Grant service access to Key Protect 

After you add a root key to Key Protect, you use Cloud Identity and Access Management (IAM) to authorize access between the Watson service and Key Protect.

You must be the account owner or administrator on the Key Protect service instance and at least the viewer role on all instances of the Watson services.



1. Go to the IAM [Authorizations](https://cloud.ibm.com/iam/authorizations) page. (From the IBM Cloud console menu bar, select Manage > Access IAM, and then click Authorizations.)
2. Click Create.
3. Select the Watson service as the Source service. Leave All resources selected to scope the access.
4. Select Key Protect as the Target service.
5. Select Resources based on selected attributes, and then select Instance ID for the target service attribute. One of the following criteria must be true to authorize:



* The IAM Policy authorizes a resource group that contains the Key Protect instance to target all instances of the dependent service.
* The IAM Policy authorizes a specific instance of Key Protect to target all instances of the dependent service.
* The IAM Policy authorizes a specific instance of Key Protect to target a resource group that the new instance of the dependent service would be created in.
* The IAM Policy authorizes a resource group that contains the Key Protect instance to target a resource group that the new instance of the dependent service would be created in.



Select the Key Protect service instance that you created earlier.
6. Authorize dependent services by selecting Enable authorization to be delegated. Delegation allows the Key Protect instance to propagate its authorizations to this service.
7. Make sure that the Reader role is enabled. Reader permissions allow the Watson service to see the root keys in the Key Protect instance.
8. Click Authorize and confirm delegated authorization.