vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information on encryption key set up, see the [Key Protect Getting started tutorial](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial) or [Getting started with IBM Cloud Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started).

Customer managed encryption for custom image instances is not currently implemented in the Citrix DaaS order form. To use customer managed encryption for a custom image instance boot volume, you must first create a custom image with encryption, then select your custom image in the custom image instance section in the Citrix DaaS order form.







 Step 7 - Logging and monitoring 

Centralized logging is provided by an IBM® Log Analysis instance that provides one place for the various log files, including:



* Cloud Connector VSIs (Connector Logs and Plug-in),
* Domain Controller logs from the Active Directory Server,
* Volume Worker logs that are on both IBM Cloud Functions and the worker VSI logs that complete the jobs.



Centralized logging is enabled by default. You specify the instance to use.

Select a log instance option, either:



* Use an existing instance and select the name of the instance to use.
* Create a new instance and select a logging plan to use. Set whether to enable platform. Platform logs can be enabled for only one logging instance per region.







 Step 8 - Custom configuration (optional) 

Citrix DaaS for IBM Cloud provisioning uses Terraform scripts and IBM Cloud Schematics to create your resources.

If you want only the items on the provisioning form, you select Create. The scripts create a Schematics workspace for you where you can see your script logs and the resources that are provisioned.

If you want to further customize your resources, you select Enable configuration customization after 'Create' and then Create. The scripts create the Schematics workspace for you and show you the parameters that you can customize. After you are done customizing the parameters, you select Generate Plan then Apply plan. The Terraform scripts run and create your resources.
You can deploy containers from any image regardless of security status.

To find out about the required permissions for working with exemptions, see [Access roles for configuring IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure).

Using Portieris to block the deployment of images with issues that are found by Vulnerability Advisor is deprecated.



 Setting exemption policies by using the console 

If you are using the IBM Cloud console, you can set a [namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_namespace), [repository](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_repository), or [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag) as the scope of the exemption policy. If you want to use the [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) as the scope, you must use the CLI, see [Setting organizational exemption policies by using the CLI](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_managing_policy_cli).

If you want to set exemptions from the policy by using the IBM Cloud console, complete the following steps:



1. Log in to IBM Cloud. You must be logged in to see Vulnerability Advisor in the IBM Cloud console.
2. Click the Navigation menu icon, then click Container Registry.
3. Click Settings.
4. In the Security policy exemptions section, click Create.
5. Select the issue type.
6. Enter the issue ID.

You can find this information in your [vulnerability report](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_reviewing).
On the IBM Cloud RHEL8 image gocryptfs is not available, but on Ubuntu 20.04 it is. You can install gocryptfs by using apt.

Mount a File Storage (here it is mounted on /mnt/filestor):

root@classic-byok-poc01:/mnt cat /etc/fstab
LABEL=cloudimg-rootfs	/	 ext4	defaults,relatime	0 1
 CLOUD_IMG: This file was created/modified by the Cloud Image build process
LABEL=cloudimg-bootfs /boot ext3 defaults,relatime 0 0
LABEL=SWAP-xvdb1	none	swap	sw,comment=cloudconfig	0	2
fsf-fra0401g-fz.service.softlayer.com:/IBM02SEV1395451_375/data01 /mnt/filestor nfsvers=3 defaults 0 0

Turn on encryption:

root@classic-byok-poc01:/mnt mkdir filestor/cipher
root@classic-byok-poc01:/mnt gocryptfs -init filestor/cipher
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

3698766d-b3fdc176-33442fb3-dc4c4d61-
d8a36aad-9a453019-710b96a5-7717d5ed

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs filestor/cipher MOUNTPOINT

Mount the encrypted storage as unencrypted and work with it:
To validate as custom image by using the API, use the [List all images](https://test.cloud.ibm.com/apidocs/vpc/latestlist-images).

For the $image_id, specify the ID of the custom image you want to validate.

curl -X GET "$vpc_api_endpoint/v1/images/$image_id/?version=2023-02-21&generation=2" -H "Authorization: Bearer $iam_token"

Compare the returned Checksum (SHA256) value to the output that is generated when you calculate a checksum for the image locally.



* Example Linux command: sha256sum ubuntu_image.qcow2
* Example Mac command: shasum -a 256 ubuntu_image.qcow2
* You receive output similar to: 6809606da67eb83670e6249e54e94043eb43c0471669fb96ea4050c4c07e2df7



After you validate the Checksum (SHA256), use the image to create a virtual server. See [Creating a virtual server instance by using the API](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-virtual-servers&interface=api).





 Next steps 

After you validate the custom images, you can deploy and manage your custom images. For more information, see [Managing custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-custom-images&interface=ui). If you plan to manage your custom images with a private catalog, see [Onboarding a virtual server image for VPC](https://cloud.ibm.com/docs/account?topic=account-catalog-vsivpc-tutorial&interface=ui).
The following example views the details of a custom image with the id of r134-1d1e92e9-6550-4d06-8483-d674310045fd.

ibmcloud is image r134-1d1e92e9-6550-4d06-8483-d674310045fd

ID r134-589548bd-9241-4ad7-a610-1df6ba020793
Name my-image-from-volume-cli-1
CRN crn:v1:staging:public:is:us-south:a/efe5afc483594adaa8325e2b4d1290df::image:r134-589548bd-9241-4ad7-a610-1df6ba020793
Status available
Operating system Name Architecture Vendor Version Dedicated host only
centos-7-amd64 amd64 CentOS 7.x - Minimal Install false

Source volume ID Name
r134-6438d80f-4433-4445-be2f-0cca05afff3e transpose-clubhouse-putt-repent

Created 2023-03-16T01:11:03+05:30
Deprecation Date 2023-03-01T06:11:28+05:30
Obsolescence Date 2023-12-31T06:11:28+05:30
Visibility private
Owner type user
Minimum provisioned size(GB) 250
SHA256 Checksum 774d44ac0d55f2bfe869b995565715e5d9970ec23ce7127b2e2776b2618a9f7c
File size(GB) 2
Encryption none
Resource group 11caaa983d9c4beb82690daab08717e9
Resource type image
Catalog Offering Managed false
ibmcloud hpvs registration-create [--repository-name REPO-NAME] [--cr-username USER-NAME --cr-pwd-path FILE-PATH | --no-auth] [--allowed-env-keys ENV-KEYS | --no-env] [--image-key-id IMAGE-KEY-ID] [--fingerprint FINGERPRINT] [--image-key-public-path PUBLIC-KEY] [--registration-key-private-path PRIVATE-KEY-PATH] [--registration-key-public-path PUBLIC-KEY-PATH] [--gpg-passphrase-path PASS-PHRASE] [--cap-add CAPABILITIES] [--isv-secrets ISV-SECRETS | --no-isv-secrets]

The output of this command is a registration.json.asc file that is used for updating the virtual server. Ensure that you move the existing registration.json.asc file to another location before you run this command.

If you enter the command without any parameters, you are prompted to enter all the parameters.

If image is in ICR, the fingerprint of the gpg key that was used to sign the image must be provided when you are prompted for the "Fingerprint", and path to the public key with which it is signed needs to be provided when you are prompted for the "Path to the file containing the image public key".

For the --registration-key-private-path and --registration-key-public-path parameters, ensure that you use the same private and public key that you had used when you created the virtual instance the first time. You must save these keys in a safe and secure location for future use. If you do not use the same set of private and public key, the command execution fails

If the container registry does not require authentication, set the -no-auth parameter to prevent prompting. If no environment parameters are required, set the -no-env parameter, for example:

ibmcloud hpvs registration-create --no-env --no-auth

Command options--repository-name REPO-NAME : Is the fully qualified name for the repository.

--cr-username USER-NAME
[Key management](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959749) C_GenerateKeyPair Yes Generates a public or private key pair. 
 [Key management](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959749) C_WrapKey Yes Wraps (encrypts) a key. 
 [Key management](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959749) C_UnwrapKey Yes Unwraps (decrypts) a key. 
 [Key management](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959749) C_DeriveKey Yes Derives a key from a base key. 
 [Random number generation](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959750) C_SeedRandom No Adds seed material to the random number generator. 
 [Random number generation](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959750) C_GenerateRandom Yes Generates random data. The length of the random data cannot be zero and the pointer that points to the random data location cannot be NULL.
Run one of the following commands based on the image you plan to use.



* Select a stock image or a custom image from your account for your instance.

To list all available images, run the following command:

ibmcloud is images

Deprecated images do not include the most current support.

Let's pick image ibm-debian-11-3-minimal-amd64-1. To get the image ID, run the following command:

image=$(ibmcloud is images | grep -i "debian.available.amd64.public" | cut -d" " -f1)

Save the image ID as a variable, which will be used later to provision an instance.
* Select an image shared from a private catalog for the instance

If you select a catalog image that belongs to a different account, there are additional considerations and limitations to review. See [Using cross-account image references in a private catalog in the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uiprivate-catalog-image-reference-vpc-cli)



* To list all available private catalog image offerings, run the following command.

ibmcloud is catalog-image-offerings

This command returns the identifier of each image offering and the identifier of the private catalog where the image resides. Save the offering_id and catalog_id in variables, which will be used later to provision an instance.

offering_id=6bf79f7b-de48-4ce8-8cae-866b376f2889
catalog_id=71306253-8444-4cae-a45d-64d35e5393ec
* To get the offering_crn for the offering and the offering_version_crn for each version in the offering, run the following command.

ibmcloud is catalog-image-offering $catalog_id $offering_id
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>







 For private repositories 

If the failure happened for a private repository, then create a an SSH secret and use the SSH protocol. An SSH secret contains the credentials to access the private repository that contains the source code to build your container image. An SSH secret is also used as a Git repository access secret. The SSH secret contains a private key while the corresponding public key is stored with your Git repository provider. For more information about creating a key pair and store the public part in GitHub or GitLab, see [Accessing private code repositories](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories). It is important that your private key file is not encrypted with a passphrase before you can upload it to Code Engine. The format of the private key file can vary, which makes it complicated to assess if the file is encrypted. Depending on the version of the ssh-keygen tool that was used to create the key pair, the file might have one of the following headers:



* If the file starts with -----BEGIN RSA PRIVATE KEY-----, then it uses the PEM format and was created with an older version of ssh-keygen. If the file is encrypted with a passphrase, then it typically contains a line like this: Proc-Type: 4,ENCRYPTED.
* If the file starts with -----BEGIN OPENSSH PRIVATE KEY-----, then it was created with a newer version of ssh-keygen. 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 deploy containers from any image regardless of security status.

To find out about the required permissions for working with exemptions, see [Access roles for configuring IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure).

Using Portieris to block the deployment of images with issues that are found by Vulnerability Advisor is deprecated.



 Setting exemption policies by using the console 

If you are using the IBM Cloud console, you can set a [namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_namespace), [repository](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_repository), or [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag) as the scope of the exemption policy. If you want to use the [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) as the scope, you must use the CLI, see [Setting organizational exemption policies by using the CLI](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_managing_policy_cli).

If you want to set exemptions from the policy by using the IBM Cloud console, complete the following steps:



1. Log in to IBM Cloud. You must be logged in to see Vulnerability Advisor in the IBM Cloud console.
2. Click the Navigation menu icon, then click Container Registry.
3. Click Settings.
4. In the Security policy exemptions section, click Create.
5. Select the issue type.
6. Enter the issue ID.

You can find this information in your [vulnerability report](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_reviewing).
Log on to the source VM where the source mksysb resides and copy the image to the helper VM after you choose an option. In the following example, the customer is using Secure Copy Protocol (scp) from an on-premises system and copying it into the /mksysb file system of the helper VM:

If you did not decide on a private access option, or chose a different option for your internal IP access, your steps might vary.

Running the cksum command:

: >cksum gdrh10v1.sysb
371420133 5806899200 gdrh10v1.sysb
: >scp gdrh10v1.sysb root@192.168.111.3:/mksysb/gdrh10v1.sysb
root@192.168.111.3's password:
gdrh10v1.sysb 100%





 Creating the alternate disk image volume 

Log on to the helper VM and verify that the image under /mksysb has an identical cksum as the reported size from the on-premises system. After verifying the matching sizes, you can create a volume large enough to hold the restored root volume group.

To determine the necessary volume size of the alternate disk, examine the contents of the bosinst.data file within the mksysb archive. The bosinst.data file in the archive contains stanza information that indicates the minimum space that is required to restore the mksysb. An easy way to accomplish this is to usfe the restore command to extract the ./images/bosinst.data file from the mksysb archive.

Search the bosinst.data file and find the stanza that is named target_disk_data. This stanza indicates the minimum size in megabytes of the required volume in a SIZE_MB = size key value pair. The recorded size is used when creating the alternate disk image volume and attaching it to the _helper VM.

The restore -qf command:

 restore -qf gdrh10v1.sysb ./bosinst.data
x ./bosinst.data
 grep -p target_disk_data bosinst.data
* [Copying the default-region-icr-io secrets](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret) from the default project to the project that you want to pull images from.
* [Creating your own image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts).
* [Adding the image pull secret to your deployment configuration or to the project service account](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).



Version change log
: Worker node patch updates are available. :
: Red Hat OpenShift [3.11.146_1530_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311153_1530).





 7 November 2019 

CLI change log
: Updated the IBM Cloud Kubernetes Service CLI plug-in change log page for the [release of version 0.4.51](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog).





 1 November 2019 

New! Keep your own key (KYOK) support (beta)
: You can now [enable several key management service (KMS) providers](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms), so that you can use your own root key to encrypt the secrets in your cluster.







 October 2019 



 31 October 2019 

Refreshed Red Hat OpenShift on IBM Cloud docs
: Includes the following new content.



* [Setting up VPN connectivity](https://cloud.ibm.com/docs/openshift?topic=openshift-vpn)
For example, if you pushed the encrypted image to IBM Cloud Container Registry, you can follow the example in [Deploying containers from an IBM Cloud Container Registry image to the default Red Hat OpenShift project](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesnamespace). When you create the deployment in your cluster, the container runtime uses the private decryption key in the /etc/crio/keys/synced directory to decrypt the image before running it.
10. For any subsequent images that you want to encrypt, you can either use the same public key to encrypt the images with Skopeo, or repeat these steps to use a different public and private key pair.



If you later decide to disable the add-on, the addon-image-key-syncrhonizer daemon set is removed, but the image-key-synchronizer project and any secrets that you created in that project are not removed, and the container runtime can still use the secrets to run encrypted images. If you want to remove the keys from your worker nodes as well, you must delete the corresponding secrets from the image-key-synchronizer project before you disable the add-on.

For the list of changes for each Image Key Synchronizer add-on version, see the [IBM Cloud Image Key Synchronizer add-on change log](https://cloud.ibm.com/docs/openshift?topic=openshift-image-key-synchronizer-changelog).





 Referring to the image pull secret in your pod deployment 

If the cluster administrator did not [store the image pull secret in the Kubernetes service account](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret), all deployments that don't specify a service account can't use the image pull secret to deploy containers. Instead, you can define an image pull secret in your pod deployment.
wrap the plaintext key with the root key, creating a DEK (this is the ciphertext)
 this should fail (the root key is disables)
$ ibmcloud kp key wrap $KEY_ID -p $PLAINTEXT --output json

FAILED
kp.Error:
correlation_id='c2edbdad-7e62-4690-8fcc-10515ade9913',
msg='Conflict: Action could not be performed on key. Please see "reasons" for more details.',
reasons='[KEY_ACTION_INVALID_STATE_ERR: Key is not in a valid state -
FOR_MORE_INFO_REFER: https://cloud.ibm.com/apidocs/key-protect]'







 Required parameters 

KEY_ID
: The ID of the key that you want to delete. To retrieve a list of your available keys, run the [kp keys](#kp-keys) command.







 kp key enable 

When you enable a root key that was previously disabled, the key transitions from the Suspended (value is 2) to the Active (value is 1) key state. This action restores the key's encrypt and decrypt operations.

If you're using an integrated Cloud Service that supports restoring access to a disabled root key, the service may take up to a maximum of 4 hours before access to the root key's associated data is restored.

After access to the associated data is restored, a corresponding enable event is displayed in the IBM Cloud Activity Tracker web UI. The enable event indicates the key has been restored (and is now enabled) and the key can be used for encrypt and decrypt operations, such as wrap, unwrap, and rewrap.

ibmcloud kp key enable KEY_ID
-i, --instance-id INSTANCE_ID



 Examples 

This is an example of kp key enable.

 create a root key
$ ibmcloud kp key create my-root-key --output json

{
"name": "my-snapshot", // required
"source_snapshot": { // required
"crn": "crn:[...]"
},
"resource_group": { // optional
"id": "2d1bb5a8-40a8-447a-acf7-0eadc8aeb054"
},
"encryption_key"; "crn:[...]" // required when source has customer-managed encryption
}

A successful response indicates that the snapshot copy was created in the target region.

{
"created_at": "2023-05-10T20:18:18Z",
"deletable": false,
"encryption": "user_managed",
"encryption_key": {
"crn": "crn:[...]"
},
"href": "https://us-east.iaas.cloud.ibm.com/v1/snapshots/r139-f6bfa329-0e36-433f-a3bb-0df632e79263",
"id": "r139-f6bfa329-0e36-433f-a3bb-0df632e79263",
"lifecycle_state": "pending",
"minimum_capacity": 100,
"name": "my-snapshot",
"operating_system": {
"architecture": "amd64",
"dedicated_host_only": false,
"display_name": "Ubuntu Linux 20.04 LTS Focal Fossa Minimal Install (amd64)",
"family": "Ubuntu Linux",
"gpu_supported": [],
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:390086ac-76fa-4094-8cf3-c0829bd69526:key:264fadc3-7667-4b25-916e-5825fe70de0b"
}





 Example 2 

Create a root key, disable it, and attempt to use the root key to wrap another key.

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

$ echo $KEY_ID

63d044d9-b38b-4803-85ef-ed9a1e5087c2

 disable the root key
$ ibmcloud kp key disable $KEY_ID

Disabling key: '63d044d9-b38b-4803-85ef-ed9a1e5087c2', in instance: '390086ac-76fa-4094-8cf3-c0829bd69526'...
OK

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

$ echo $PLAINTEXT

BNxtU9B4kXOZA45Cnyz3wOh4J77TakTXI1n2rj0ZiMc=

 wrap the plaintext key with the root key, creating a DEK (this is the ciphertext)
 this should fail (the root key is disables)
$ ibmcloud kp key wrap $KEY_ID -p $PLAINTEXT --output json

FAILED
kp.Error:
correlation_id='c2edbdad-7e62-4690-8fcc-10515ade9913',