vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).

After you decide whether to use your password directly or to create an access token, [create your registry access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce).





 Add registry access to Code Engine 

To set up access to an IBM Cloud Container Registry in a different IBM Cloud account, to pull images from a private Docker Hub account, or to pull or push images by using the Code Engine CLI, you can use the [IBM API key](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-your-account-api-key) or [Docker Hub password or access token](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryaccess-private-docker-hub) to create registry access through Code Engine to store your authentication key or token for you.



 Adding registry access from the console 

To add IBM Cloud Container Registry or Docker Hub access with the console,



1. Go to the [Code Engine dashboard](https://cloud.ibm.com/codeengine/overview).
2. Select a project (or [create one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project)).
3. From the project page, click Registry access.
4. Click Create.
5. Select Docker Hub or Custom.
6. Enter a name for your registry access.
7. Enter a server name for your registry. For Container Registry, the server name is <region>.icr.io. For example, us.icr.io.
To add access to a private 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 Docker Hub registry called privatedocker that is at 'https://index.docker.io/v1/' and uses your username and password.

ibmcloud ce secret create --format registry --name privatedocker --server 'https://index.docker.io/v1/' --username <Docker_User_Name> --password <Password>

Example output

Creating registry secret 'privatedocker'...
OK
3. Create your app and reference the image in your private Docker Hub registry. For example, create the myhelloapp app to reference the docker.io/privaterepo/helloworld by using the privatedocker access information.

ibmcloud ce app create --name myhelloapp --image docker.io/privaterepo/helloworld --registry-secret privatedocker

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 deploys, 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, Hello World is returned.

curl https://myhelloapp.abcdabcdhye.us-south.codeengine.appdomain.cloud







 Next steps 



* After your app deploys, [access your app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-access-service) through a URL.
Select a project (or [create one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project)).
3. From the project page, click Registry access.
4. Click Create.
5. Select Docker Hub or Custom.
6. Enter a name for your registry access.
7. Enter a server name for your registry. For Container Registry, the server name is <region>.icr.io. For example, us.icr.io. For [Docker Hub](https://hub.docker.com/), the server name is https://index.docker.io/v1/.
8. Enter a username. For IBM Cloud Container Registry, it is iamapikey. For Docker Hub, it is your Docker ID.
9. Enter the password. For IBM Cloud Container Registry, the password is your API key. For Docker Hub, you can use your Docker Hub password or an [access token](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryaccess-private-docker-hub).
10. Click Create.



You can add access to a container registry when you create an application or job, or when you build an image. Click Configure image and specify the container image to run, including the registry where the image is stored and the [registry access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registrytypes-registryaccesssecrets) to use to retrieve the image. Follow previous steps 5-9.





 Adding registry access with the CLI 

Beginning with CLI version 1.42.0, defining and working with secrets in the CLI is unified under the secret command group. See [ibmcloud ce secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) commands.
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 job configuration and reference the hello_repo image in Container Registry. For example, the following job create command creates the myhellojob job to reference the us.icr.io/mynamespace/hello_repo by using the myregistry access information.

ibmcloud ce job create --name myhellojob --image us.icr.io/mynamespace/hello_repo --registry-secret myregistry

The format of the name of the image for this job 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.







 Next steps 



* After you create your job, submit the job to run it. See [Run a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job). You can run your job multiple times.
[Here is how](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-different-account).

Can I restrict pull access to a certain regional registry or even a single namespace?
: Yes, you can edit the existing [IAM policy of the service ID](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorize-cr-service-id) that restricts the Reader service access role to that regional registry or a registry resource such as a namespace. Before you can customize registry IAM policies, you must [enable IBM Cloud IAM policies for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-user).

Can I configure a registry secret for all users in a project?
: Yes! You can use the Integration page in the console to configure settings to set up and manage registry access to images in IBM Cloud Container Registry so that all users of a specific Code Engine project can store and access images in Container Registry without having to manually create registry secrets. With sufficient permissions, you can configure this default registry access on a per location (region) basis. If you don't have sufficient permissions to perform these actions, you can use this page to help you understand the required permissions. See [Configuring project-wide settings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrations).





 Accessing images from a public account 

If your image is stored in a public repository, such as a public Docker Hub, then you can simply reference the image directly when you deploy your application or run your job. Note that while storing images in a public registry is fine for getting started with applications and jobs, store your enterprise images in a private registry.





 Accessing images in your own account from console 

If you are accessing Code Engine from an account that you own or administer, then Code Engine can automatically push and pull images to and from an IBM Cloud Container Registry namespace in your account when you create or update apps, jobs, or builds from the console.
If you have a problem when you try to log in, see [Why can't I log in to Container Registry?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login) for assistance.
3. Push the image by running the following command:

docker push us.icr.io/<my_namespace>/hello-world:1
4. Confirm that your image uploaded successfully by running the following command:

ibmcloud cr images

You can [automate access to IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_access) with

API keysand [grant access to IBM Cloud Container Registry resources](https://cloud.ibm.com/docs/Registry?topic=Registry-user) by using IAM.







 Deploy a container that uses your image 

Now that you have an image that is stored in IBM Cloud Container Registry, you can run a container on IBM Cloud Kubernetes Service that uses that image, see [Deploying apps with the CLI](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appapp_cli).

Throughout this tutorial, replace <my_cluster> with the name of your free Kubernetes cluster.



1. Run the following command:

ibmcloud ks cluster-config <my_cluster> --export

This command produces an export command that sets the KUBECONFIG environment variable.
2. Run the export command, which was generated by the previous command, by copying and pasting it.
3. Update the following line in the hello-world.yaml file by replacing <my_namespace> with your namespace:

image: us.icr.io/<my_namespace>/hello-world:1
4. Run your image as a deployment and expose it by creating a service that is accessed through the IP address of the worker node:

kubectl apply -f hello-world.yaml
5.
If you got an error during the cluster creation process or have an existing cluster, you can use this command to apply the process again.

This API key method replaces the previous method of authorizing a cluster to access IBM Cloud Container Registry by automatically creating a [token](https://www.ibm.com/cloud/blog/announcements/announcing-end-of-ibm-cloud-container-registry-support-for-uaa-tokens) and storing the token in an image pull secret. Now, by using IAM API keys to access IBM Cloud Container Registry, you can customize IAM policies for the service ID to restrict access to your namespaces or specific images. For example, you can change the service ID policies in the cluster's image pull secret to pull images from only a certain registry region or namespace. Before you can customize IAM policies, you must [enable IBM Cloud IAM policies for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-user). For more information, see [Understanding how your cluster is authorized to pull images from IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth).

When you run this command, the creation of IAM credentials and image pull secrets is initiated and can take some time to complete. You can't deploy containers that pull an image from the IBM Cloud Container Registry icr.io domains until the image pull secrets are created. To check the image pull secrets, run oc get secrets | grep icr-io. If you added IAM policies to an existing service ID, such as to restrict access to a regional registry, the service ID, IAM policies, and API key for the image pull secret are reset by this command.

ibmcloud oc cluster pull-secret apply --cluster CLUSTER

Minimum required permissions:



* Operator or Administrator platform access role for the cluster in IBM Cloud Kubernetes Service
* Administrator platform access role in IBM Cloud Container Registry across all regions and resource groups. The policy can't be scoped to a particular region or resource group.



Command options:

-c, --cluster CLUSTER
* Decide on the roles that each user needs and on which resources in IBM Cloud Container Registry, see [IAM roles](https://cloud.ibm.com/docs/Registry?topic=Registry-iamiam). You can create multiple policies, for example, you can grant write access on a resource but grant read access only on another resource. Policies are additive, which means that a global read policy and a resource-scoped write policy grants both read and write access on that resource.
* [Invite users to an account](https://cloud.ibm.com/docs/account?topic=account-iamuserinviamuserinv).

If you want users to create clusters in IBM Cloud Kubernetes Service, ensure that you assign the IBM Cloud Container Registry Administrator role to those users, and don't assign a resource group. For more information, see [Preparing to create clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusterscluster_prepare).



To create policies for IBM Cloud Container Registry, the service name field must be container-registry.

If you want to access resources, you must assign roles to users or service IDs. If you want to grant access to everything, don't specify a resource type or a resource. If you want to grant access to a specific namespace, specify the resource type as namespace and use the namespace name as the resource.



* To create a policy for users, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources).
* To create a policy for service IDs, run the ibmcloud iam service-policy-create command or use the IBM Cloud console to bind roles to your service IDs. To create policies, you must have the Administrator role. You automatically have the Administrator role on your own account.
Click Configure image and specify the container image to run, including the registry where the image is stored and the [registry access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registrytypes-registryaccesssecrets) to use to retrieve the image. Follow previous steps 5-9.





 Adding registry access with the CLI 

Beginning with CLI version 1.42.0, defining and working with secrets in the CLI is unified under the secret command group. See [ibmcloud ce secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) commands. Use the --format option to specify the category of secret, such as basic_auth, generic, ssh, tls, or registry. While you can continue to use the registry command group, take advantage of the unified secret command group. To create a secret to access a container registry, use the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command. To learn more about working with secrets in Code Engine, see [Working with secrets](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret).

To add IBM Cloud Container Registry or Docker Hub access with the CLI, use the secret create --format registry command. This command requires a name of the registry secret, the URL of the registry server, and the username and password information to access the registry server, and also allows other optional arguments. For a complete listing of options, see the [ibmcloud ce secret create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command.

For example, the following command creates registry access to an IBM Cloud Container Registry instance called myregistry that is on the us.icr.io registry server:
When I create a namespace, why aren't I authorized to access the specified resource? 

You aren't authorized to create a namespace in IBM Cloud® Container Registry.

  What’s happening 

You try to create a namespace, but you receive the following error message:

You are not authorized to access the specified resource.

  Why it’s happening 

You don't have the correct user permissions for working with namespaces. To add, assign, and remove namespaces, you must have the Manager role in the Container Registry service at the account level. If you have the Manager role on the resource group, or resource groups, it is not sufficient, the Manager role must be at the account level.

  How to fix it 

You must ensure that you are assigned the Manager role at the account level. For more information, see [User permissions for working with namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_setup_cli_namespace_plan_perm).
Create a second policy that grants the Reader and Writer roles on namespace_c to User B by running the following command.

ibmcloud iam user-policy-create <user.b@example.com> --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_c --roles Reader,Writer

This command adds two roles to the same resource in the same policy.



4. Push images into namespace_a and namespace_b.



1. Pull the hello-world image by running the following command.

docker pull hello-world
2. Tag the image to namespace_a by running the following command, where <registry_region> is the name of your [IBM Cloud Container Registry region](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions), for example us-south.

docker tag hello-world <registry_region>.icr.io/namespace_a/hello-world
3. Tag the image to namespace_b by running the following command.

docker tag hello-world <registry_region>.icr.io/namespace_b/hello-world
4. Log in to IBM Cloud Container Registry by running the [ibmcloud cr login](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_login) command.

ibmcloud cr login

IBM Cloud Container Registry supports other clients as well as Docker. To log in by using other clients, see [Accessing your namespaces interactively](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive).

If you have a problem when you try to log in, see [Why can't I log in to Container Registry?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login) for assistance.
5. Push the image to namespace_a by running the following command.
To log in by using other clients, see [Accessing your namespaces interactively](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive).

If you have a problem when you try to log in, see [Why can't I log in to Container Registry?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login) for assistance.
5. Push the image to namespace_a by running the following command.

docker push <registry_region>.icr.io/namespace_a/hello-world
6. Push the image to namespace_b by running the following command.

docker push <registry_region>.icr.io/namespace_b/hello-world



5. Prove that User B can interact with namespace_b and namespace_c, but not namespace_a.



1. Log in as User B by running the following command.

ibmcloud login -c <YourAccountID>
2. Show that User B can see namespace_b and namespace_c, but not namespace_a because User B doesn't have access to namespace_a, by running the following command.

ibmcloud cr namespaces
3. List your images by running the following command.

ibmcloud cr images

The image in namespace_b is shown in the list, but the image in namespace_a doesn't, because User B doesn't have access to namespace_a.
4. Log in to IBM Cloud Container Registry by running the following command.

ibmcloud cr login

IBM Cloud Container Registry supports other clients as well as Docker. To log in by using other clients, see [Accessing your namespaces interactively](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive).
5. Pull the image by running the following command.
How do I give the user these permissions?](https://cloud.ibm.com/docs/containers?topic=containers-access-credswhat-perms-api-key)
* [How do I limit which commands a user can run?](https://cloud.ibm.com/docs/containers?topic=containers-access-credslimit-apikey-scopes)
* [What if I don't want to assign the API key owner or credentials owner the Super User infrastructure role?](https://cloud.ibm.com/docs/containers?topic=containers-access-credsnon-superuser)
* [What happens if the user who set up the API key for a region and resource group leaves the company?](https://cloud.ibm.com/docs/containers?topic=containers-access-credsapikey-user-leaves)
* [How can I lock down my cluster if my API key becomes compromised?](https://cloud.ibm.com/docs/containers?topic=containers-access-credsapikey-lockdown)



* [Ensuring that the API key or infrastructure credentials owner has the correct permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsowner_permissions)
* [Understanding access to the infrastructure portfolio](https://cloud.ibm.com/docs/containers?topic=containers-access-credsunderstand_infra)
* [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)
: If you want to manage your Vulnerability Advisor exemption policies for security issues, depending on the task that you want to complete, you might have to update your access role.

For more information, see [Access roles for configuring Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure).





 29 July 2020 

You can set permissions so that access to resources within a namespace can be configured at the resource group level
: Namespaces are created in resource groups so that access to resources within a namespace can be configured at the resource group level. If a namespace isn't already in a resource group, you can assign the namespace to a resource group.



* Namespaces created in version 0.1.485 of the Container Registry CLI or later, or in the IBM Cloud console on or after 29 July 2020, are created in a resource group that you specify so that you can configure access to resources within the namespace at the [resource group](https://cloud.ibm.com/docs/account?topic=account-rgs) level. However, you can still set permissions for the namespace at the account level or in the namespace itself. For more information, see [Set up a namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_namespace_add) and [ibmcloud cr namespace-add](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_namespace_add).
* Namespaces created in version 0.1.484 of the Container Registry CLI or earlier, or in the IBM Cloud console before 29 July 2020 aren't assigned to resource groups. You can assign an existing namespace to a resource group so that you can configure access to resources within a namespace at the resource group level.