vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, if you have a Windows 2019 BYOL custom image, select Windows-2019-amd64-byol for the operating system. Failure to select the -byol version of the operating system when you import a BYOL custom image might result in a virtual server that is unable to start.<br><br>If you configured your Red Hat Enterprise Linux or Windows custom image to license through IBM Cloud, you must select the nonbyol operating system. For example, if you have a Windows 2019 custom image that you plan to license through IBM Cloud, select Windows-2019-amd64 as the operating system when you import the custom image. 
 Encryption The default selection is Provider managed. If you have not encrypted your image by using QEMU, use the default value, Provider managed. If you are importing an image that you have encrypted by using QEMU and your own passphrase, select the key management service where your customer root key (CRK) that protects your passphrase is stored. Select either Key Protect or Hyper Protect Crypto Services. VHD format images are not supported for encryption. 
 Encryption service instance For an encrypted image, select the specific instance of the key management service where your CRK that wraps your encryption passphrase is stored. For more information, see [Setting up your key management service and keys](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-imagekms-prereqs). 
 Key name Select the customer root key (CRK) that you used to wrap your encryption passphrase. For more information, see [Setting up your key management service and keys](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-imagekms-prereqs). 
 Wrapped data encryption key For an encrypted image, specify the ciphertext that is associated with the wrapped data encryption key (WDEK). The WDEK is produced by wrapping the passphrase that you used to encrypt your image with your customer root key.
You can also specify your own root encryption key in the POST/images call. For more information, see [Create an image from volume and use your root encryption key](https://cloud.ibm.com/docs/vpc?topic=vpc-create-ifvifv-use-crk).

This procedure:



1. Creates an instance and uses its boot volume ID as the source volume.
2. Stops the running instance.
3. Creates an image with the ID of the boot volume. In this scenario, the boot volume is encrypted with the default IBM-managed encryption. If the boot volume was encrypted with a [customer root key](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutvpc-customer-managed-encryption), that root key is used to encrypt the new image. The API response displays the [CRN of the root key](https://cloud.ibm.com/docs/vpc?topic=vpc-create-ifvifv-use-crk).





 Step 1 - Creating an instance 

Specify a POST/instances request to create an instance and pass the required parameters. See the following example.

curl -X POST "$vpc_api_endpoint/v1/instances?version=2021-05-20 $iam_token" -d
{
"name":"test-ifv-instance",
"profile":{
"name":"bx2-2x8"
},
"vpc":{
"id":"6054c339-8a17-4c75-958c-4a23358a37ed"
},
"image":{
"id":"524d52aa-b267-4801-a7d2-6d4fe75baf65"
},
"zone":{
If you are using Windows 11, select a Windows 2019 or 2022 image.<br><br>For custom images with Windows operating systems, you can bring your own license (BYOL) or license through IBM Cloud.<br><br>For Windows [BYOL custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-byol-vpc-about), you must select the OS with -byol appended to the name. For example, if you have a Windows 2019 BYOL custom image, select Windows-2019-amd64-byol for the operating system. Failure to select the -byol version of the operating system when you import a BYOL custom image might result in a virtual server that is unable to start.<br><br>If you configured your Windows custom image to license through IBM Cloud, you must select the non-byol operating system. For example, if you have a Windows 2019 custom image that you plan to license through IBM Cloud, select Windows-2019-amd64 as the operating system when you import the custom image. 
 Encryption The default selection is No encryption. If you have not encrypted your image by using QEMU, use the default value, No encryption. If you are importing an image that you have encrypted by using QEMU and your own passphrase, select the key management service where your customer root key (CRK) that protects your passphrase is stored. Select either Key Protect or Hyper Protect Crypto Services. VHD format images are not supported for encryption. 
 Encryption service instance For an encrypted image, select the specific instance of the key management service where your CRK that wraps your encryption passphrase is stored. For more information, see [Setting up your key management service and keys](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-imagekms-prereqs). 
 Key name Select the customer root key (CRK) that you used to wrap your encryption passphrase.
DGflqQBSmV40XP3iZnNUJDrHuAol463Z/BuxxFXL3ry6rTosLGfrRwdQjxp8RSsn
WyIIO2rmcqXZYe4SCtiMjMejLlTIDWLIMdYL3d6hA4DpgDLoh6EPmhKMVVwRt5b0
ew5eMLcDuq6ButOM5yv4zYVHNrajY41NK+abSlFb6wzMg2AUDiC/MxV1LRq6mpyZ
GJllx3LS1M1j7fDO3pmh/M0X7yD/4RgHwFaW4/4CQBw3fyxrOv0pZzZay+o
-----END PUBLIC KEY-----







 Step 2: Encrypt the image 

Encrypt the image by using the public key and then build a container image by using a

Dockerfile.



1. Go to the directory where you store your apps, for example, <my_app>.

cd <my_app>
2. Create the Dockerfile by running the following command:

cat << EOF >> Dockerfile
FROM nginx:latest
RUN echo "some secret" > /secret-file
EOF
3. Use Buildah to create an unencrypted image by running the following command, where <namespace> is your namespace:

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.
"id": "4fec84ef-baf9-405d-bf3b-9d5a60e068f7",
"crn": "crn:[...]",
"href": "",
"name": "ifv-boot-vol"
}
}







 Creating an image from volume and specifying your own encryption key 

In this scenario, you're creating an image from a volume and specifying your root key in the POST/images call.

The example request specifies the CRN of the root key in the encryption_key parameter:

curl -X POST "$vpc_api_endpoint/v1/images?version=2021-05-20"
$iam_token" -d
{
"name": "test-ifv-boot-volume",
"source_volume": {
"id": "4fec84ef-baf9-405d-bf3b-9d5a60e068f7"
},
"encryption_key":{
"crn":"crn:[...key:...]"
},
}

The response includes information about the root key:

{
"created_at": "2021-05-20T00:05:13.873893Z",
"crn": "crn:[...]",
"encryption_key": {
"crn": "crn:[...key:...]"
},
"encryption": "user_managed",
"file": {},
"href": "https://us-south.iaas.cloud.ibm.com/v1/images/4fec84ef-baf9-405d-bf3b-9d5a60e068f7",
Failed Image creation failed. 
 Deleting The image is being deleted. 
 Deprecated You can use the image to create an instance. Using the deprecated status can discourage use of the image before the status changes to obsolete. 
 Obsolete You can't use the image to a create an instance. If you try to use an obsolete image to create an instance, you receive a message that the image can't be used to create an instance. This status allows a reversible disabiling of an image before you delete the image. 







 Scheduling an image from volume lifecycle status by using the UI 

You can schedule either a single image lifecycle status change or schedule the status changes for the entire lifecycle of the image.

Use the following steps to schedule a single status change:

You can schedule a single status change for an image.



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. On the Custom images tab, click the Actions icon ![More Actions icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/action-menu-icon.svg) for a specific image and select from the available options.
3. Select Schedule lifecycle.
4. In Image status, select the status change for the image.
5. In Deprecation details, select whether to change status Immediately or to Schedule future date.
6. If you selected Schedule future date, you need to fill out the following:



* Select either By calendar date or By number of days.



* If you selected By calendar date, enter the date and time information.
When you import with the API or UI, you supply a single QCOW2 boot image file that can be 10 GB to 250 GB. This file is private to the account to which it is imported. The region where you import the encrypted image is the region where you create virtual server instances from that image. The encrypted image displays with other custom images that you have permission to use. In the UI, a lock icon next to the name indicates that it's an encrypted custom image.

If you import an encrypted image that is not exactly 100 GB virtual disk size and use it to provision an instance, and then try to create a custom image from that instance’s boot volume, the POST /images call is going to return an error.

When you provision a virtual server instance with the encrypted image, no other encryption information is needed. The WDEK and the CRN of the root key are stored as metadata with the image. The WDEK is used to access the encrypted image when a virtual server instance that uses the encrypted image is started.

At provision time, data in the instance's boot volume is also encrypted by using the same root key that the custom image uses along with a generated passphrase. Alternatively, you can provide a different root key for the boot volume.

After the virtual server instance is created, you can view the custom image and see the root key CRN. You can also [rotate the root key](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-key-rotation) and be notified by the KMS when your encrypted image WDEK is automatically rewrapped (reencrypted).

Any secondary volumes that you create and attach from the encrypted custom image use a different passphrase than the base custom image. Optionally, you can provide a different root key for secondary volumes that are created during instance provisioning.

For more information about creating custom images, see [Creating an encrypted custom image](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-image).
Complete the following steps by using QEMU to create a second encrypted qcow2 file of your custom image.



1. Determine your own passphrase to use for encrypting your image. The sample commands in this task use the passphrase abc123. Keep your passphrase available. Later you need to wrap the passphrase to create a wrapped data encryption key (WDEK). The WDEK is required when you import the image to IBM Cloud VPC.
2. Verify your current qcow2 custom image by using the following command:

qemu-img info my_100G_custom_image.qcow2

For this example, you'd see a response similar to the following output:

image: my_100G_custom_image.qcow2
file format: qcow2
virtual size: 100 GiB (107374182400 bytes)
disk size: 1.28 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
3. Create a new, empty qcow2 file of the exact same size and encrypt it with LUKS encryption. Use the passphrase that you choose, for example, abc123, to encrypt the file:

qemu-img create --object secret,id=sec0,data=abc123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 my_100G_custom_image-encrypted.qcow2 100G
4. Convert your qcow2 image, my_100G_custom_image.qcow2 to the encrypted image, my_100G_custom_image-encrypted.qcow2.
qemu-img create --object secret,id=sec0,data=abc123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 my_100G_custom_image-encrypted.qcow2 100G
4. Convert your qcow2 image, my_100G_custom_image.qcow2 to the encrypted image, my_100G_custom_image-encrypted.qcow2.

qemu-img convert --object secret,id=sec0,data=abc123 --image-opts driver=qcow2,file.filename=my_100G_custom_image.qcow2 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=my_100G_custom_image-encrypted.qcow2 -n -p
5. Compare the two files to verify that they are identical.

qemu-img compare --object secret,id=sec0,data=abc123 --image-opts driver=qcow2,file.filename=my_100G_custom_image.qcow2 driver=qcow2,encrypt.key-secret=sec0,file.filename=my_100G_custom_image-encrypted.qcow2 -p
6. Check the file for errors.

qemu-img check --object secret,id=sec0,data=abc123 --image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=my_100G_custom_image-encrypted.qcow2

For this example, you'd see a response similar to the following output:

No errors were found on the image.
16343/1638400 = 1.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 1074790400
7.
<br>Need to create a custom image from a volume instead? Select the source for the custom image by choosing either Virtual server instance boot volume or Block storage boot volume. For more information, see [Creating an image from a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-create-ifv). 
 Location Select the specific geographic region where your image is stored. 
 Bucket Select the IBM Cloud Object Storage bucket where your image is stored. 
 Name Select the image file in the IBM Cloud Object Storage service instance that you want to import. If you are importing an encrypted image, the image must be encrypted with LUKS encryption by using QEMU and your own passphrase. For more information, see [Encrypting the image](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-imagemanually-encrypt-image). 
 Operating System Select the operating system that is included in your image. There is no stock image for Windows 10 and Windows 11. If you are using Windows 10, select a Windows 2019 image. If you are using Windows 11, select a Windows 2019 or 2022 image.<br><br>For custom images with Windows operating systems, you can bring your own license (BYOL) or license through IBM Cloud.<br><br>For Windows [BYOL custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-byol-vpc-about), you must select the OS with -byol appended to the name. For example, if you have a Windows 2019 BYOL custom image, select Windows-2019-amd64-byol for the operating system. Failure to select the -byol version of the operating system when you import a BYOL custom image might result in a virtual server that is unable to start.<br><br>If you configured your Windows custom image to license through IBM Cloud, you must select the non-byol operating system.
Provision a key management service, create a customer root key (CRK), and then wrap your passphrase with the CRK to generate a wrapped data encryption key (WDEK).
4. Ensure that you have the required IBM Cloud Identity and Access Management authorizations so that you can import the image from IBM Cloud Object Storage and so that your WDEK can be used for data encryption.
5. Import the image to IBM Cloud VPC. You must specify IBM Cloud Object Storage location, the CRK that is stored in your KMS, and your WDEK ciphertext.







 Encrypting the image 

In this step, you use QEMU to specify your own passphrase and encrypt your custom image with LUKS encryption.

The custom image that you plan to encrypt must meet the custom image requirements for IBM Cloud VPC infrastructure. Confirm that you completed the image preparation requirements in the following topics:



* [Getting started with custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images)
* [Creating a Linux custom image](https://cloud.ibm.com/docs/vpc?topic=vpc-create-linux-custom-image)
* [Creating a Windows custom image](https://cloud.ibm.com/docs/vpc?topic=vpc-create-windows-custom-image)



To complete the encryption task, you must have [QEMU](https://www.qemu.org/) version 2.12 or later installed.

You must use a Linux or Windows operating system to complete the QEMU encryption instructions. Mac operating system is not supported.

Complete the following steps by using QEMU to create a second encrypted qcow2 file of your custom image.



1. Determine your own passphrase to use for encrypting your image. The sample commands in this task use the passphrase abc123. Keep your passphrase available. Later you need to wrap the passphrase to create a wrapped data encryption key (WDEK). The WDEK is required when you import the image to IBM Cloud VPC.
"instance-id": "<service_instance_ID>",
"apikey": "<service_instance_ID_API_key>"
}





To deploy containers that use encrypted images:



1. Enable the Image Key Synchronizer add-on.

ibmcloud oc cluster addon enable image-key-synchronizer -c <cluster_name_or_ID>
2. Verify that the addon-image-key-syncrhonizer daemon set was successfully created in the image-key-synchronizer project in your cluster.

oc get ds addon-image-key-syncrhonizer -n image-key-synchronizer
3. Use openssl to generate a private and public RSA key pair.

openssl genrsa -out myprivatekey.pem
openssl rsa -in myprivatekey.pem -pubout -out mypubkey.pem
4. Provide the private key directly in a secret, or first wrap the private key by using a root key from a key management service (KMS), such as Key Protect. After you create the secret in the image-key-synchronizer project, the Image Key Synchronizer add-on automatically copies the private key to the /etc/crio/keys/synced directory on your worker nodes.



* To provide the private key directly: Save the private key as a Kubernetes secret in the image-key-synchronizer project.

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.
The authentication_algorithm must be disabled if and only if encryption_algorithm is aes128gcm16, aes192gcm16, or aes256gcm16.

export authentication_algorithm=<your_secure_authentication_algorithm>
export pfs=<your_secure_pfs_group>
export encryption_algorithm=<your_secure_encryption_algorithm>
3. Replace IPsec policies --authentication-algorithm value, --pfs value, and --encryption-algorithm value with secure ciphers in your CLI code.

ibmcloud is ipsec-policy-update $ipesc_policy
[--authentication-algorithm $authentication_algorithm]
[--pfs $pfs]
[--encryption-algorithm $encryption_algorithm]

Command examples:



* Initiate the IPsec policy variables:



* export ipesc_policy=my-ipsec-policy
* export authentication_algorithm=sha256
* export pfs=14
* export encryption_algorithm=aes128



* Update an IPsec policy by using SHA 256 authentication: ibmcloud is ipsec-policy-update $ipesc_policy --authentication-algorithm $authentication_algorithm
* Update an IPsec policy by using PFS with DH Group 14: ibmcloud is ipsec-policy-update $ipesc_policy --pfs $pfs
* Update an IPsec policy by using AES 128 encryption: ibmcloud is ipsec-policy-update $ipesc_policy --encryption-algorithm $encryption_algorithm
* Update an IPsec policy by using SHA 256 authentication, AES 128 encryption, and PFS with DH Group 14: ibmcloud is ipsec-policy-update $ipesc_policy --authentication-algorithm $authentication_algorithm --pfs $pfs --encryption-algorithm $encryption_algorithm









 Upgrading a VPN from a custom IKE policy with the API
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>...
Error decrypting layer sha256:ab4ea03582e08a8e8fc35b778cc6f1a1fa797469fa9cc61cee85f703b316bb12: missing private key needed for decryption
ERRO exit status 125
3. Use Buildah to pull the image with the decryption key, where <user_keys>/<user>Private.pem is the decryption key and us.icr.io/<namespace>/<my_app> is the registry:

buildah pull --decryption-key ../<user_keys>/<user>Private.pem us.icr.io/<namespace>/<my_app>

The encrypted image is retrieved from the registry, decrypted, and stored in the local image store.
4. Confirm that the image is stored by running Podman:

podman run -it us.icr.io/<namespace>/<my_app> /bin/bash







 Storing keys 

To use the private key in production, you must safely store and protect the private key. You might also want to manage the public key in the same way to control who can build images. You can use [IBM Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about) to store and protect your keys.

IBM Key Protect stores symmetric keys rather than the asymmetric PKI keys that are used for image encryption. You can add your keys separately as two IBM Key Protect standard keys by using the dashboard, CLI, or API.
* [Using granular RBAC permissions for custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-using-granular-RBAC-permissions-for-custom-images)
* [Configuration requirements for custom Linux kernel](https://cloud.ibm.com/docs/vpc?topic=vpc-configuration-requirements-for-custom-linux-kernels)
* [About creating an image from a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-image-from-volume-vpc&interface=ui)
* [Importing and validating custom images into VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-importing-custom-images-vpc).
* [Managing custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-custom-images&interface=ui)
* [Managing image from a volume](https://cloud.ibm.com/docs/vpc?topic=vpc-image-from-volume-vpc-manage&interface=ui)
View, inspect, pull, push, delete, and restore images.<br><br>View, add, analyze, and remove namespaces.<br><br>Assign namespaces to resource groups.<br><br>View and set quotas.<br><br>View vulnerability reports.<br><br>View and create image signatures.<br><br>Review and change pricing plans.<br><br>Enable IAM access policy enforcement.<br><br>List, add, and remove Vulnerability Advisor security issue exemption policies.<br><br>List types of security exemptions.<br><br>Set and run retention policies.<br><br>View the contents of the trash.<br><br>Restore images.<br><br>View the contents of the manifest for an image.<br><br>Prevent or allow image pulls or pushes over public network connections for your account.<br><br>Check whether the use of public connections is prevented for image pushes or pulls in your account.<br><br>Delete all untagged images in your Container Registry account. 



For the following Container Registry commands, you must have at least one of the specified roles as shown in the following tables. To create a policy that allows access to Container Registry, you must create a policy where the following criteria apply.



* The service name is container-registry.
* The service instance is empty.
* The region is the region that you want to grant access to, or is empty to give access to all regions.





 Access roles for configuring Container Registry 

To grant a user permission to configure Container Registry in your account, you must create a policy that grants one or more of the roles in the following table. When you create your policy, you must not specify a resource type or resource. Policies for configuring Container Registry must not be set at a resource group level.

For example, run the following ibmcloud iam user-policy-create command. Where <user_email> is the user's email address, <region> is the region, and <roles> is the role, or roles, that you want the user to have.