vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Accessing the infrastructure portfolio with your IBM Cloud Pay-As-You-Go or Subscription account](https://cloud.ibm.com/docs/containers?topic=containers-access-credsdefault_account)
* [Accessing a different classic infrastructure account](https://cloud.ibm.com/docs/containers?topic=containers-access-credscredentials)
* [Customizing classic infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access)



* [Assigning infrastructure access through the console](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_console)
* [Assigning infrastructure access through the CLI](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_cli)





[Controlling user access with IBM Cloud IAM and Kubernetes RBAC](https://cloud.ibm.com/docs/containers?topic=containers-usersusers)



* [Example cluster use cases and IAM roles](https://cloud.ibm.com/docs/containers?topic=containers-usersexample-iam)
* [Assigning IBM Cloud IAM roles with the console](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users)
* [Assign IBM Cloud IAM roles with the CLI](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli)



* [Assigning IBM Cloud IAM platform roles from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_platform)
* [Assigning IBM Cloud IAM service roles from the CLI:**](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_service)
For more information, see [Granting access to IBM Cloud Container Registry resources tutorial](https://cloud.ibm.com/docs/Registry?topic=Registry-iam_access) and [Managing IAM access for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iam).
* How can I share an image with many users?

 How can I share an image with many users? 

You can create an IBM Cloud account and invite all the users to it. They can then all have access to any namespace A collection of repositories that store images in a registry. A namespace is associated with an IBM Cloud account, which can include multiple namespaces. that is created in the account. You can create a subset of the users and set an IAM access policy to differentiate access at the namespace level. Users can be members of many accounts, but you can't give access outside the account, that is, you can't share a namespace to multiple accounts.

For more information, see [Defining IAM access policies](https://cloud.ibm.com/docs/Registry?topic=Registry-user).
* Do I have any untagged images?

 Do I have any untagged images? 

To find out whether you have any [untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_untagged) images, list your images by running the [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests) command. Untagged images have a hyphen (-) in the Tags column.
* Do I need untagged images?

 Do I need untagged images? 

If you have active containers that are running [untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_untagged) images, you must retain the untagged images.
ibmcloud cr info will return the name of the container registry.

ibmcloud cr info

Set the variable accordingly:

MYCONTAINERREGISTRY=<us.icr.io_like_value_returned_from_ibmcloud_cr_info>

Set the variable to a name you want to used as a new namespace:

MYNAMESPACE=<my_container_registry_namespace>
5. Create a namespace to store the container image. Feel free to skip this step and use an existing namespace.

ibmcloud cr namespace-add $MYNAMESPACE
6. Build a Docker image using the [Dockerfile](https://github.com/IBM-Cloud/cdn-with-cda-todolist/blob/master/Dockerfile) in Container Registry and use cdn-with-cda-todolist as the image name:

docker build -t $MYCONTAINERREGISTRY/$MYNAMESPACE/cdn-with-cda-todolist:latest .
7. Log in Container Registry:

ibmcloud cr login
8. Push the image to Container Registry:

docker push $MYCONTAINERREGISTRY/$MYNAMESPACE/cdn-with-cda-todolist:latest







 Run the application in the cluster 



1. Run the command below to target the cluster where to deploy the application.

ibmcloud ks cluster config --cluster $MYCLUSTER
2. Retrieve the cluster ingress subdomain and secret name:

ibmcloud ks cluster get --cluster $MYCLUSTER
3. Copy deployment.sample.yaml to deployment.yaml:

cp deployment.sample.yaml deployment.yaml
4. Edit deployment.yaml and replace the placeholders <image>, <ingress-subdomain> and <ingress-secret> with values matching your environment.
5. Deploy the application to the cluster:

kubectl apply -f deployment.yaml
6.
Public IBM images 

You can access the images that are provided by IBM by using the IBM Cloud® Container Registry command line.

You can't access the public IBM images by using the IBM Cloud console anymore.



  Accessing the public IBM images by using the CLI 

You can access the public IBM images by using the command line.

Before you begin, complete the following tasks.



1.  Ensure that the IBM Cloud Container Registry CLI is installed, see [Installing the container-registry CLI plug-in](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespacecli_namespace_registry_cli_install).
2.  Log in to [IBM Cloud](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login).

ibmcloud login



To list the public images, complete the following steps.



1.  Target the global registry:

ibmcloud cr region-set global
2.  List the IBM public images.

ibmcloud cr images --include-ibm
To allow users to bind services to the cluster or to view logs that are forwarded from cluster logging configurations, [grant users Cloud Foundry roles](https://cloud.ibm.com/docs/account?topic=account-mngcf) for the org and space that the services are deployed to or where logs are collected.
5. If you use Kubernetes namespaces to isolate resources within the cluster, grant access to namespaces by [assigning users IBM Cloud IAM service access roles for the namespaces](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).
6. For any automation tooling such as in your CI/CD pipeline, set up service accounts and [assign the service accounts Kubernetes RBAC permissions](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac)).



For more information about setting up your account and resources, try out this tutorial about the [best practices for organizing users, teams, and applications](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-users-teams-applications).





 Other types of access control 

Besides IBM Cloud IAM access control policies that you set up, you might explore the additional ways to control how your cluster can be accessed.



 Cluster network setup 



* Cloud service endpoints: You might consider creating a cluster with only a private cloud service endpoint for communication to the cluster's API server. You can also [create an allowlist for the private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clusterprivate-se-allowlist) to limit access to your cluster from only the allowed subnets. For more information, see the different service architecture setups for [classic](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_classic) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_vpc) clusters.
Your containers must be authorized to pull images by using the secret that you created. You can add the image pull secret to the service account for the namespace, or refer to the secret in each deployment. For instructions, see [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).





 Private network connection to icr.io registries 

When you use the private network to pull images, your image pull traffic is not charged as [public bandwidth](https://cloud.ibm.com/docs/openshift?topic=openshift-costsbandwidth), because the traffic is on the private network. For more information, see the [IBM Cloud Container Registry private network documentation](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_private).

When you set up your IBM Cloud account to use service endpoints, you can use a private network connection to push images to and to pull images from IBM Cloud Container Registry.

What do I need to do to set up my cluster to use the private connection to icr.io registries?



1. Enable a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account so that you can use the IBM Cloud Container Registry private cloud service endpoint. To enable VRF, see [Enabling VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf). To check whether a VRF is already enabled, use the ibmcloud account show command.
2. [Enable your IBM Cloud account to use service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointservice-endpoint).



Now, IBM Cloud Container Registry automatically uses the private cloud service endpoint. You don't need to enable the private cloud service endpoint for your Red Hat OpenShift on IBM Cloud clusters.
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). Red Hat OpenShift on IBM Cloud offers public images, such as ibmliberty, that you can use to create your first containerized app. When it comes to enterprise applications, use a private registry like the one that is provided in IBM Cloud to protect your images from being used by unauthorized users.

Container
: Every container is created from an image. A container is a packaged app with all its dependencies so that the app can be moved between environments and run without changes. Unlike virtual machines, containers don't virtualize a device, its operating system, and the underlying hardware. Only the app code, run time, system tools, libraries, and settings are packaged inside the container. Containers run as isolated processes on Ubuntu compute hosts and share the host operating system and its hardware resources. This approach makes a container more lightweight, portable, and efficient than a virtual machine.

For more information, see the [Docker documentation](https://docs.docker.com/).

Looking for even more education? [Learn how Docker and Red Hat OpenShift on IBM Cloud work together by completing this course.](https://cognitiveclass.ai/courses/docker-essentials)





 What is Red Hat OpenShift? 

Red Hat OpenShift is a Kubernetes container platform that provides a trusted environment to run enterprise workloads. It extends the Kubernetes platform with built-in software to enhance app lifecycle development, operations, and security. With Red Hat OpenShift, you can consistently deploy your workloads across hybrid cloud providers and environments.
If a specific role and its actions don't fit the use case that you're looking to address, you can [create a custom role](https://cloud.ibm.com/docs/account?topic=account-custom-rolescustom-access-roles) and pick the actions to include.

Review the following tables that outline the actions that each role allows within the Container Registry service.



* [Platform management roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamplatform_management_roles) enable users to perform tasks on service resources at the platform level, for example, assign user access to the service, create or delete instances, and bind instances to applications.
* [Service access roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamservice_access_roles) enable users access to Container Registry and the ability to call the Container Registry API.



For more information about the exact actions that are mapped to each role, see [IAM roles and actions for Container Registry](https://cloud.ibm.com/docs/account?topic=account-iam-service-roles-actionscontainer-registry-roles).

For more information about assigning user roles in the UI, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources).





 Context-based restrictions 

Container Registry also supports context-based restrictions. You can use context-based restrictions to define and enforce access restrictions for IBM Cloud resources based on the network location of access requests. These restrictions work with traditional IAM policies, which are based on identity, to provide an extra layer of protection.

For more information, see [What are context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis).

For an example of how to set up context-based restrictions, see the context-based restrictions tutorial [Leveraging context-based restrictions to secure your resources](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-tutorial).
* When you deploy apps or run jobs and your registry uses an IBM Cloud Container Registry namespace that is in your account, then you can let Code Engine automatically create and manage the registry secret for you, as long as your account has the required permissions as described in the following table.



* In the console, this registry access secret is called a Code Engine managed secret. This option is available when you use the Configure image or Specify build details workflows for building an image with Code Engine.
* In the CLI, this registry secret is of the format, ce-auto-icr-private-<region>. This registry secret is automatically created when you specify the --build-source option but you do not provide the --registry-secret option with the app create, app update, job create, or job update commands.







Table 2. Access authorities for image registry

 Action IAM service access Description 

 Pull images Reader service access When you deploy an image as an application or job, you must pull the image from a registry. To pull images, you need read access. If the registry is public, you already have read access to the images. If the registry is private, then a registry secret is required. 
 Push images Reader and Writer service access When you build source code, you must push the image to a registry. To push images to your registry, you must have read and write access, and you must have a registry secret. 
 Create a namespace Reader, Writer, and Manager service access This action is only supported for IBM Cloud Container Registry. 
 Code Engine automatically created registry secret Administrator platform access <br>Reader, Writer, and Manager service access This action is only supported for IBM Cloud Container Registry. 



Can I use a service ID?

Yes, you can create a service ID and assign authorities to it. Note that service IDs are also automatically created by the Code Engine UI when you automatically create access to your IBM Cloud Container Registry. DO NOT delete this service ID as you will lose access to the images in the registry.

Can I access images in a different registry?

Yes! [Here is how](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-different-account).
Why am I getting an Unauthorized error when I'm using Code Engine? 

You are trying to access IBM Cloud® Container Registry but are getting an Unauthorized error.

  What’s happening 

When you try to access Container Registry, you get the following message. You might see this error message if you are using IBM Cloud Code Engine.

Status code 401 Unauthorized

  Why it’s happening 

You are trying to access Container Registry by using IBM Cloud Code Engine and you don't have the correct credentials.

  How to fix it 

If you are accessing Container Registry through Code Engine, confirm that Code Engine is using a pull secret with a valid API key. For more information, see [Add registry access to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce).
docker tag hello-world:latest image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
3. Push the image to your cluster's internal registry.

docker push image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
4. Verify that the image is added to the Red Hat OpenShift image stream.

oc get imagestream

Example output

NAME DOCKER REPO TAGS UPDATED
hello-world image-registry-openshift-image-registry.svc:5000/default/hello-world latest 7 hours ago



8. To enable deployments in your project to pull images from the internal registry, create an image pull secret in your project that holds the credentials to access your internal registry. Then, add the image pull secret to the default service account for each project.



1. List the image pull secrets that the default service account uses, and note the secret that begins with default-dockercfg.

oc describe sa default

Example output

...
Image pull secrets:
all-icr-io
default-dockercfg-mpcn4
...
2. Get the encoded secret information from the data field of the configuration file.

oc get secret <default-dockercfg-name> -o yaml

Example output

apiVersion: v1
data:
.dockercfg: ey...=
3. Decode the value of the data field.

echo "<ey...=>" | base64 -D

Example output

{"172.21.xxx.xxx:5000":{"username":"serviceaccount","password":"eyJ...
4. Create a new image pull secret for the internal registry.
Why am I getting Access denied errors about my quota? 

You have a valid IAM API key or OAuth token, but you still get Access denied errors about your quota in IBM Cloud® Container Registry.

  What’s happening 

When you try to access Container Registry, you get one of the following messages.



*  Your account has exceeded its pull traffic quota for the current month.
*  Your account has exceeded its image storage quota for the current month.



  Why it’s happening 

You exceeded your image storage quota or pull traffic quota.

  How to fix it 

Review your quota limits and increase them as necessary. However, increasing your quota does increase your costs. For more information, see [Managing quota limits for storage and pull traffic](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quotaregistry_quota_get).
In the CLI, the name of an automatically created registry secret is of the format, ce-auto-icr-private-<region>.
* User managed secret - This is a secret that you create and manage. You can [access images from your account with an API key](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-your-account-api-key) or use an access token for the container registry of your choice; for example, Docker Hub. For this case, the registry access secret that is listed in the console is the name of your registry secret.



If your registry is public and does not require credentials; for example, Code Engine sample images in icr.io/codeengine or Docker Hub public, then you do not need a registry secret. For this case, the registry access secret that is listed in the console is None.





 Setting up authorities for image registries 

If your registry is public, you do not have to set up authorities to pull images. Note that pulling images from a public registry while you are getting started with Code Engine is acceptable. Use a private registry when it comes to your enterprise workloads.

What authorities do I need?

To determine the authorities that you need, consider the following cases:



* When you deploy apps or run jobs, Code Engine can automatically access images that are in your own account.
* If you want to access images from a shared account, other IBM Cloud accounts, or a private Docker account, you must be assigned the proper access authorities.
* When you deploy apps or run jobs and your registry uses an IBM Cloud Container Registry namespace that is in your account, then you can let Code Engine automatically create and manage the registry secret for you, as long as your account has the required permissions as described in the following table.



* In the console, this registry access secret is called a Code Engine managed secret. This option is available when you use the Configure image or Specify build details workflows for building an image with Code Engine.
* In the CLI, this registry secret is of the format, ce-auto-icr-private-<region>.
Logging in to Container Registry by using the ibmcloud cr login command is subject to IAM login session limits. If your login expires, see [Why does the Container Registry login keep expiring?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login-expire) for assistance.



 Prerequisites 

None





 Command options 

CLIENT
: (Optional) Select the client that you want to log in. Valid values are docker and podman. If this option is not used and Docker is installed, the default is docker; if Docker is not installed, the default is podman.





 Example 

To log in to the registry with Podman, run the following command.

ibmcloud cr login --client podman







 ibmcloud cr manifest-inspect 

View the contents of the [manifest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_manifest) for an image. You can reference the image that you want to inspect either by digest or by tag.

ibmcloud cr manifest-inspect [--quiet | -q ] IMAGE



 Prerequisites 

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





 Command options 

IMAGE
: The name of the image for which you want to inspect the manifest. You can identify images by using either the digest <dns>/<namespace>/<repo>@<digest> or by tag <dns>/<namespace>/<repo>:<tag>. Where <dns> is the domain name, <namespace> is the namespace, <repo> is the repository, <digest> is the digest, and <tag> is the tag.

To find the names of your images, run one of the following commands:



* To identify your image by digest, run the ibmcloud cr image-digests command.