vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Delete a configuration issue exemption for issue application_configuration:nginx.ssl_protocols for a single image with the digest us.icr.io/birds/bluebird@sha256:101010101010.

ibmcloud cr exemption-rm --scope us.icr.io/birds/bluebird@sha256:101010101010 --issue-type configuration --issue-id application_configuration:nginx.ssl_protocols







 ibmcloud cr exemption-types 

Lists the types of security issues that you can exempt.

ibmcloud cr exemption-types



 Prerequisites 

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







 ibmcloud cr iam-policies-enable 

From 5 July 2022, all accounts require Cloud Identity and Access Management (IAM) access policies. If you started to use IBM Cloud Container Registry before the availability of [IAM API key policies in Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-25feb2019) in February 2019, you must ensure that you are using IAM access policies to manage access to the Container Registry service. For more information, see [IAM access policies are required from 5 July 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policy).

If you're using IAM authentication, this command enables fine-grained authorization. For more information, see [Managing IAM access for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iam) and [Defining IAM access policies](https://cloud.ibm.com/docs/Registry?topic=Registry-useruser).

ibmcloud cr iam-policies-enable



 Prerequisites
Configure an HSM client image[See Build a Docker image](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-hsm-build-docker).
3. Configure the node to use HSM. From the APIs or the console, when you deploy a peer, CA, or ordering node, you can select the advanced option to use an HSM. See [Configure the node to use the HSM](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-cfg-hsm-node).







 Before you begin 



* The Kubernetes CLI is required to configure the HSM. If you are using a Kubernetes cluster on IBM Cloud see [Getting started with IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) or [Installing the OpenShift CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-cli).
* You need access to a container registry, such as Docker or the [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).







 Build a Docker image 

Configure HSM on your blockchain network by publishing an HSM client image to a container registry, as described below.

Build an HSM client image

Next we build a Docker file that contains the HSM client image. These instructions assume that you have successfully configured your HSM appliance and HSM client. Use these steps to generate an image that is consumable by the IBM Blockchain Platform operator.



* Step one: Modify the HSM client configuration.
* Step two: Build the HSM client image.
* Step three: Push the Docker image to your container registry.
To create an IBM Cloud IAM API key with the CLI, run the [iam api-key-create](https://cloud.ibm.com/docs/account?topic=cli-ibmcloud_commands_iamibmcloud_iam_api_key_create) command. For example, to create an API key called cliapikey with a description of "My CLI API key" and save it to a file called key_file, run the following command:

ibmcloud iam api-key-create cliapikey -d "My CLI API key" --file key_file

If you choose to not save your key to a file, you must record the API key that is displayed when you create it. You cannot retrieve it later.
2. After you create your API key, add registry access to Code Engine. To add access to Container Registry with the CLI, use the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command to create a registry secret. For example, the following command creates registry access to a Container Registry instance called myregistry. Note, even though the --server and --username options are specified in the example command, the default value for the --server option is us.icr.io and the --username option defaults to iamapikey when the server is us.icr.io.

ibmcloud ce secret create --format registry --name myregistry --server us.icr.io --username iamapikey --password APIKEY

Example output

Creating registry secret 'myregistry'...
OK
3. Create your app and reference the hello_repo image in Container Registry.
Building images for your apps 

A Docker image is the basis for every container that you create with Red Hat® OpenShift® on IBM Cloud®.

An image is created from a Dockerfile, which is a file that contains instructions to build the image. A Dockerfile might reference build artifacts in its instructions that are stored separately, such as an app, the app's configuration, and its dependencies.



 Building images 

You can build your images in several ways, including the following IBM Cloud services.

IBM Cloud Code Engine
: Code Engine supports building images from a Dockerfile and Cloud Native Buildpacks and automatically pushing the images to IBM Cloud® Container Registry. For more information, see [Planning your build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-build).

Tekton pipelines
: The Continuous Delivery service includes several Tekton tasks that you can reference within your pipelines to build images. For more information, see [Tekton pipelines](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-pipeline_container_imagespipeline_tekton_images).





 Deploying containers from an existing image stream in the internal registry 

You can deploy an app from an existing [image stream](https://docs.openshift.com/container-platform/4.11/openshift_images/image-streams-manage.html) that your cluster administrator set up in the internal registry of your Red Hat OpenShift cluster. For example, your cluster administrator might have [set up the image stream to import an image from an external private registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry), such as IBM Cloud Container Registry.



 Using an image stream with the CLI 



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. List the available image streams in a project.
Create a job configuration that uses an image in Container Registry by using the Code Engine console.

Code Engine can automatically pull images from a Container Registry namespace in your account. To pull images from a different Container Registry account or from a private Docker Hub account, see [Create a job from images in a private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job-private).



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating from Run a container image.
3. Select Job.
4. Enter a name for the job; for example, myjob.
5. Select a project from the list of available projects. You can also [create a new one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project). Note that you must have a selected project to create a job.
6. Select Container image and click Configure image.
7. Select a container registry location, such as IBM Registry, Dallas.
8. Select Code Engine managed secret for Registry access secret. Because this example uses an image in a Container Registry namespace in your account, Code Engine can automatically create and manage the registry access secret for you.
9. Select an existing namespace and name of the image in the registry for the Code Engine job to reference. For example, select mynamespace and select the image hello_repo in that namespace.
10. Select a value for Tag; for example, latest.
11. Click Done.
12. Modify any default values for environment variables or runtime settings. For more information about these options, see [Options for creating and running a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-planjob-options).
13. From the Create job page, click Create.
14.
For more information, see [Navigating the Red Hat OpenShift console](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_tutorialopenshift_oc_console).

openshift-dns, openshift-dns-operator
: The DNS project includes the components to validate incoming network traffic against the iptables rules that are set up on the worker node, and proxies requests that are allowed to enter or leave the cluster.

openshift-image-registry
: Red Hat OpenShift provides an internal [container image registry](https://docs.openshift.com/container-platform/4.11/registry/index.html) that you can use to locally manage and view images through the console. Alternatively, you can [set up the private IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_iccr) or [import images from IBM Cloud Container Registry to the internal registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry). The internal registry comes with a classic IBM Cloud File Storage for Classic volume in your IBM Cloud infrastructure account to [store the registry images](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_internal_registry). The file storage volume is provisioned through the image-registry-storage persistent volume claim (PVC).

openshift-ingress, openshift-ingress-operator
: Red Hat OpenShift uses [routes](https://docs.openshift.com/container-platform/4.11/networking/routes/route-configuration.html) to directly expose an app's service on a hostname so that external clients can reach the service. To create routes, the cluster uses the Ingress operator.
Why can't I push images to the internal registry from outside the VPC network? 

Infrastructure provider and applicable versions:



*  VPC
*  Red Hat OpenShift 4.4 or later



  What’s happening 

When you try to push container images to the internal Red Hat OpenShift container image registry, the push fails with a message similar to the following.

dial tcp 161.26.0.28:443: connect: network is unreachable

  Why it’s happening 

Red Hat OpenShift on IBM Cloud clusters that run on the VPC infrastructure provider use IBM Cloud Object Storage to store data from the cluster's internal container registry. By default, access to the Object Storage endpoint is available only from inside a VPC instance. Therefore, when external process such as a local machine or CI/CD pipeline try to push container images to the internal registry from outside the VPC, the image push fails.

  How to fix it 

Modify the custom resource of the internal image registry operator to proxy container image traffic through the internal registry pods to the direct Object Storage endpoints.

Run the following command to patch the configs.imageregistry.operator.openshift.io/cluster resource to set the disableRedirect property to true.

oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"disableRedirect":true}}' --type=merge
The Unix socket uses the SELinux labels in the following table to enforce the appropriate system access policies. These labels prevent user containers from being able to access the container runtime socket.



SELinux labels that are used to protect container runtime processes.

 Process SELinux label 

 CRI-O system_u:system_r:container_runtime_t:s0 
 kubelet system_u:system_r:unconfined_service_t:s0 
 crio.sock system_u:object_r:container_var_run_t:s0 
 A container process, such as c14 system_u:system_r:container_t:s0:c14 



Example request flow

The following diagram presents an example request flow between the kubelet and CRI-O.

Zoom

![Example request flow between kubelet and CRI-O.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/crio-selinux.png)

Figure 1. Example request flow between kubelet and CRI-O





 Image and registry 

Every deployment is based on an image that holds the instructions for how to spin up the container that runs your app. These instructions include the operating system inside the container and extra software that you want to install. To protect your app, you must protect the image and establish checks to ensure the image's integrity.

Should I use a public or a private registry to store my images?
: Public registries, such as Docker Hub, can be used to get started with Docker images and Kubernetes to create your first containerized app in a cluster. But when it comes to enterprise applications, avoid registries that you don't know or don't trust to protect your cluster from malicious images.
List the policies for User B by running the following command.

ibmcloud iam user-policies <user.b@example.com>

Find the policies that you created and note the Policy IDs.
3. Delete the policies that you created by running the following command, where <Policy_ID> is the Policy ID.

ibmcloud iam user-policy-delete <user.b@example.com> <Policy_ID>









 Step 3: Create a service ID and grant access to a resource 

Configure a service ID and grant it access to your IBM Cloud Container Registry namespace.



1. Set up a service ID with access to IBM Cloud Container Registry and create an

API keyfor it.



1. Log in to User A's account by running the following command.

ibmcloud login
2. Create a service ID named cr-roles-tutorial with the description "Created during the access control tutorial for Container Registry" by running the following command.

ibmcloud iam service-id-create cr-roles-tutorial --description "Created during the access control tutorial for Container Registry"
3. Create a service policy for the service ID that grants the Reader role on namespace_a by running the following command.

ibmcloud iam service-policy-create cr-roles-tutorial --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_a --roles Reader
4. Create a second service policy that grants the Writer role on namespace_b by running the following command.

ibmcloud iam service-policy-create cr-roles-tutorial --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_b --roles Writer
5. Create an API key for the service ID by running the following command.

ibmcloud iam service-api-key-create cr-roles-tutorial-apikey cr-roles-tutorial



2.
: Required. If you have one, enter your Docker email address. If you don't have one, enter a fictional email address, such as a@b.c. This email is required to create a Kubernetes secret, but is not used after creation.
2. Verify that the secret was created successfully. Replace <namespace> with the name of the namespace where you created the image pull secret.

kubectl get secrets --namespace <namespace>
3. [Create a pod that references the image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret).









 Using the image pull secret to deploy containers 

You can define an image pull secret in your pod deployment or store the image pull secret in your Kubernetes service account so that it is available for all deployments that don't specify a Kubernetes service account in the namespace.

To plan how image pull secrets are used in your cluster, choose between the following options.



* Referring to the image pull secret in your pod deployment: Use this option if you don't want to grant access to your registry for all pods in your namespace by default. Developers can [include the image pull secret in each pod deployment](https://cloud.ibm.com/docs/containers?topic=containers-imagespod_imagePullSecret) that must access your registry.
* Storing the image pull secret in the Kubernetes service account: Use this option to grant access to images in your registry for all deployments in the selected Kubernetes namespaces. To store an image pull secret in the Kubernetes service account, use the [following steps](https://cloud.ibm.com/docs/containers?topic=containers-registrystore_imagePullSecret).





 Storing the image pull secret in the Kubernetes service account for the selected namespace 

Every Kubernetes namespace has a Kubernetes service account that is named default. Within the namespace, you can add the image pull secret to this service account to grant access for pods to pull images from your registry.
If you have one, enter your Docker email address. If you don't have one, enter a fictional email address, such as a@b.c. This email is required to create a Kubernetes secret, but is not used after creation.
2. Verify that the secret was created successfully. Replace <project> with the name of the project where you created the image pull secret.

oc get secrets --namespace <project>
3. [Create a pod that references the image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).









 Using the image pull secret to deploy containers 

You can define an image pull secret in your pod deployment or store the image pull secret in your Kubernetes service account so that it is available for all deployments that don't specify a Kubernetes service account in the project.

To plan how image pull secrets are used in your cluster, choose between the following options.



* Referring to the image pull secret in your pod deployment: Use this option if you don't want to grant access to your registry for all pods in your project by default. Developers can [include the image pull secret in each pod deployment](https://cloud.ibm.com/docs/openshift?topic=openshift-imagespod_imagePullSecret) that must access your registry.
* Storing the image pull secret in the Kubernetes service account: Use this option to grant access to images in your registry for all deployments in the selected Red Hat OpenShift projects. To store an image pull secret in the Kubernetes service account, use the [following steps](https://cloud.ibm.com/docs/openshift?topic=openshift-registrystore_imagePullSecret).





 Storing the image pull secret in the Kubernetes service account for the selected project 

Every Red Hat OpenShift project has a Kubernetes service account that is named default. Within the project, you can add the image pull secret to this service account to grant access for pods to pull images from your registry.
Why do commands fail saying that I'm not logged in? 

You are logged in to IBM Cloud but you can't run any commands in IBM Cloud® Container Registry. You get the following message: FAILED You are not logged in to IBM Cloud.

  What’s happening 

All ibmcloud cr commands fail with the message: FAILED You are not logged in to IBM Cloud.

  Why it’s happening 

The container-registry CLI plug-in is out of date and needs updating.

  How to fix it 

Upgrade to the most recent version of the container-registry CLI plug-in, see [Updating the container-registry CLI plug-in](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_cli_update).
: An app might refer to a complete app or a component of an app. You might deploy components of an app in separate pods or separate worker nodes. For more information, see [Planning app deployments](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deploy) and [Developing Kubernetes-native apps](https://cloud.ibm.com/docs/containers?topic=containers-app).

To dive deeper into Kubernetes, see the [Kubernetes documentation](https://kubernetes.io/docs/home/?path=users&persona=app-developer<=vel=foundational).





 What are containers? 

Containers provide a standard way to package your application's code, configurations, and dependencies into a single unit that can run as a resource-isolated process on a compute server. To run your app in Kubernetes on Red Hat OpenShift on IBM Cloud, you must first containerize your app by creating a container image that you store in a container registry.

Built on existing Linux container technology (LXC), the open source project that is named Docker defined templates for how to package software into standardized units, called containers, that include all the elements that an app needs to run. Red Hat OpenShift on IBM Cloud uses cri-o as the container runtime to deploy containers from Docker container images into your cluster.

Image
: A container image is the base for every container that you want to run. Container images are built from a Dockerfile, a text file that defines how to build the image and which build artifacts to include in it, such as the app, the app configuration, and its dependencies. Images are always built from other images, making them quick to configure. Let someone else do the bulk of the work on an image and then tweak it for your use.

Registry
: An image registry is a place to store, retrieve, and share container images. Images that are stored in a registry can either be publicly available (public registry) or accessible by a small group of users (private registry).
For this example, update the myhelloapp that you created in [Deploying an application that references an image in a container registry with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-crimagedeploy-app-crimage-cli) to reference a different image in a different namespace in the same account. Update the app to reference the helloworld_repo image in the mynamespace2 namespace in Container Registry.



1. Add a different image to Container Registry. For this example, add the helloworld_repo image in the mynamespace2 namespace in Container Registry. For more information about adding an image to Container Registry, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started).
2. Add registry access to Code Engine. For this example, because the helloworld_repo image resides in the same account, use the previously defined myregistry registry access.
3. Update your app and reference the image in Container Registry by using the myregistry access. For example, update the myhelloapp app to reference the us.icr.io/mynamespace2/helloworld_repo by using the myregistry access information.

ibmcloud ce app update --name myhelloapp --image us.icr.io/mynamespace2/helloworld_repo:1 --registry-secret myregistry

The format of the name of the image for this application is REGISTRY/NAMESPACE/REPOSITORY:TAG where REGISTRY and TAG are optional. If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest.
4. After your app is updated, you can access the app. To obtain the URL of your app, run ibmcloud ce app get --name myhelloapp --output url. When you curl the myhelloapp app, the app returns Hello World from Code Engine, which demonstrates the app is now using the helloworld_repo image.