vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Red Hat OpenShift projects](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother)



* [Copying an existing image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret)
* [Creating an image pull secret with different IAM API key credentials](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts)
* [Accessing images that are stored in other private registries](https://cloud.ibm.com/docs/openshift?topic=openshift-registryprivate_images)



* [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret)



* [Storing the image pull secret in the Kubernetes service account for the selected project](https://cloud.ibm.com/docs/openshift?topic=openshift-registrystore_imagePullSecret)



* [Setting up a cluster to pull entitled software](https://cloud.ibm.com/docs/openshift?topic=openshift-registrysecret_entitled_software)
* [Adding a private registry to the global pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_global_pull_secret)
* [Updating an IBM Cloud Kubernetes Service containerd custom registry configuration](https://cloud.ibm.com/docs/openshift?topic=openshift-registryupdate_containerd_registry_config)



* [Example daemonset to update a containerd custom registry configuration](https://cloud.ibm.com/docs/openshift?topic=openshift-registryds-example-registry)
If you're building a proof of concept, you can also use a cryptography toolkit such as [OpenSSL](https://www.openssl.org/) to generate key material that you can import into Hyper Protect Crypto Services for your testing needs.

Choose an option for importing key material into Hyper Protect Crypto Services
: Choose from two options for importing root keys based on the level of security that is required for your environment or workload. By default, Hyper Protect Crypto Services encrypts your key material while it's in transit by using the Transport Layer Security (TLS) 1.2 protocol. If you're building a proof of concept or trying out the service for the first time, you can import root key material into Hyper Protect Crypto Services by using this default option. If your workload requires a security mechanism beyond TLS, you can also [use an import token](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-importing-keysusing-import-tokens) to encrypt and import root key material into the service.

Plan ahead for encrypting your key material
: If you choose to encrypt your key material by using an import token, determine a method for running RSA encryption on the key material. You must use the RSAES_OAEP_SHA_1 encryption scheme as specified by the

[PKCS #1 v2.1 standard for RSA encryption](https://tools.ietf.org/html/rfc3447). Review the capabilities of your internal key management system or on-premises HSM to determine your options.

Plan ahead for encrypting the nonce
: If you choose to encrypt your key material by using an import token, you must also determine a method for running AES-GCM encryption on the nonce that is distributed by Hyper Protect Crypto Services. The nonce serves as a session token that checks the originality of a request to protect against malicious attacks and unauthorized calls. Review the capabilities of your internal key management system or on-premises HSM to determine your options.

Manage the lifecycle of imported key material
For example, when you run the gpg --list-keys latestnewkey command, the following snippet is an example of the output:

pub rsa4096 2023-01-12 [SCEA] [expires: 2024-04-28]
322A65D5B50BF16F5FDB6D7173943217FCD72F51
uid [ultimate] latestnewkey
<latestnewkey@example.com>
sub rsa4096 2023-01-1--fingerprint FINGERPRINT2 [SEA] [expires: 2024-04-28]

In this example, "322A65D5B50BF16F5FDB6D7173943217FCD72F51" is the fingerprint.

--image-key-public-path PUBLIC-KEY
: The path for the file that contains the public part of the key that was used to sign the image. The public part of the key must be a minimum of 20 characters and base64 encoded. If the path is not specified, the command first tries to determine the public part of the key automatically by requesting the container registry notary service. If the image is present in ICR, path to the gpg public key that is used to sign the image should be mandatorily provided. It is optional for DCT signed image in Docker Hub.

--registration-key-public-path PRIVATE-KEY-PATH
: The path for the public key from the registration key pair.

--registration-key-private-path PUBLIC-KEY-PATH
: The path for the private key from the registration key pair.

--gpg-passphrase-path PASS-PHRASE
: The path to a file that contains the gpg passphrase used for the private part of the registration key. The passphrase must consist of at least 6 characters. To make sure that a new line is not appended, use echo with -n or cat with EOF.

--cap-add CAPABILITIES
: The Linux capabilities to be enabled are specified as a comma separated list.

--isv-secrets ISV-SECRETS
GPG keys provided during the setup of the toolchain are used to [sign](https://github.com/containers/skopeo/blob/main/docs/skopeo-copy.1.md) the images. If you want to customize the image signing process then add the following stage definition in your .pipeline-config.yaml:

sign-artifact:
abort_on_failure: false
image: icr.io/continuous-delivery/pipeline/image-signing:1.0. 0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
script: 
!/usr/bin/env bash
STAGE_DIND="true"
STAGE_ABORT_ON_FAILURE="false"
STAGE_IMAGE_PULL_POLICY="IfNotPresent"
source scripts/sign_image.sh





 acceptance-test 

Define this stage run your acceptance test after deployment.

acceptance-test:
abort_on_failure: false
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2. 12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
script: 
!/usr/bin/env bash
export APP_URL=$(cat ../app-url)
source scripts/setup_go.sh
echo "APP_URL :- ${APP_URL}"
go run acceptance-test/acceptance-test.test.go





 release 

Define this stage to upload evidence and artifacts that are generated from the previous stages.

release:
abort_on_failure: false
image: icr.io/continuous-delivery/toolchains/devsecops/compliance-baseimage:2.26.
Creating the encrypted workload section of a contract 

The value of any section in a contract can be plain text or encrypted. Complete the following steps on an Ubuntu system, to encrypt the workload section used in a contract:



1. Create the docker-compose.yaml file based on your workload requirements. For example,

services:
redisnode01:
image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1
ports:
- "6379:6379"

For more information, see [Overview of Docker Compose](https://docs.docker.com/compose/).
2. Create the [workload section](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_workload) of the contract and add the contents in the workload.yaml file.
3. Export the complete path of the workload.yaml file and ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt:

WORKLOAD="<PATH to workload.yaml>"
CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt>"
4. Use the following command to create a random password (the contract is encrypted via symmetric AES with a random PASSWORD):

PASSWORD="$(openssl rand 32 | base64 -w0)"
5. Use the following command to encrypt password with ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt:
* [Using an image stream from the Red Hat OpenShift web console](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesoc_imagestream_deploy-ui)



* [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)
* [Deploying containers from an encrypted image](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesencrypted-images)
* [Referring to the image pull secret in your pod deployment](https://cloud.ibm.com/docs/openshift?topic=openshift-imagespod_imagePullSecret)
* [Pushing images to IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-imagespush-images)
* [Managing security of images in IBM Cloud Container Registry with Vulnerability Advisor](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesva-images)
* [Setting up trusted content for container images](https://cloud.ibm.com/docs/openshift?topic=openshift-imagestrusted_images)
* [Enabling image security enforcement in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec)



* [Enabling or disabling image security enforcement](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-enable)
* [Default image policies](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-default-policies)





[Developing apps to run on Red Hat OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsopenshift_apps)
3. On the Share image to private catalog page, select a Private catalog from the list of available private catalogs.
4. Enter a version number in Software version.
5. Click Create catalog offering to share the image to the private catalog.
6. After the image is created, click Validate image.



This process shares only the custom image to the private catalog. The validation process occurs within the private catalog. Clicking Validate image takes you to a new page and from this screen, you can start with [Step 3: Validate the virtual server image in Onboarding a virtual server image for VPC](https://cloud.ibm.com/docs/account?topic=account-catalog-vsivpc-tutorial&interface=ui&locale=encatalog-vsivpc-review-images) to complete the validation process.





 Schedule a custom image lifecycle status change in the UI 

You can schedule either a single image lifecycle status change or schedule the status changes for the entire lifecycle of the image. You can make an immediate status change only if you didn't schedule a future status change.

Follow these 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.
2022/11/21 08:24:15 ENVIRONMENT_INIT - ENVIRONMENT_SYSTEM_STATEENUM_CREATE_SUCCESS
2022/11/21 08:24:15 Done with the blueprint init flow job

OK







 Enable BYOK or KYOK commands 

You can use your encryption keys from key management services (KMS), IBM Key Protect(BYOK), and IBM Cloud Hyper Protect Crypto Services (KYOK) to encrypt and secure data stored in Schematics. For more information about how to protect sensitive data in Schematics, see [protecting your sensitive data in Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datadata-storage).



 Prerequisites 

The key management system lists the instance that are created from your specific location and region. Following prerequisites are followed to perform the KMS activity.



* You should have your KYOK, or BYOK. To create the IBM Key Protect keys, see [create KYOK root key by using UI](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys). To create an IBM Cloud Hyper Protect Crypto Services keys, see [create BYOK root key by using UI](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-create-root-keys).
* You need to [add root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-root-keysimport-root-key-gui) to Schematics services.
* You need to configure [service to service authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauthcreate-auth) to integrate BYOK, and KYOK in Schematics service.



KMS setting is a one time settings. You need to open the [support ticket](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar) to update KMS settings.
: Is the path for the file that contains the passphrase for the registration key. The passphrase must consist of at least 6 characters. To make sure that a new line is not appended, use echo with -n or cat with EOF. If the path is not specified, you are prompted for the passphrase.

-v, --verbose
: Set to true for verbose output.
2. To create a registration file, run the hpvs registration-create command.

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]

If you enter the command without any parameters:

ibmcloud hpvs registration-create

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".

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

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

--cr-username USER-NAME
2 admin2 741a60c0a875cd91195b71f6db3cb5...

Enter the KEYNUM of any existing signature key files you want to use to create administrators. If you don't want to use existing signature key files, press enter without entering any KEYNUM values.

If you want to use a combination of existing and new signature keys, enter the KEYNUM values of the existing signature key files you want to use. You will be prompted to enter information for any new signature key files after that.

Enter the KEYNUM of the existing signature key files you want to use to create administrators:
> 1
Enter the password for the signature key identified by:
admin1 (665527ed7e97c2a083dab035f40c65...)
>

The signature key file is protected by password. You need to remember the passwords that you enter when creating new signature key files and make sure the files are not removed from your workstation. Otherwise, you are not able to perform future administrative actions that need to be signed, such as [rotating master keys](https://test.cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-rotate-master-key-cli-recovery-crypto-unit).
4. Load the master key to crypto units.

A random master key value is generated in a recovery crypto unit and is then transferred to all the other crypto units in the service instance.

The following output is an example that is displayed:

You asked to install one administrator and selected one existing signature key to use. No new signature key files will be created.

Installing 1 of 1 administrators....
Setting signature thresholds....
Generating a random master key value....
Transferring the master key value to 1 of 3 crypto units....
Transferring the master key value to 2 of 3 crypto units....
Transferring the master key value to 3 of 3 crypto units....

OK
The selected service instance has been initialized.
Valid visibility is: public or private.
* --owner-type: Filters images with given owner type. Default is all. One of: all, provider, user.
* --resource-group-id: ID of the resource group. This ID is mutually exclusive with --resource-group-name.
* --resource-group-name: Name of the resource group. This name is mutually exclusive with --resource-group-id.
* --all-resource-groups: Query all resource groups.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is image-create 

Create an image.

ibmcloud is image-create IMAGE_NAME ([--file IMAGE_FILE_LOCATION --os-name OPERATING_SYSTEM_NAME --encrypted-data-key ENCRYPTED_DATA_KEY --encryption-key ENCRYPTION_KEY]] | [--source-volume SOURCE_VOLUME --encryption-key-volume ENCRYPTION_KEY_VOLUME]) [--resource-group-id RESOURCE_GROUP_ID | --resource-group-name RESOURCE_GROUP_NAME] [--output JSON] [-q, --quiet]



 Command examples 



* ibmcloud is image-create my-ubuntu-16-amd64 --file cos://us-south/custom-image-vpc-bucket/customImage-0.qcow2 --os-name ubuntu-16-amd64
* ibmcloud is image-create my-ubuntu-16-amd64 --file cos://us-south/custom-image-vpc-bucket/customImage-0.qcow2 --os-name ubuntu-16-amd64 --resource-group-id fee82deba12e4c0fb69c3b09d1f12345
As a result, those requests will fail.







 11 April 2023 



 For all version dates 

Image lifecycle management. Accounts that have been granted special approval to preview this feature can now [deprecate](https://cloud.ibm.com/apidocs/vpc-betadeprecate-image) or [obsolete](https://cloud.ibm.com/apidocs/vpc-betaobsolete-image) custom images directly. Alternatively, you can schedule transition at a later date by specifying the deprecated_at or obsoleted_at properties when [creating](https://cloud.ibm.com/apidocs/vpc-betacreate-image) or [updating](https://cloud.ibm.com/apidocs/vpc-betaupdate-image) an image. If you need to revert a status change, you can transition deprecated or obsolete images back to available. For more information, see [Managing custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-custom-images&interface=apicustom-images-list-api).

deprecated custom images remain usable, while obsolete images cannot be used to provision instances or bare metal servers.

Revised file storage profiles. For users with accounts that have access to file shares, a new dp2 profile is now available when [creating](https://cloud.ibm.com/apidocs/vpc-betacreate-share) and [updating](https://cloud.ibm.com/apidocs/vpc-betaupdate-share) a file share. Profiles in the existing custom and tiered families have been deprecated and will remain available only to accounts that have already provisioned file shares with those profiles. The deprecated profiles also will not be included in the upcoming general availability release for file shares.

The dp2 profile belongs to a new defined_performance file share profile family, which provides similar functionality to the deprecated custom file share profile family.
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 GREP11 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 SignUpdate and 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 GREP11 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 GREP11, see [GREP11 API reference](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grep11-api-ref). You can also find Dilithium algorithm code examples in the following repositories:



* [The sample GREP11 GitHub repository for Golang](https://github.com/IBM-Cloud/hpcs-grep11-go)
* [The sample GREP11 GitHub repository for JavaScript](https://github.com/IBM-Cloud/hpcs-grep11-js)
Step 4: Set the encryption key as an environment variable 

If you create the key by following [step 3](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-import-keystutorial-import-create-key), to encode the key and set the encoded value as an environment variable, perform the following command. You can skip this step if you use your own key in this tutorial:

KEY_MATERIAL=$(openssl enc -base64 -A -in PlainTextKey.bin)





 Step 5: Encrypt the nonce with the encryption key 

For extra security, Hyper Protect Crypto Services requires nonce verification when you import a encryption key to the service.

In cryptography, a nonce serves as a session token that checks the originality of a request to protect against malicious attacks and unauthorized calls. By using the same nonce that was distributed by Hyper Protect Crypto Services, you help to ensure that your request to upload a key is valid. The nonce value must be encrypted by using the same key that you want to import into the service.

To encrypt the nonce value:



1. If you are going to use the API to perform the subsequent steps, do the following:

You don't need to perform this step if you are going to use the IBM Key Protect CLI.



1. [Download the sample kms-encrypt-nonce binary](https://github.com/IBM-Cloud/kms-samples/releases/tag/v1.1) that is compatible with your operating system. Extract the file, and then move the binary to the hs-crypto-test directory.

The binary contains a script that you can use to run AES-CBC encryption on the nonce value by using the key that you generated in [step 2](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-import-keystutorial-import-retrieve-token).
To use [Skopeo](https://github.com/containers/skopeo) to sign your images, you must create a private [GNU Privacy Guard (GnuPG or GPG)](https://gnupg.org/) identity and then run the skopeo command.

The following example doesn't include Skopeo authentication.



1. To create a GnuPG identity, run the following command.

gpg --generate-key
2. Push and sign the image at the same time by using the GnuPG identity to sign the image. Where <your_email> is the email address that you used to sign up for GnuPG, <repository:tag> is your repository and tag, and <image> is the name of your image in the format <region><namespace><repository:tag>, where <region> is the name of your region and <namespace> is the name of your namespace.

To find the names of your images, run ibmcloud cr image-list. Combine the content of the Repository column (repository) and Tag column (tag) separated by a colon (:) to create the image name in the format repository:tag. If the list images command times out, see [Why is it timing out when I list images?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-timeout) for assistance.

skopeo --insecure-policy copy --sign-by <your_email> docker-daemon:<repository:tag> docker://<image>

For example, where user@email.com is your GnuPG email address, bluebird:build1 is your repository and tag, and us.icr.io/birds/bluebird:build1 is the name of your image.

skopeo --insecure-policy copy --sign-by user@email.com docker-daemon:bluebird:build1 docker://us.icr.io/birds/bluebird:build1