vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Creating an API key from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryaccess-registry-account-console)
* [Creating an API key with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryaccess-registry-account-cli)



* [Accessing images in a shared account](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-shared-account)
* [Accessing images in a different account](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-different-account)
* [Accessing images in a private Docker Hub account](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryaccess-private-docker-hub)
* [Add registry access to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce)



* [Adding registry access from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce-console)
* [Adding registry access with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce-cli)



* [Authorizing access to Container Registry with service ID](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorize-cr-service-id)



* [Authorizing access to Container Registry with service ID from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorize-console-service-id)
* [Create new IAM API key credentials and store them in an image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryother_registry_accounts) to access images in other IBM Cloud accounts or to apply IAM policies that restrict access to certain registry domains or namespaces.
* [Create an image pull secret to access images in external private registries](https://cloud.ibm.com/docs/containers?topic=containers-registryprivate_images).



If you already created an image pull secret in your namespace that you want to use in your deployment, see [Deploying containers by using the created imagePullSecret](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret).



 Copying an existing image pull secret 

You can copy an image pull secret, such as the one that is automatically created for the default Kubernetes namespace, to other namespaces in your cluster. If you want to use different IBM Cloud IAM API key credentials for this namespace such as to restrict access to specific namespaces, or to pull images from other IBM Cloud accounts, [create an image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryother_registry_accounts) instead.



1. List available Kubernetes namespaces in your cluster, or create a namespace to use.

kubectl get namespaces

Example output

default Active 79d
ibm-cert-store Active 79d
ibm-system Active 79d
kube-public Active 79d
kube-system Active 79d

To create a namespace

kubectl create namespace <namespace_name>
2. List the existing image pull secrets in the default Kubernetes namespace for IBM Cloud Container Registry.

kubectl get secrets -n default | grep icr-io

Example output

all-icr-io          kubernetes.io/dockerconfigjson        1         16d
3.
This requires additional Kubernetes configuration (e.g. [creating a container registry secret in the new namespace](https://cloud.ibm.com/docs/containers?topic=containers-registryother)).



4. Run the below command to generate secure-file-storage.yaml. It will use the environment variables you just configured together with the template file secure-file-storage.template.yaml.

./generate_yaml.sh



As example, assuming the application is deployed to the default Kubernetes namespace:



Environment variables used by the script

 Variable Value Description 

 $IMAGE_PULL_SECRET Do not define when using provided image A secret to access the registry. 
 $IMAGE_REPOSITORY icr.io/solution-tutorials/tutorial-cloud-e2e-security or icr.io/namespace/image-name The URL-like identifier for the built image based on the registry URL, namespace and image name from the previous section. 
 $TARGET_NAMESPACE default the Kubernetes namespace where the app will be pushed. 
 $INGRESS_SUBDOMAIN secure-file-stora-123456.us-south.containers.appdomain.cloud Retrieve from the cluster overview page or with ibmcloud ks cluster get --cluster <your-cluster-name>. 
 $INGRESS_SECRET secure-file-stora-123456 Retrieve with ibmcloud ks cluster get --cluster <your-cluster-name>. 
 $BASENAME secure-file-storage The prefix used to identify resources. 







 Deploy to the cluster 



1. If not present, enable the [ALB OAuth Proxy add-on](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsapp-id) in your cluster.

ibmcloud ks cluster addon enable alb-oauth-proxy --cluster $MYCLUSTER

You can check for existing add-ons with this command:

ibmcloud ks cluster addon ls --cluster $MYCLUSTER
2.
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 

SOURCE_IMAGE
: The name of the source image. You can identify source 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.

TARGET_IMAGE
: The name of the target image. TARGET_IMAGE must be in the format repository:tag, for example, us.icr.io/namespace/image:latest.





 Examples 

Add another tag reference, latest, to the image us.icr.io/birds/bluebird:1.

ibmcloud cr image-tag us.icr.io/birds/bluebird:1 us.icr.io/birds/bluebird:latest

Copy the image us.icr.io/birds/bluebird:peck to another repository in the same namespace birds/pigeon.

ibmcloud cr image-tag us.icr.io/birds/bluebird:peck us.icr.io/birds/pigeon:peck

Copy the image us.icr.io/birds/bluebird:peck to another namespace animals to which you have access.

ibmcloud cr image-tag us.icr.io/birds/bluebird:peck us.icr.io/animals/dog:bark







 ibmcloud cr image-untag 

Remove a [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag), or tags, from each specified image in IBM Cloud Container Registry.

To remove a specific tag from an image and leave the underlying image and any other tags in place, use the ibmcloud cr image-untag command.
If your Docker client is set up to require root permissions, you must run ibmcloud login, ibmcloud cr login, docker pull, and docker push commands with sudo.

If you change your permissions to run Docker commands without root privileges, you must run the ibmcloud login command again.



To copy an image between two registries, complete the following steps:



1. [Pull an image from a registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_pulling_reg).
2. [Push the image to another registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_pushing_namespace). Make sure that you use the correct [domain name](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_domain_name) for the new region you're targeting.



After you copy your image, you can do one of the following tasks.



* [Manage image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=ui) to find information about potential security issues and vulnerabilities.
* [Create a cluster and use this image to deploy a container](https://cloud.ibm.com/docs/containers?topic=containers-getting-startedgetting-started) to the cluster in IBM Cloud Kubernetes Service.







 Creating images that refer to a source image 

Create an image by using the [ibmcloud cr image-tag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_tag) command.

In the region that you are logged in to, create an image in IBM Cloud Container Registry that refers to an existing image in the same region. This action is supported for source images that are created by using supported versions of Docker Engine, see [Support for Docker](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewdocker).
To add private registries, edit the global pull-secret in the openshift-config project.



1. Create a secret value that holds the credentials to access your private registry and store the decoded secret value in a JSON file. When you create the secret value, the credentials are automatically encoded to base64. By using the --dry-run option, the secret value is created only and no secret object is created in your cluster. The decoded secret value is then stored in a JSON file to later use in your global pull secret.

oc create secret docker-registry <secret_name> --docker-server=<registry_URL> --docker-username=<docker_username> --docker-password=<docker_password> --docker-email=<docker_email> --dry-run=true --output="jsonpath={.data..dockerconfigjson}" | base64 --decode > myregistryconfigjson

--namespace <project>
: Required. The Red Hat OpenShift project of your cluster where you want to use the secret and deploy containers to. To list available projects in your cluster, run oc get ns.

<secret_name>
: Required. The name that you want to use for your image pull secret.

--docker-server <registry_URL>
: Required. The URL to the registry where your private images are stored.

--docker-username <docker_username>
: Required. The username to log in to your private registry.

--docker-password <token_value>
: Required. The password to log in to your private registry, such as a token value.

--docker-email <docker-email>
: 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.
Click the Navigation menu icon, then click Container Registry.
3. Click Settings.
4. In the Security policy exemptions section, click Create.
5. Select the issue type.
6. Enter the issue ID.

You can find this information in your [vulnerability report](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_reviewing). The Vulnerability ID column contains the ID to use for CVE or security notice issues; the Configuration Issue ID column contains the ID to use for configuration issues.
7. Select the registry namespace, repository, image, and tag that you want the exemption to apply to.
8. Click Create.



You can also edit and remove exemptions by hovering over the relevant row and clicking the open and close list of options icon.





 Setting exemption policies by using the CLI 

If you are using the CLI, you can set a [namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_namespace), [repository](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_repository), [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest), or [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag) as the scope of the exemption policy.

If you want to set exemptions from the policy by using the CLI, you can run the following commands:



* To create an exemption for a security issue, run the [ibmcloud cr exemption-add](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_exemption_add) command.
* To list your exemptions for security issues, run the [ibmcloud cr exemption-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_exemption_list) command.
docker login -u <DOCKER_HUB_ID> -p <DOCKER_HUB_PWD>
docker tag hsm-client:v1 <DOCKER_HUB_ID>/hsm-client:v1
docker push <DOCKER_HUB_ID>/hsm-client:v1



* Replace <DOCKER_HUB_ID> with your Docker Hub id.
* Replace <DOCKER_HUB_PWD> with your Docker Hub password.



Create a Kubernetes image pull secret

If the HSM client image that you published is not public, then the operator requires an image pull secret that contains a valid username and password (or access token) for the container registry. If the image is public, the imagepullsecret is not required and you can skip this command. To build the image pull secret named hsm-docker-secret, run the following command in the namespace or project where you deployed the service:

kubectl create secret docker-registry hsm-docker-secret --docker-server=<DOCKER_REGISTRY_SERVER> --docker-username=<DOCKER_USER> --docker-password=<DOCKER_PASSWORD> --docker-email=<DOCKER_EMAIL> -n <NAMESPACE>

Replace:



* DOCKER_REGISTRY_SERVER - Registry server url where the HSM client image is hosted.
* DOCKER_USER - Valid username with access to HSM client image in the container registry.
* DOCKER_PASSWORD - Valid password or access token for the HSM client image in the container registry.
* DOCKER_EMAIL - Email address for container registry user.
* NAMESPACE - Name of the project or namespace that is visible on the console Support page.



These instructions are obviously for the Docker registry. If you are using the IBM Container Registry, then you need to set up your own image pull secret in your cluster:

- [Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Kubernetes namespaces](/docs/containers?topic=containers-registryother)
Bound To crn:v1:bluemix:public:iam-identity::a/1bb222bb2b33333ddd3d3333ee4ee444::serviceid:ServiceId-ff55555f-5fff-6666-g6g6-777777h7h7hh
Created At 2019-02-01T19:06+0000
API Key i-8i88ii8jjjj9jjj99kkkkkkkkk_k9-llllll11mmm1
Locked false
UUID ApiKey-222nn2n2-o3o3-3o3o-4p44-oo444o44o4o4
6. Create an image pull secret to store the API key credentials in the cluster namespace. Repeat this step for each namespace of each cluster for each icr.io domain that you want to pull images from.

kubectl --namespace <namespace> create secret docker-registry <secret_name> --docker-server=<registry_URL> --docker-username=iamapikey --docker-password=<api_key_value> --docker-email=<docker_email>

--namespace <namespace>
: Required. Specify the Kubernetes namespace of your cluster that you used for the service ID name.

<secret_name>
: Required. Enter a name for your image pull secret.

--docker-server <registry_URL>
: Required. Set the URL to the image registry where your registry namespace is set up. For available domains, see [Local regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions).

--docker-username iamapikey
: Required. Enter the username to log in to your private registry. If you use IBM Cloud Container Registry, enter iamapikey.

--docker-password <token_value>
: Required.
In this automatic access scenario, Code Engine builds an image from your local source, and automatically uploads the image to IBM Cloud Container Registry with automatic access by using build options with the buildrun submit command.

See [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry) for more information about setting required permissions for Code Engine to automatically access these images in Container Registry. In this case, you do not need to specify a registry secret or the location of the image registry.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



Before you work with local source, make sure that your source is in an accessible location on your local workstation.

This example uses the https://github.com/IBM/CodeEngine samples; in particular, the helloworld sample.



1. Download the https://github.com/IBM/CodeEngine sample source to your local workstation with the following command.

git clone https://github.com/IBM/CodeEngine
2. Change to the CodeEnginehelloworld directory.
3. From the CodeEnginehelloworld directory, run a build to build an image from the helloworld source on your local workstation and let Code Engine automatically store and access the image. This command automatically builds and pushes the image to a Container Registry namespace in your account. If you do not have an existing Container Registry namespace, Code Engine automatically creates one for you. For example, the following buildrun submit command runs a build run that is called buildrun-local-dockerfile that builds from the local source.

ibmcloud ce buildrun submit --name buildrun-local-dockerfile --source .

The .
Go to System Tools > Local Users and Groups > Groups > Distributed COM Users > Add to Group.
2. Click Add and enter the group name for the Hyper-V group and click OK.







 Granting remote access to the server for CIMV2 and Virtualization namespaces 

You can update the permissions for Remote access to the server for Virtualization and CIMV2.



1. From the Computer Management window, select Service and Applications > WMI Control.
2. Right-click and go to Properties > Security > Root > CIMV2 > Security.
3. Add the Hyper-V group, then select it and click Advanced.
4. Make sure that the new group is selected and click Edit.
5. Change Apply to: to The namespace and all subnamespaces.
6. For Enable Account and Remote enable, select Allow.
7. Select for Apply these permissions to objects and or containers within this container only and click OK.
8. Repeat these steps for Virtualization.







 Updating the authorization store 

The authorization store for Hyper-V is the final component that gives domain group to Hyper-V.



1. Open the Authorization Manager by running the command azman.msc from the run menu or command prompt.
2. From the Action menu, select Open Authorization Store.
3. Make sure that XML is selected. Now, you need to remotely access InitalStore.xml on the Hyper-V server. Use the following path.

HOSTNAMEc$ProgramDataMicrosoftWindowsHyper-VInitialStore.xml
4. Go to Hyper-V services > Role Assignments > Administrator.
5. Fom the Action Menu, select Assign Users and Groups > From Windows and Active Directory.
6. Add the Hyper-V group.







 Granting folder permissions 

Now that the Hyper-V group has complete permissions to manage Hyper-V remotely, you need to give permissions to write to the C:UsersPublicDocumentsHyper-V folder.



1. Open My Computer and go to the following address:
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? 

You can create an IBM Cloud account and invite all the users to it. They can then all have access to any

namespacethat 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? 

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? 

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. If you delete untagged images that are in use, you can cause problems with scaling or automated restarts. Deleting untagged images might cause a problem in the following circumstances:



* The image was deployed by referencing the image by using the digest.
Assign the users Viewer access to the resource group so that they can work with clusters in resource groups other than default. Note that users must have access to the resource group to create clusters.



1. Click the IAM services tile.
2. In the services drop-down list, select No service access.
3. In the next drop-down list, scope the policy to All resource groups or to particular resource groups.
4. Select Viewer.
5. Click Add.



5. In the side panel, review the Access summary of your changes, and click Assign. If you assigned a service access role, the role might take a couple minutes to sync with your cluster's RBAC.







 Assign IBM Cloud IAM roles with the CLI 

Grant users access to your IBM Cloud Kubernetes Service clusters by assigning IBM Cloud IAM platform access and service access roles with the CLI.

Before you begin, complete the following steps.



* Verify that you're assigned the cluster-admin IBM Cloud IAM platform access role for the IBM Cloud account in which you're working.
* Verify that the user is added to the account. If the user is not, invite the user to your account by running ibmcloud account user-invite <user@email.com>.
* [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
* Decide whether to assign [platform or service access](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewaccess_policies) roles. The CLI steps vary depending on which access role you want to assign:



* [Assign platform access roles from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_platform)
* [Assign service access roles from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_service)
User access To create classic infrastructure clusters, you must set up [infrastructure credentials](https://cloud.ibm.com/docs/containers?topic=containers-access-creds) for each region and resource group. To let users manage the cluster, use [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles). To grant users access to cluster resources, use [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles), which correspond with Kubernetes RBAC roles. 
 Integrations You can extend your cluster and app capabilities with a variety of IBM Cloud services, add-ons, and third-party integrations. For a list, see [Supported IBM Cloud and third-party integrations](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrations). 
 Locations and versions Classic clusters are available in multizone and single zone locations [worldwide](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneslocations). 
 Service interface Classic clusters are fully supported in the Kubernetes Service [v1 API](https://containers.cloud.ibm.com/global/swagger-global-api//), [CLI](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli), and [console](https://cloud.ibm.com/kubernetes/clusters). 
 Service compliance See the classic section in [What standards does the service comply to?](https://cloud.ibm.com/docs/containers?topic=containers-faqsstandards). 
 Service limitations See [Service limitations](https://cloud.ibm.com/docs/containers?topic=containers-limitationstech_limits). Feature-specific limitations are documented by section. 







 Troubleshooting and support 

Classic, VPC, and Satellite clusters are supported through the same IBM Cloud Support processes.