vania-janet/multiturn-rag-retrieval-data huggingface dataset:
POST /keys/{root_key_ID}/actions/wrap [Wrap (encrypt) a data encryption key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-wrap-keys) 
 POST /keys/{root_key_ID}/actions/unwrap [Unwrap (decrypt) a data encryption key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-unwrap-keys) 



To find out more about programmatically managing your keys in Key Protect, check out the [Key Protect API reference doc](https://cloud.ibm.com/apidocs/key-protect).







 Integrating a supported service 

To add an integration, create an authorization between services by using the IBM Cloud® Identity and Access Management dashboard. Authorizations enable service to service access policies, so you can associate a resource in your cloud data service with a [root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryptionkey-types) that you manage in Key Protect.

Be sure to provision both services in the same region before you create an authorization. To learn more about service authorizations, see [Granting access between services](https://cloud.ibm.com/docs/account?topic=account-serviceauth).

When you're ready to integrate a service, use the following steps to create an authorization:



1. From the menu bar, click Manage > Access (IAM), and select Authorizations.
2. Click Create.
3. Select a source and target service for the authorization.

For Source service, select the cloud data service that you want to integrate with Key Protect

For Target service, select IBM Key Protect.
4. Enable the Reader role.

With Reader permissions, your source service can browse the root keys that are provisioned in the specified instance of Key Protect.
5. Click Authorize.







 What's next 

Add advanced encryption to your cloud resources by creating a root key in Key Protect.
* Keys: A key object stores a cryptographic key. The key can be a public key, a private key, or a secret key. Each type of these keys has subtypes for use in specific mechanisms.



* Public key: The public component of a key pair that is used by anyone to encrypt messages intended for a particular recipient that has access to the private key of the key pair. The public key is also used to verify signatures created by the private key.
* Private key: The private component of a key pair that is used to decrypt messages. The private key is also used to create signatures.
* Secret key: A secret key is a generated stream of bits that is used to encrypt and decrypt messages symmetrically.





Zoom

![PKCS #11 object classes](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/hs-crypto//images/object-class.svg)

Figure 2. PKCS #11 object classes

Currently, the data object class is not supported and only X.509 Public Key Certificate objects are supported in this implementation.





 Cloud Identity and Access Management 

IBM Cloud Identity and Access Management (IAM) provides user authentication and access control for the implementation of the PKCS #11 API. By using API keys, the PKCS #11 library obtains bearer tokens that are used to perform Cryptoki API calls.

This implementation of PKCS #11 equates an API key with a user's PIN. For more information about setting up the service ID and the corresponding API key, see [Create service IDs for the SO user, normal user, and anonymous user](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-best-practice-pkcs11-accessstep2-create-service-id-api-key).





 Crypto service 

As part of the PKCS #11 library initialization process, a gRPC connection is made from the PKCS #11 library to the IBM Cloud.
[Creating a Continuous Delivery service instance](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-create_cd_service)[Protecting your personal data when you use the Professional plan](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_data_securitycd_professional_plan) 







 Understanding your integration 

When you integrate a supported service with Key Protect, you enable [envelope encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption) for that service. This integration allows you to use a root key that you store in Key Protect to wrap the data encryption keys that encrypt your data at rest.

For example, you can create a root key, manage the key in Key Protect, and use the root key to protect the data that is stored across different cloud services.

Zoom

![The diagram shows a contextual view of your Key Protect integration.](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/key-protect/images/kp-integrations.svg)

Figure 1. Contextual view of Key Protect integration.



 Key Protect API methods 

Behind the scenes, the Key Protect API drives the envelope encryption process.

The following table lists the API methods that add or remove envelope encryption on a resource.



Table 6. Describes the Key Protect API methods.

 Method Description 

 POST /keys/{root_key_ID}/actions/wrap [Wrap (encrypt) a data encryption key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-wrap-keys) 
 POST /keys/{root_key_ID}/actions/unwrap [Unwrap (decrypt) a data encryption key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-unwrap-keys)
The LUKS passphrase is then encrypted by a root key, which creates a WDEK. To decrypt data, the WDEK is unwrapped so you can access the data that's stored on the volume. This process is possible only by accessing the root key that is stored in your KMS instance. Root keys in HPCS service instances are also protected by a

hardware security module (HSM)master key.

You control access to your root keys stored in KMS instances within IBM Cloud® by using IBM Cloud® Identity and Access Management (IAM). You grant access to a service to use your keys. You can also revoke access at any time, for example, if you suspect your keys might be compromised, or [delete your root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-mng-datadelete-root-keys).

VPN for VPC: Customer-provided preshared keys are encrypted before they are stored in database. All other data VPN gateway and VPN policy configuration is encrypted at rest at the database level.



 About customer-managed keys 

For block storage volumes and encrypted images, you can rotate the root keys for more security. When you rotate a root key by schedule or on demand, the original key material is replaced. The old key remains active to decrypt existing resources but can't be used to encrypt new ones. For more information, see [Key rotation for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-key-rotation).

Consider regional and cross-regional implications when you choose to use customer-managed encryption. For more information, see [Regional and cross regional considerations](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutbyok-cross-region-keys).

With Key Protect or HPCS you can create, import, and manage your root keys. You can assign access policies to the keys, assign users or service IDs to the keys, or give the key access only to a specific service.
* Snapshots that are created from boot and data volumes inherit the customer-managed encryption from the source volume.



Encrypt file shares:



* File share data is always encrypted with your own keys at rest.
* You control the number and usage of root keys to use for envelope encryption at the file shares level. That is, you can choose to encrypt all your file shares with same root key or each file share with different keys. Alternatively, you can encrypt some file shares with one root key and others with different root keys. You have complete flexibility to implement your root key usage based on your individual security needs.
* Manage the root keys for your file shares by rotating, disabling, or deleting keys. You can restore deleted keys within 30 days after their deletion.



IBM Cloud® File Storage for VPC is available for customers with special approval to preview this service in the Frankfurt, London, Madrid, Dallas, Toronto, Washington, Sao Paulo, Sydney, Osaka, and Tokyo regions. Contact your IBM Sales representative if you are interested in getting access.

Encrypt your custom images:



* You can [manually encrypt](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-imagemanually-encrypt-image) an image by creating a encrypted copy of it by used QEMU.
* You can create encrypted [custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-image) from encrypted boot volumes. For more information, see [About encrypted custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutbyok-about-encrypted-images).



Excellent performance:



* BYOK uses hypervisor encryption on the VPC infrastructure, which delivers excellent encrypted Block Storage for VPC I/O performance for your virtual server instances.
Data security and encryption 

IBM® Netezza® Performance Server for IBM Cloud Pak® for Data as a Service has security built into its architecture.

The following methods are used to secure your connection and data:



*  All the connections to the database server are TLS 1.2 connections.
*  Netezza Performance Server supports the following suites of Cipher with 2048 bit RSA key size for TLS communication:



*  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
*  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
*  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
*  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
*  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
*  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256



*  User data is stored on secure reliable storage (as a service) from the cloud providers.
For Azure, Azure Premium disks.
For AWS, Amazon Elastic Block Store (EBS).
*  The data is encrypted at rest by using cloud provider key management service.
*  Snapshots are stored on Cloud Object Storage (COS), which is replicated across AZs in the region in which it was created and are encrypted at rest and in transit.





  Data deletion 

When you delete an instance, all the data and snapshots associated with the instance are deleted immediately.
Securing your data in App ID 

To ensure that you can securely manage your data when you use IBM Cloud® App ID, it is important to know exactly what data is stored and encrypted and how you can delete any stored personal data.



 How your data is stored and encrypted in App ID 

App ID stores and encrypts user profile attributes. As a multi-tenant service, every tenant has a designated encryption key and user data in each tenant is encrypted with only that tenant's key. App ID ensures that private information is encrypted before it is stored.

You can add a higher level of encryption control to your data at rest (when it is stored) by enabling integration with a Key Management Service (KMS). The data that you store in IBM Cloud is encrypted at rest by using envelope encryption. If you need to control the encryption keys, you can integrate Key Protect or Hyper Protect Crypto Services. This process is commonly referred to as Bring Your Own Key (BYOK). With Key Protect and Hyper Protect Crypto Services, you can create, import, and manage encryption keys. You can assign access policies to the keys, assign users or service IDs to the keys, or give the key access only to a specific service.





 Managing your own keys 

App ID uses envelope encryption to implement both provider-managed and 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 KMS. Key Protect keys are secured by FIPS 140-2 Level 3 certified cloud-based hardware security modules (HSMs), and Hyper Protect Crypto Services keys are secured by FIPS 140-2 Level 4 certified cloud-based HSMs.



 Enabling customer-managed keys for App ID by using Key Protect
Unwrap the ciphertext to reveal the original DEK (plaintext) and a new ciphertext (the new ciphertext is the plaintext wrapped with the new rotated root key)
6. Unwrap the new ciphertext to reveal the original DEK (plaintext)



 create a root key
$ KEY_ID=$(ibmcloud kp key create my-root-key --output json | jq -r '.["id"]')

$ echo $KEY_ID

5b976173-7804-4f82-acfa-bb98098bc528

 create a random, base64-encoded, 32-byte data encryption key (DEK)
$ PLAINTEXT=$(openssl rand -base64 32)

$ echo $PLAINTEXT

UPJ4YDwbQMjQG/aqlHsPhHV1CBkpIXngLHFS5+i4UZ4=

 wrap the plaintext key with the root key, creating a DEK (this is the ciphertext)
$ CIPHERTEXT=$(ibmcloud kp key wrap $KEY_ID -p $PLAINTEXT --output json | jq -r '.["Ciphertext"]')

$ echo $CIPHERTEXT

eyJjaXBoZXJ0ZXh0IjoiQkFrTlJrS2Q0 ...<redacted>... ODA5OGJjNTI4In0=

 rotate the root key
$ ibmcloud kp key rotate $KEY_ID

Rotating root key...
OK

 show key details
$ ibmcloud kp key show $KEY_ID --output json

{
"id": "5b976173-7804-4f82-acfa-bb98098bc528",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"algorithmType": "AES",
You can describe storage classes in the command line with the oc describe sc <storage-class-name> command. Note that data volumes are automatically encrypted by an AWS managed default key. For more information, see [Default KMS key for EBS encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.htmlEBSEncryption_key_mgmt). For more information on AWS EBS encryption, see [How AWS EBS encryption works](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.htmlhow-ebs-encryption-works).



Table 2. AWS EBS storage class reference.

 Storage class name EBS volume type File system type Provisioner Default IOPS per GB Size range Hard disk Encrypted? Volume binding mode Reclaim policy More info 

 sat-aws-block-goldDefault io2 ext4 ebs.csi.aws.com 10 10 GiB - 6.25 TiB SSD True WaitforFirstConsumer Delete [Link](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.htmlsolid-state-drives) 
 sat-aws-block-silver gp3 ext4 ebs.csi.aws.com N/A 1 GiB - 16 TiB SSD True WaitforFirstConsumer Delete [Link](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.htmlsolid-state-drives) 
 sat-aws-block-bronze st1 ext4 ebs.csi.aws.com N/A 125 GiB - 16 TiB HDD True WaitforFirstConsumer Delete [Link](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.htmlhard-disk-drives)
The current supported version of this encryption is TLS 1.2.
* The storage where the configuration is stored is encrypted with LUKS using AES-256.







 Auditing data 

You can define 1 or more routing rules that define how auditing events are routed in the account. Auditing data from an IBM Cloud service to your target service in IBM Cloud is secure via private connection. The connection supports TLS 1.2.

You can store auditing data to any of the following target types:



* An IBM Cloud Object Storage bucket: You create and manage the bucket, and the data that is collected in the bucket. For more information about COS data security, see [Data security](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-security).
* An Activity Tracker instance: You manage the instance and the data that is collected in the instance. For more information, see [Data security](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-mng-data).









 How can you delete any stored data 



 Configuration data 

Activity Tracker Event Routing stores configuration data only.

You can delete any route, target and account setting configuration by using the API, the CLI or terraform scripts.



* To stop Activity Tracker Event Routing from routing audit events to the configured targets, you must [remove any default targets](https://cloud.ibm.com/docs/atracker?topic=atracker-target-default-reset) and delete all routes.
* To delete auditing event destinations, you must delete the target definitions.
* To remove any account setting, you can reset the account default settings.







 Auditing data 

To delete auditing data, check the target type instructions.



* For IBM Cloud Object Storage bucket, see [Data security](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-security).
Single Data Center distributes objects across multiple machines within the same physical location.

Users of Object Storage refer to their binary data, such as files, images, media, archives, or even entire databases as objects. Objects are stored in a bucket, the container for their unstructured data. Buckets contain both inherent and user-defined metadata. Finally, objects are defined by a globally unique combination of the bucket name and the object key, or name.

All Object Storage buckets must be encrypted with KYOK by using keys that are managed by Hyper Protect Crypto Services. For more information, see [Encryption at rest](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-at-rest). In addition, a geographically separate region should be used as an [alternative storage site](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-bcdryour-workloads-requirements-alternate-storage-site). This means you should use [cross region resiliency](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints-geo) for all of your Object Storage buckets.

To start working with Object Storage, see the following instructions:



* [Getting started with Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage)
* [Connecting to Object Storage from VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-connecting-vpc-cos)
* [Encrypting your data](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-encryption)









 Storage in Satellite location 

Within the Satellite location, Satellite storage uses Satellite Config to provide a convenient way to install various storage drivers in Red Hat OpenShift on IBM Cloud clusters, by using storage templates. The storage templates are provided and tested by the vendors.
What are master encryption keys and how are they assigned to my Block Storage for VPC volumes? 

Each volume is assigned a unique master encryption key, called a data encryption key or DEK, which is generated by the instance's host hypervisor. The master key for each Block Storage for VPC volume is encrypted with a unique KMS-generated LUKS passphrase, which is then encrypted by your customer root key (CRK) and stored in the KMS. Passphrases are AES-256 cipher keys, which means that they are 32 bytes long and not limited to printable characters. You can view the cloud resource name (CRN) for the CRK that is used to encrypt a volume. However, the CRK, LUKS passphrase, and the volume's master encryption key are never exposed. For more information about all the keys IBM VPC uses to secure your data, see [IBM's encryption technology - How your data is secured](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutbyok-technologies).
* I use customer-managed encryption for my volumes. What happens when I disable or delete my root key?

 I use customer-managed encryption for my volumes. What happens when I disable or delete my root key? 

These actions are two separate actions. Disabling a root key in your KMS suspends its encryption and decryption operations, placing the key in a suspended state. Workloads continue to run in virtual server instances and boot volumes remain encrypted. Data volumes remain attached. However, if you power down the VM and then power it back on, any instances with encrypted boot volumes do not start. You can enable a root key in a suspended state and resume normal operations. For more information, see [Disabling root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managingbyok-disable-root-keys).

Deleting a root key has greater consequences.
You can enable encryption by creating a Kubernetes secret that uses your personal API key as long as you have the Reader service access role for your Key Protect instance as well as the Viewer platform access role and the Writer service access role for your cluster.

[Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. Make sure that you are assigned the Editor platform access role and the Writer service access role for Key Protect so that you can create your own root key that you use to encrypt your Block Storage for Classic instance. You can review your IAM access roles in the [IAM console](https://cloud.ibm.com/iam). For more information about IAM roles, see [IAM access](https://cloud.ibm.com/docs/account?topic=account-userroles).
2. If you don't have a Key Protect instance, [provision one](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provision).
3. [Create a root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys). By default, the root key is created without an expiration date.
4. Create an IAM service ID. Replace <service_ID_name> with the name that you want to assign to your service ID. This service ID is used to access your Key Protect instance from your Block Storage for Classic volume.

ibmcloud iam service-id-create <service_ID_name>

Example output

OK
Service ID test-id is created successfully

ID ServiceId-a1a11111-bb11-1111-a11b-1111111a11ba
Name test-id
Description
Encrypting images for content confidentiality 

You can protect the confidentiality of your IBM Cloud® Container Registry images, and ensure that hosts that aren't trusted can't run the images.

Create an encrypted image so that people without the

private keycan't access the content. Create the encrypted image by using an RSA public-private key pair to encrypt and decrypt the image. A public key is not a secret and anyone can use it to encrypt an image. A private key is a secret, and only users that have that private key can use it to decrypt the image.

Encryption is supported in IBM Cloud Container Registry and complies with the following standards:



* [opencontainers/image-spec](https://github.com/opencontainers/image-spec)
* [opencontainers/artifacts](https://github.com/opencontainers/artifacts/pull/15)



For more information about encrypting images, see [Advancing container image security with encrypted container images](https://developer.ibm.com/articles/advancing-image-security-encrypted-container-images/) and [Advancing image security and compliance through Container Image Encryption](https://www.youtube.com/watch?v=dYXhAxxPkqA).



 Before you begin 



* Complete the instructions in [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started).
* Ensure that you have the most recent version of the container-registry CLI plug-in for the IBM Cloud CLI, see [Updating the container-registry CLI plug-in](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_cli_update).
All cryptographic operations, such as key creation and key rotation, are performed within the HSM. IBM periodically rotates the HSM's master keys, providing an extra layer of security. 
 Customer-managed encryption keys Root keys are symmetric keys that protect data encryption keys with [envelope encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption). Root keys never leave the boundary of the HSM. 
 Dedicated key storage Key metadata is stored in highly durable, dedicated storage for Key Protect that is encrypted at rest with additional application layer encryption. 
 Fine-grained access control Key Protect leverages IBM Cloud IAM roles to ensure that users can be assigned appropriate access at the instance, key, and key ring level.