vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If the source snapshot is not encrypted with a customer key, the encryption of the copy remains provider-managed. If the source snapshot is protected by a customer-managed key, you need to specify the customer-managed key that you want to use to encrypt the new copy.

The following example creates a snapshot in the target region (us-south) by using the CRN of a snapshot from the source region (us-east).

ibmcloud is snapshot-create --name my-cli-snapshot-crc --source-snapshot-crn crn:v1:staging:public:is:us-south:a/2d1bace7b46e4815a81e52c6ffeba5cf::snapshot:r134-b9590a48-63a3-445e-b819-3f2c0b82daf8

Creating snapshot my-cli-snapshot-crc under account Test Account as user test.user@ibm.com...

ID r142-bd4532c0-e73c-44f9-a017-89e5368c521a
Name my-cli-snapshot-crc
CRN crn:v1:staging:public:is:us-east:a/2d1bace7b46e4815a81e52c6ffeba5cf::snapshot:r142-bd4532c0-e73c-44f9-a017-89e5368c521a
Status pending
Clones Zone Available Created

Source volume ID Name Remote Region
r134-be21061a-4dc6-4c9f-b17d-421838fde399 -remote-421838fde399 us-south

Snapshot Copies ID Name Remote Region CRN Resource type

Bootable true
Encryption provider_managed
Encryption key -
Source Snapshot ID Name Remote Region CRN Resource type
To update ISV secrets, you must create a new registration definition file with the updated ISV secrets and use the same registration definition file when running the hpvs instance-update command to update the instance.

--no-isv-secrets
: If the image does not require any isv secrets, this parameter can be set. You need not provide the isv-secrets parameter, and if you do, it will be ignored.







 Using your OCI Image to provision a Hyper Protect Virtual Server 

You must use the [CLI](https://cloud.ibm.com/docs/hpvs-cli-plugin)ibmcloud hpvs instance-create command to use your own OCI Image to provision a Hyper Protect Virtual Server, as described [here](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-provisionprovision-cli).



 Example 

ibmcloud hpvs instance-create myServerName lite-s <location> --rd-path "C:MyRegistrationDefinitionsregistration.json.asc" -i latest







 Configuring your server 

The following topic describes how you can configure your server. Use this description only for configurations that are not considered credentials or personal data.

In this description "environment variables" are not set as environment variables, instead they provided within /.runqenv.

Instance-specific configurations for applications that run in OCI containers are generally provided as environment variables when a container is created. Either the application consumes the variables, or a script, that runs before the actual application, configures the application. Before you can set environment variables, the registration definition must allow them. You can provide environment variables by way of the e or --environment option (cannot contain “,”). The environment variables are written to /.runqenv.

You can allow environment variables by name to envs_whitelist array within the registration definition.
Custom images are private to the account where they are created, so the --visibility option is private.

ibmcloud is images --visibility private

For more information, see [ibmcloud is images](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referenceimages) in the VPC CLI reference page.





 Listing all images by using the API 

You can list all of the IBM Cloud VPC images in your region by using the application programming interface (API).

To list all images by using the API, use [List all images](https://cloud.ibm.com/apidocs/vpc/latestlist-images). Custom images are private to the account where they are created, so you can set the visibility property to private to retrieve only custom images.

curl -X GET ”$vpc_api_endpoint/v1/images?version=2022-11-21&generation=2" -H "Authorization: Bearer $iam_token"





 Viewing custom image details by using the UI 

You can view the following details of a custom image:



* Name and ID
* Assigned resource group
* Size
* Location
* Creation date
* Operating system and version
* Encryption type
* Deprecation date (if set)
* Obsolescence date (if set)



You can edit the name of the custom image, adds tags for searchability, and view and copy the unique Cloud Resource Name (CRN). The SHA256 checksum value for the image is accessible.

To view details for a custom image, complete the following steps.



1. In [IBM Cloud console](https://cloud.ibm.com/login), go to Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Compute > Images.
2.
buildah bud -t us.icr.io/<namespace>/<my_app> .

us.icr.io/<namespace>/<my_app> is committed to the local image store.
4. Encrypt the image by using the public key and upload the image to the registry by running the following commands and by specifying the JSON Web Encryption (jwe) protocol to encrypt the image, where <user_keys>/<user>Pub.pem is the encryption key.

buildah push --encryption-key jwe:..<user_keys>/<user>Pub.pem us.icr.io/<namespace>/<my_app>

Buildah version 1.15, or later, uses Docker’s login credentials to authenticate. If these credentials don't work or you want to use an

API key, you can supply the —-creds <user_name> option, where <user_name> is the username. If you use the —-creds <user_name> the option, when requested, type in the password of the registry credential.

You get a response that informs you that the manifest is written to the image destination, which is the registry.
5. Check in your registry to make sure that the image is there.







 Step 3: Pull and decrypt the image 

Pull the image from the registry and decrypt it by using the private key.



1. To ensure that you are pulling from the registry and that you are not using the local cache, remove the image locally:

buildah rmi -f us.icr.io/<namespace>/<my_app>
2. (Optional) You can try to pull the image without providing the decryption key to confirm that the image can't be decrypted:

buildah pull us.icr.io/<namespace>/<my_app>

The output contains a message similar to the following message:

...<truncated>...
oc create -n image-key-synchronizer secret generic --type=key --from-file=myprivatekey.pem <secret_name>
* To wrap the private key by using a Key Protect root key:



1. Encode your private key in base64, and copy the output.

cat myprivatekey.pem | base64
2. Use the Key Protect CLI plug-in to wrap the base64-encoded private key with your root key. In the output, copy the ciphertext of the wrapped private key.

ibmcloud kp key wrap <root_key_ID> -p <base64_encoded_private_key>
3. Save the wrapped private key as a Kubernetes secret in the image-key-synchronizer project.

apiVersion: v1
kind: Secret
type: kp-key
metadata:
name: <secret_name>
namespace: image-key-synchronizer
stringData:
rootkeyid: "<root_key_ID>"
ciphertext: "<wrapped_private_key_cipertext>"
4. Create the secret.

oc apply -n image-key-synchronizer -f <secret_name>.yaml





5. Use docker to locally pull an OCI image. Replace <source_image> with the repository of the image and <tag> with the tag of the image that you want to use, such as latest.

docker pull <source_image>:<tag>
6. Use skopeo to encrypt the local image. This command copies the OCI image that you previously pulled, uses your public key to encrypt the image, and saves the encrypted image to a different local file. Consider naming the encrypted image <source_image>_encrypted for easy identification.

skopeo copy --encryption-key jwe:./mypubkey.pem <source_image>:<tag> <source_image>_encrypted:<tag>
7.
To verify whether it is encrypted with a passphrase, run the ssh-keygen -p -f <ID_FILE> command.

ssh-keygen -p -f <ID_FILE>
Enter old passphrase:

ssh-keygen -p -f <ID_FILE>
Key has comment '<COMMENT>'
Enter new passphrase (empty for no passphrase):

You can escape the command by using Ctrl+C. If the command requires the old passphrase (first example), then the original file was encrypted, otherwise it directly asks for the passphrase of the new file (second example).

To decrypt an encrypted private key file, run the following command and leave the new passphrase empty.

$ ssh-keygen -p -f <ID_FILE>

Enter old passphrase: <PASSPHRASE>
Key has comment '<COMMENT>'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

This command modifies the private key file. If you need to retain your encrypted version, create a copy first.



To create an SSH secret and use the SSH protocol,



1. Run the [ibmcloud ce secret create --format ssh](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command. An SSH secret is also used as a Git repository access secret. The SSH_KEY_PATH needs to point to the private key file that matches the public key in your account or the deployment key in the repository. This command requires a name and a key path, and also allows other optional arguments such as the path to the known hosts file. If you specify the --known-hosts-path option, include the host of your Git repository, for example github.com or gitlab.com in your known hosts file.
While it is comparatively simple to [Base64-encode key material](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-root-keyshow-to-encode-root-key-material), it is important to follow [NIST guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) when creating your own key material. Improperly created key material can make your keys more susceptible to being compromised. Unless you feel confident in creating the appropriate key material yourself, the best practice is to let Key Protect create your key material for you as part of the key creation process, which follows the latest NIST guidelines.

Because this key material can be used to [create a functionally duplicate key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorialget-started-next-steps-best-practices-key-aliases), whether you have created the key material yourself or exported a Key Protect created key, make sure you keep this key material secure.
* UI
* CLI
* API







 Importing and validating custom images into VPC 

You can create your own custom image on premises and then import it to IBM Cloud® Virtual Private Cloud infrastructure from IBM Cloud® Object Storage. Then, you can use your custom image to create new virtual server instances that runs on the KVM hypervisor. If you plan to use your custom image in a private catalog, you must first import and validate the custom image into IBM Cloud VPC.

You can also create a custom image of a boot volume that is attached to a server at import time. For more information, see [About creating an image from volume](https://cloud.ibm.com/docs/vpc?topic=vpc-image-from-volume-vpc).



 Prerequisites 

To complete this task, you must have an instance of IBM Cloud® Object Storage available. You must also create an authorization so that the Image Service for VPC can access images in IBM Cloud Object Storage. For more information, see [Granting access to IBM Cloud Object Storage to import images](https://cloud.ibm.com/docs/vpc?topic=vpc-object-storage-prereq).

For more information about custom images, see [Getting started with custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images).

Keep the following considerations to keep in mind when you import a custom image:



* When you import a custom image, it's private to the account where you import it. Also, the region where you choose to import the image is the region where you can create virtual server from that image.
* You can't create an image from an encrypted boot volume (image from a volume) that is not 100 GB. The operation is blocked.
* For custom images with Red Hat Enterprise Linux® or Windows® operating systems, you must select the appropriate version of the operating system. Depending on how you configured the image, select either bring your own license byol, or if you plan to license the OS through IBM Cloud, select the version without byol appended.
ibmcloud ce registry create 

Create an image registry access secret.

ibmcloud ce registry create --name NAME (--password PASSWORD | --password-from-file PASSWORD_FILE | --password-from-json-file) [--email EMAIL] [--output OUTPUT] [--quiet] [--server SERVER] [--username USERNAME]



 Command Options 

-n, --name
: The name of the image registry access secret. Use a name that is unique within the project.



* The name must begin and end with a lowercase alphanumeric character.
* The name must be 253 characters or fewer and can contain lowercase letters, numbers, periods (.), and hyphens (-).



This value is required.

--email, -e
: The email address to access the registry server. This value is optional.

--output, -o
: Specifies the format of the command output. Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

--password, -p
: The password to access the registry server. If neither --password, nor --password-from-file, nor --password-from-json-file option is specified, then you are prompted for the password. This value is optional.

--password-from-file, --pf
: The path to a file containing the password to access the registry server. The first line of the file is used for the password. If neither --password, nor --password-from-file, nor --password-from-json-file option is specified, then you are prompted for the password. This value is optional.

--password-from-json-file, --pfj
: The path to a JSON file containing the password to access the registry server. The apikey field is used for the password.
While it is comparatively simple to [Base64-encode key material](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-root-keyshow-to-encode-root-key-material), it is important to follow [NIST guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) when creating your own key material. Improperly created key material can make your keys more susceptible to being compromised. Unless you feel confident in creating the appropriate key material yourself, the best practice is to let Key Protect create your key material for you as part of the key creation process, which follows the latest NIST guidelines.

Because this key material can be used to [create a functionally duplicate key](https://cloud.ibm.com/docs/key-protect/concepts?topic=key-protect-getting-started-tutorialget-started-next-steps-best-practices-key-aliases), whether you have created the key material yourself or exported a Key Protect created key, make sure you keep this key material secure.
With the PKCS #11 API, you can also perform [post-quantum cryptographic](https://en.wikipedia.org/wiki/Post-quantum_cryptography) operations. Traditional cryptography relies on complicated mathematical problems that are difficult for classical computers to solve. However, with the computing capabilities, quantum computers can solve these problems. Post-quantum cryptography is considered to be resistant to cryptanalytic attacks from quantum computers. It usually uses asymmetric algorithms and has multiple approaches.

The PKCS #11 API provides the [Dilithium algorithm](https://pq-crystals.org/dilithium/) for post-quantum cryptography. It is a lattice-based digital signature scheme and can be used for signature generation and verification. Currently, only the [high-security version of round 2 Dilithium](http://oid-info.com/get/1.3.6.1.4.1.2.267.1.6.5) is supported and it is not available for C_SignUpdate and C_VerifyUpdate operations.

The Dilithium algorithm is supported only by the IBM 4769 crypto card, also referred to as Crypto Express 7S (CEX7S). If you create your instances in Virtual Private Cloud (VPC) based regions, where the CEX7S crypto cards are used, you can use the Dilithium algorithm for post-quantum cryptography with the PKCS #11 API. For a list of VPC-based regions, see [Regions and locations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions).

For more information about Dilithium algorithm support in PKCS #11, see

[PKCS #11 API reference](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-pkcs11-api-ref). You can also find Dilithium algorithm code examples in the [GitHub sample repository](https://github.com/IBM-Cloud/hpcs-pkcs11).
For more information about creating an image from a volume, see [About creating an image from a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-image-from-volume-vpc).<br> * A Catalog image is a custom image that is imported into a private catalog. You can either import a custom image that was already imported into IBM Cloud VPC or an image from a volume. For more information about catalog images, see [Custom images in a private catalog](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uicustom-image-cloud-private-catalog). <br> Note: If you select a catalog image that belongs to a different account, you have more considerations and limitations to review. See [Using cross-account image references in a private catalog in the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uiprivate-catalog-image-reference-vpc-ui). To create a private catalog, see the tutorial [Onboarding a virtual server image for VPC](https://cloud.ibm.com/docs/account?topic=account-catalog-vsivpc-tutorial&interface=ui).<br> * You can also select either an RHEL or Windows custom image and bring your own license (BYOL). For more information about creating BYOL custom images, see [Bring your own license](https://cloud.ibm.com/docs/vpc?topic=vpc-byol-vpc-about).<br><br><br>
Whether you can enable the feature depends on the history of the Hyper Protect Virtual Server instance (partition layout and LUKS encryption) and the contract information. See the following table for possible scenarios and results. If you don't know what kms details in the contract mean, see the instructions in [Steps](https://cloud.ibm.com/docs/vpc?topic=vpc-hyper-protect-virtual-server-mng-datasteps-to-enable).



Table 1. Scenarios

 Number of partitions in the data volume Metadata partition Contract Whether the partition/second partition is LUKS encrypted Behavior of Hyper Protect Virtual Server 

 0 N/A Has kms details Not LUKS encrypted The instance creates two partitions in the data volume, calls Hyper Protect Crypto Services to generate a third seed and wrap it with the CRK. The wrapped seed is stored in the metadata partition. Then the instance generates a LUKS passphrase with the seed (unwrapped first) and the two seeds from the contract to encrypt the second partition. 
 0 N/A Has kms details LUKS encrypted The instance shuts down. You need to remove the kms details in the contract. 
 1 N/A Not supported. The instance shuts down. 
 2 No encrypted seed Has kms details (one entry) Not LUKS encrypted The instance calls Hyper Protect Crypto Services to generate a third seed and wrap it with the CRK. The wrapped seed is stored in the metadata partition. Then the instance generates a LUKS passphrase with the seed (unwrapped first) and the two seeds from the contract to encrypt the second partition. 
 2 No encrypted seed Has kms details (one entry) LUKS encrypted Similar flow as the previous one to re-encrypt the second partition. The old LUKS passphrase is replaced. Note that the two seeds from env and workload need to be the same as before; otherwise the re-encryption fails and the instance shuts down. Provide the correct seeds and retry.
For earlier versions, see the [Portieris documentation](https://github.com/IBM/portieris).



 Enabling or disabling image security enforcement with the CLI 

See the following commands.



* [ibmcloud oc cluster image-security enable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics-image-security-enable)
* [ibmcloud oc cluster image-security disable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics-image-security-disable)







 Enabling or disabling image security enforcement from the console 



1. From the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift), select your cluster.
2. From the Overview tab, in the Summary pane, find the Image security enforcement field and click Enable or Disable.









 Default image policies 

When you enable image security enforcement, Red Hat OpenShift on IBM Cloud automatically creates certain image policies in your cluster. When you disable the feature, the underlying ClusterImagePolicy CRD is removed, which removes all the default image policies and any custom images policies that you created.



* Image policies with the name ibm-signed-image-enforcement restrict the images that are run in the project to Red Hat OpenShift on IBM Cloud images only. Do not modify these image policies. Any changes that you make are overwritten within a few minutes.
* Other image policies, such as default or default-allow-all, permit images that are not restricted by another image policy. You can modify these image policies and your changes are preserved, but don't rename the image policy. If you rename the policy, more policies with the default name and settings are created.



To review the image policies in your cluster,

Before you begin
From IBM Cloud® Identity and Access Management (IAM), authorize service between Cloud Block Storage (source service) and your KMS (target service). For custom images, also authorize between Image Service for VPC (source service) and IBM Cloud Object Storage (target service).
5. The IBM Cloud VPC infrastructure uses your root key to secure the data by wrapping the passphrases for volumes or custom images. For custom images, the root key wraps the passphrase before you import the custom image file to the cloud. For more information, see [About encrypted custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutbyok-about-encrypted-images).
6. Manage your keys in your KMS. For example, you can [disable](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managingbyok-disable-root-keys) your root key to suspend its encryption and decryption operations. You can also [rotate your customer-managed root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-key-rotation). By rotating your root keys, you can roll out a new key across the resources that were protected by the old key.





 Flow diagrams for specifying customer-managed encryption for volumes 

You can specify customer-managed encryption when you create Block Storage for VPC volumes during instance provisioning. You can also specify it when you create a stand-alone volume.

Figure 1 shows the procedure for creating a data volume with customer-managed encryption during instance provisioning. The volume is automatically attached to the instance.

Zoom

![Figure shows the procedure for creating an instance with a customer-managed encrypted volume.]