vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: Set up your own repo in our secured Docker private image registry where images are stored and shared by all users in the organization.
: Benefit from automatic scanning of images in your private IBM Cloud registry.
: Review recommendations specific to the operating system used in the image to fix potential vulnerabilities.

Continuous monitoring of the cluster health
: Use the cluster dashboard to quickly see and manage the health of your cluster, worker nodes, and container deployments.
: Find detailed consumption metrics by using IBM Cloud® Monitoring and quickly expand your cluster to meet work loads.
: Review logging information by using IBM® Log Analysis to see detailed cluster activities.

Secure exposure of apps to the public
: Choose between a public IP address, an IBM provided route, or your own custom domain to access services in your cluster from the internet.

IBM Cloud service integration
: Add extra capabilities to your app through the integration of IBM Cloud services, such as Watson APIs, Blockchain, data services, or Internet of Things.





 Comparison of offerings and their combinations 

You can run IBM Cloud Kubernetes Service in IBM Cloud Public, in IBM Cloud Private, or in a hybrid setup.

IBM Cloud Public, off-premises
: With IBM Cloud Public on [shared or dedicated](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes) hardware or on bare metal machines, you can host your apps in clusters on the cloud by using IBM Cloud Kubernetes Service. You can also create a cluster with worker pools in multiple zones to increase high availability for your apps. IBM Cloud Kubernetes Service on IBM Cloud Public delivers powerful tools by combining Docker containers, the Kubernetes technology, an intuitive user experience, and built-in security and isolation to automate the deployment, operation, scaling, and monitoring of containerized apps in a cluster of compute hosts For more information, see [IBM Cloud Kubernetes Service technology](https://cloud.ibm.com/docs/containers?topic=containers-service-arch).
: You can also create your cluster in a Virtual Private Cloud (VPC), which gives you the security of a private cloud environment with isolated networking features along with the dynamic scalability of the public cloud.
Auditing events for Container Registry 

Use IBM Cloud® Activity Tracker to track how users and applications interact with the IBM Cloud® Container Registry service in IBM Cloud.

The IBM Cloud Activity Tracker service records user-initiated activities that change the state of a service in the IBM Cloud. For more information, see [IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started).



 Locations of service events 

You can track how users and applications interact with the IBM Cloud Container Registry service. The following tables list the locations where the automatic collection of Container Registry service events is enabled.



Table 1. The automatic collection of Container Registry service events in Americas locations

 Locations in Americas Service events available 

 Dallas (us-south) Yes 
 Sao Paulo (br-sao) Yes 
 Toronto (ca-tor) Yes 





Table 2. The automatic collection of Container Registry service events in Asia Pacific locations

 Locations in Asia Pacific Service events available 

 Osaka (jp-osa) Yes 
 Sydney (au-syd) Yes 
 Tokyo (jp-tok) Yes 





Table 3. The automatic collection of Container Registry service events in Europe locations

 Locations in Europe Service events available 

 Frankfurt (eu-de) Yes 
 London (eu-gb) Yes 





Table 4. The automatic collection of Container Registry service events for Global

 Location for Global Service events available 

 Global Yes 



For more information about where to see Container Registry events, see [Where to look for events](https://cloud.ibm.com/docs/Registry?topic=Registry-at_eventsui).

For more information about the locations where IBM Cloud services are enabled to automatically collect events, see [IBM Cloud services that generate Activity Tracker events by location](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-cloud_services_locations).





 Where to look for events 



 IBM Cloud Activity Tracker events
: With effect from 19 November 2020, Container Image Security Enforcement is deprecated. To enforce container image security, you can use [Portieris](https://github.com/IBM/portieris). You can use Portieris to control where images are deployed from, enforce Vulnerability Advisor policies, and ensure that [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontent) is properly applied to the image.

For more information, see [Enforcing container image security by using Portieris](https://cloud.ibm.com/docs/Registry?topic=Registry-security_enforce_portieris).





 21 October 2020 

Find out about the usage on your account by using platform metrics
: You can use the [ibmcloud cr platform-metrics](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_platform_metrics) command to enable and disable platform metrics, and to find out whether you have platform metrics set up on your account.

For more information, see [Monitoring metrics for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_monitor).





 6 October 2020 

Container Registry container builds are deprecated
: The ibmcloud cr build command, which builds an image in IBM Cloud and pushes it to Container Registry, is deprecated from 6 October 2020. You can use [Tekton pipelines](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-pipeline_container_imagespipeline_tekton_images) instead.

For more information, see [IBM Cloud Container Registry is Deprecating Container Builds](https://www.ibm.com/cloud/blog/announcements/ibm-cloud-container-registry-deprecating-container-builds).





 27 August 2020 

Setting exemption policies by digest
: When you want to set up an exemption policy, you can set the scope by namespace, repository, digest, or tag.
Why can't I access the registry through a custom firewall? 

Accessing IBM Cloud® Container Registry fails when you have a custom firewall.

  What’s happening 

You set up an extra firewall in your development environment with custom settings for inbound and outbound network traffic. When you try to access IBM Cloud Container Registry, the connection fails.

  Why it’s happening 

Your custom firewall requires certain network groups to be open for inbound and outbound network traffic to allow communication to and from the registry.

  How to fix it 

Allow your cluster to access infrastructure resources and services from behind a firewall, see [Allowing the cluster to access infrastructure resources and other services](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_outbound).

For INBOUND connectivity to your computer, allow incoming network traffic from the source network groups to the destination public IP address of your computer.

For OUTBOUND connectivity from your computer, use the same network groups and allow outgoing network traffic from the source public IP address of your computer to the network groups.
If you do not do this step, you must run ibmcloud login, ibmcloud cr login, docker pull, and docker push commands with sudo or as root.



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

You can now [set up your own namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_setup) in IBM Cloud Container Registry.





 Updating the container-registry CLI plug-in 

You might want to update the container-registry CLI plug-in periodically to use new features.



 Updating container-registry CLI plug-in version 1.0 

To update version 1.0 of the Container Registry CLI, run the following command:

ibmcloud plugin update container-registry





 Updating container-registry CLI plug-in version 0.1 

To update version 0.1 of the Container Registry CLI, run the following command, where <version_number> is the number of the version of the CLI.

Version 0.1 of the Container Registry CLI is deprecated, see [All releases of Container Registry plug-in 0.1 are deprecated](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes15sep2022_v0).

ibmcloud plugin install container-registry -v <version_number>

For example, to update the CLI to version 0.1.584, run the following command:

ibmcloud plugin install container-registry -v 0.1.584







 Uninstalling the container-registry CLI plug-in 

If you no longer need the container-registry CLI plug-in, you can uninstall it.

To uninstall the container-registry CLI plug-in, run the following command:

ibmcloud plugin uninstall container-registry
* [Updating existing clusters to use the API key image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryimagePullSecret_migrate_api_key)



* [Updating your image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryupdate-pull-secret)



* [Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Kubernetes namespaces](https://cloud.ibm.com/docs/containers?topic=containers-registryother)



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



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



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



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



* [Example daemonset to update a containerd custom registry configuration](https://cloud.ibm.com/docs/containers?topic=containers-registryds-example-registry)
As of 17 August 2021, the Registry subnets are no longer published. When you access IBM Cloud Container Registry over the public internet, you must not have any allowlist restrictions that are based on IP addresses in place. If you have any concerns about opening your allowlist, you can configure private access to IBM Cloud Container Registry by using the private IBM Cloud network, see [Securing your connection to Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_private).

In addition to the following regional subdomains, you must also allow traffic from your worker nodes to port 443 on all subdomains of icr.io in case of redirection to other subdomains for delivery optimization. You must allow: TCP port 443 FROM <each_worker_node_publicIP> TO .icr.io. If you use the deprecated domain names, you must allow those too.



Table 2. Addresses for Container Registry traffic

 Red Hat OpenShift on IBM Cloud region Registry address 

 Global registry across Red Hat OpenShift on IBM Cloud regions icr.io Deprecated: registry.bluemix.net 
 AP North jp.icr.io 
 AP South au.icr.io Deprecated: registry.au-syd.bluemix.net 
 EU Central de.icr.io Deprecated: registry.eu-de.bluemix.net 
 Osaka jp2.icr.io 
 Sao Paolo br.icr.io 
 Toronto ca.icr.io 
 UK South uk.icr.io Deprecated: registry.eu-gb.bluemix.net 
 US South us.icr.io Deprecated: registry.ng.bluemix.net 







 Allow outgoing network traffic from worker node to IAM 

Allow outgoing network traffic from your worker node to IBM Cloud Identity and Access Management (IAM). Your allowlist must be Layer 7 to allow the IAM domain name. IAM does not have specific IP addresses that you can allow. If your allowlist does not support Layer 7, you can allow all HTTPS network traffic on port 443.
For more information, see [Accessing IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_access). For more information about Registry token deprecation, see [IBM Cloud Container Registry Deprecates Registry Tokens for Authentication](https://www.ibm.com/cloud/blog/announcements/ibm-cloud-container-registry-deprecates-registry-tokens-for-authentication).

Ingress change logs
: Updated the [Ingress ALB change log](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog) for versions 0.48.1_1541_iks, 0.47.0_1540_iks, and 0.43.0_1539_iks. Version 0.45.0_1482_iks is removed.

HPCS Router
: Updated version change log for the [HPCS Router](https://cloud.ibm.com/docs/openshift?topic=openshift-hpcs-router-changelog) add-on.

Image key synchronizer
: Updated the version change log for the [Image Key Synchronizer](https://cloud.ibm.com/docs/openshift?topic=openshift-image-key-synchronizer-changelog) add-on.





 16 August 2021 

Worker node versions
: Worker node fix pack update change log documentation is available. For more information, see [Version change log](https://cloud.ibm.com/docs/containers?topic=containers-changelog).





 10 August 2021 

Ingress change logs
: Updated the [Ingress ALB change log](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog) for versions 0.48.1_1465_iks, 0.47.0_1480_iks, and 0.45.0_1482_iks.

HPCS Router
Any connections to IBM Cloud Container Registry that originate from within the VPC automatically go through the Container Registry VPE gateway, if one exists. For more information, see [Getting started with Virtual Private Cloud](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).

When you connect to Container Registry from the IBM Cloud console, you must go through a browser in your VPC to ensure that the connection goes through the Container Registry VPE gateway.

For VPE gateways created before 11 November 2022, you must ensure that the canonical domain name for the registry [region](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions) (for example, us.icr.io in us-south) resolves to the IP address of the VPE gateway. This action ensures that the image name, which starts with the hostname, is consistent. You can ensure consistency by creating container hostmap entries or configuring the kube Domain Name System (DNS).

For VPE gateways created after 11 November 2022, this additional configuration is not required because the domain name resolution is now handled automatically by the VPE gateway.

For more information about other IBM Cloud VPE services, see [VPE supported services](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-supported-services).



 Before you begin 

Before you target a VPE for Container Registry, you must complete the following tasks.



* Ensure that a Virtual Private Cloud is created, see [Getting started with Virtual Private Cloud](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).
* Make a plan for your virtual private endpoints, see [Planning for virtual private endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-considerations).
The global registry stores IBM-provided public images, and regional registries store your own private or public images. If your allowlist is IP-based, you can see which IP addresses are opened when you allow access to the IBM Cloud Container Registry regional service endpoints by reviewing [this table](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_registry).
6. Verify your connection. The following is an example for the US East and US South regional registry. If access is configured correctly, a message of the day is returned in the output. Note that if there are no messages, a 204 is returned.

curl -i https://us.icr.io/api/v1/messages







 Running kubectl commands from behind an allowlist 

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run kubectl commands, you must allow TCP access for the cluster.

When a cluster is created, the port in the service endpoint URLs is randomly assigned from within 30000-32767. You can either choose to open port range 30000-32767 for any cluster that might get created or you can choose to allow access for a specific existing cluster.

Before you begin, allow access to [run ibmcloud ks commands](https://cloud.ibm.com/docs/containers?topic=containers-vpc-firewallvpc-firewall_bx).

To allow access for a specific cluster:



1. Log in to the IBM Cloud CLI. Enter your IBM Cloud credentials when prompted. If you have a federated account, include the --sso option.

ibmcloud login [--sso]
2. If the cluster is in a resource group other than default, target that resource group. To see the resource group that each cluster belongs to, run ibmcloud ks cluster ls. Note: You must have at least the [Viewer role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the resource group.
For more information, see [Release notes for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-01nov2021). Any existing ICR images that were signed by using DCT, must be re-signed by using Red Hat.
* [Docker Hub](https://hub.docker.com/) where the images are and signed by using [Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/).
* Pull images from the [SUSE registry](https://registry.suse.com/), where you must first sign the image and push it to either Docker Hub, or ICR.





* You must install the IBM Cloud CLI. Follow these [instructions](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) to install and configure the IBM Cloud CLI.
* You must install the [CLI and the hpvs plug-in](https://cloud.ibm.com/docs/hpvs-cli-plugin).
* You must install [Skopeo](https://github.com/containers/skopeo/blob/main/install.md).







 Creating a custom image 



1. Choose a base for your OCI Image. Either use one of the [publicly available images from Docker Hub](https://hub.docker.com/search?q=&type=image&image_filter=&architecture=s390x) or build one from scratch.
2. Use a build tool such as docker build to make your required modifications to the base. You can use Ubuntu to install these tools on a Hyper Protect Virtual Server if you don't have access to a system that runs on the IBM Z platform (s390x architecture), or you can't cross build your image. To install Docker on your Hyper Protect Virtual Server, run apt update && apt install -y docker.io.
* UI
* CLI
* API
* Terraform







 Managing IAM access for Container Registry 

Access to IBM Cloud® Container Registry for users in your account is controlled by IBM Cloud® Identity and Access Management (IAM).

Every user that accesses the IBM Cloud Container Registry service in your account must be assigned an IAM

access policywith an IAM role. A user can also be a member of an [access group](https://cloud.ibm.com/docs/account?topic=account-groups) with assigned IAM access policies that grant an IAM role. Review the following roles, actions, and more to help determine the best way to assign access to Container Registry.

For more information about IAM, see [How IBM Cloud Identity and Access Management works](https://cloud.ibm.com/docs/account?topic=account-iamoverviewiamoverview).

Try out the tutorial [Granting access to Container Registry resources tutorial](https://cloud.ibm.com/docs/Registry?topic=Registry-iam_accessiam_access).



 Access policies 

The IAM access policy that you assign to users in your account determines the actions that a user can perform within the context of the service or specific instance that you select. The allowable actions are customized and defined by Container Registry as operations that are allowed to be performed on the service. Each action is mapped to an [IAM platform or service role](https://cloud.ibm.com/docs/account?topic=account-userroles) that you can assign to a user.

Policies enable access to be granted at different levels. Some options include the following access levels:



* Access to the service in your account
* Access to a specific resource within the service
* Access to all IAM-enabled services in your account
* Access to resources within a resource group



If you want to restrict user access to one or more

namespacesfor an ID that you are using for automation, use an IAM service ID.
* [Change to Container Registry private IP addresses in the following regions only: br-sao, ca-tor](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes23jun2022_private_network)



* [20 April 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-20apr2022)



* [Container Registry private IP addresses are changing from 23 June 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes20apr2022_private_network)



* [1 March 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-01mar2022)



* [Amendment to the minimum supported Docker version for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes01mar2022_docker)



* [9 February 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-09feb2022)



* [All accounts will require IAM access policies from 5 July 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes09feb2022_iam)



* [2 February 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-02feb2022)



* [Replication of exemption policies between IBM regions is discontinued](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes02feb2022_exemption)



* [1 February 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-01feb2022)
For example, IBM Cloud Container Registry and Docker Hub are container registries. A container registry can be public or private. A container registry that is public does not require credentials to access. In contrast, accessing a private registry does require credentials.

You must be within the context of a [project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-project) before you use registry commands.

For more information about accessing registries, see [Adding access to a private container registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).

To see CLI help for the registry commands, run ibmcloud ce registry -h.

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



 ibmcloud ce registry create 

Create an image registry access secret.

ibmcloud ce registry create --name NAME (--password PASSWORD | --password-from-file PASSWORD_FILE | --password-from-json-file) [--email EMAIL] [--output OUTPUT] [--quiet] [--server SERVER] [--username USERNAME]



 Command Options