vania-janet/multiturn-rag-retrieval-data huggingface dataset:
IAM access policies are required from 5 July 2022 

From 5 July 2022, to access IBM Cloud® Container Registry you must be using Cloud Identity and Access Management (IAM) access policies.

If you started to use Container Registry before the availability of [IAM API key policies in Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-25feb2019) in February 2019, you must ensure that you are using IAM access policies to manage access to the IBM Cloud Container Registry service.

Policy-free authorization is being discontinued in the following Container Registry regions:



* us-south (us.icr.io)
* uk-south (uk.icr.io)
* eu-central (de.icr.io)
* ap-south (au.icr.io)
* ap-north (jp.icr.io)



Other regions are unaffected because they already require IAM access policies for all accounts.



 What are the changes? 

Before 7 June 2019, all account users had full access to the images and settings that are associated with the account. Accounts that use Container Registry for the first time since 7 June 2019 are required to have IAM access policies and other accounts optionally require them. From 5 July 2022, all accounts require IAM access policies.

By default, account owners already have appropriate policies that give them full access to Container Registry. If policy-free authorization is in use, any other account user IDs and service IDs must be granted appropriate policies so that they can continue to access images and settings.





 Check whether these changes affect you 

To check whether policy-free authorization is in effect, run the [ibmcloud cr iam-policies-status](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_iam_policies_status) command. If the CLI reports that IAM policy enforcement is disabled, you must [prepare for the changes](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policynotices_iam_policy_prepare).
* [Example](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_platform_metrics_example)



* [ibmcloud cr private-only](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_private_only)



* [Prerequisites](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_private_only_prereq)
* [Command options](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_private_only_option)
* [Example](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_private_only_example)



* [ibmcloud cr quota](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_quota)



* [Prerequisites](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_quota_prereq)



* [ibmcloud cr quota-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_quota_set)



* [Prerequisites](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_quota_set_prereq)
* [Command options](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_quota_set_option)
* [Example](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_quota_set_example)



* [ibmcloud cr region](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_region)
* [Cleaning up your account](https://cloud.ibm.com/docs/Registry?topic=Registry-iam_accessclean_up)







 Solution tutorials 

[Moving a VM based app to Kubernetes](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes)



* [Objectives](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes-objectives)
* [Architecture](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes-architecture)



* [Traditional app architecture with VMs](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes-2)
* [Containerized architecture](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes-3)
* [VMs, containers, and Kubernetes](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes-4)



* [Virtual machines vs containers](https://cloud.ibm.com/docs/Registry?topic=Registry-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes-5)
: For the IBM Hyper Protect Container Runtime image version ibm-hyper-protect-container-runtime-1-0-s390x-9, new certificates are available.



* [Attestation certificate](https://cloud.ibm.com/media/docs/downloads/hyper-protect-container-runtime/ibm-hyper-protect-container-runtime-1-0-s390x-9-attestation.crt)
* [Encryption certificate](https://cloud.ibm.com/media/docs/downloads/hyper-protect-container-runtime/ibm-hyper-protect-container-runtime-1-0-s390x-9-encrypt.crt)
* [Intermediate certificate](https://cloud.ibm.com/media/docs/downloads/hyper-protect-container-runtime/ibm-hyper-protect-container-runtime-1-0-s390x-9-intermediate.crt)



Two partitions in new data volume



* For new Hyper Protect Virtual Servers instances, the data volume is partitioned into two parts. The first partition (100Mib) is reserved for internal metadata; the second partition remains as the data volume for workload. Only new volumes are partitioned, and you can't use the partitioned volume with an older version of the HPCR image. Provisioning with an existing encrypted volume also works. The difference is that the existing volume does not get partitioned, and you can also go back to an older image with this volume.



Support for using a dynamic registry reference



* There exist use cases in which the registry is not known when the workload section is pre-encrypted, for example, when the workload provider wants to allow the deployer to use a registry mirror or a private container registry. In such a case, it's possible to dynamically override the registry and the pull credentials - which is coordinated between the workload provider and the deployer. For more information, see [Using a dynamic registry reference](https://cloud.ibm.com/docs/vpc?topic=vpc-hyper-protect-virtual-server-use-dynamic-registry-reference).
Why am I getting Authorization required errors? 

You are trying to access IBM Cloud® Container Registry but are getting Authorization required errors.

 What’s happening 

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



* Authorization required.
* You were not authorized to complete this operation.
* An error occurred when authenticating your request.
* Status code 401 Unauthorized You might see this message if you are using IBM Cloud Code Engine. For more information, see [Why am I getting an Uunauthorized error when I'm using Code Engine?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-unauthorized-ce)



 Why it’s happening 

The following alternatives are possible causes:



* You attempted to log in to Container Registry with an invalid API key.
* You attempted to access Container Registry without logging in.
* A client attempted to access Container Registry without a bearer token.
* A client attempted to access Container Registry with an expired OAuth token.
* You attempted to authenticate against the Container Registry API with an invalid API key.
* You attempted to authenticate against the Container Registry API with an invalid Account ID.
* You logged in to a different region of Container Registry.



 How to fix it 

You can fix this problem in the following ways:



* Check the information about logging a client into Container Registry, see [Push images to your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started&interface=uigs_registry_images_pushing) in [Getting started with Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started&interface=ui).
* Create and use a valid IAM API key to log a client, such as Docker, in to Container Registry with username iamapikey and the API key as your password. For more information, see [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey&interface=uiuserapikey).
* [IBM Cloud Container Registry CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-containerregcli) (ibmcloud cr)
* [IBM Cloud DevOps Insights CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-CLI_devops-insights) (ibmcloud doi)
* [IBM Direct Link CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-dl-cli) (ibmcloud dl)
* [IBM Cloud Event Notifications CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-event-notifications-cli) (ibmcloud event-notifications)
* [IBM Cloud DNS Services CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-dns-services-cli-commands) (ibmcloud dns)
* [IBM Cloud Functions CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-functions-cli) (ibmcloud fn)
* [IBM Cloud Hyper Protect DBaaS CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-dbaas_cli_plugin) (ibmcloud dbaas)
* [IBM Hyper Protect Crypto Services CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-hpcs-cli-plugin) (ibmcloud tke)
* [IBM Hyper Protect Crypto Services Certificate manager CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-hpcs-cli-plugincert-manager-cli-plugin) (ibmcloud hpcs-cert-mgr)
container-registry.image.pull docker pull Pull a container image.<br><br>docker trust inspect Inspect the signature for a container image.<br><br>[ibmcloud cr image-tag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_tag) Create a container image that refers to a source image.<br><br>[ibmcloud cr vulnerability-assessment](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_va) View a vulnerability assessment report for your container image. Reader, Writer, Manager 
 container-registry.image.push docker push Push a container image.<br><br>docker trust sign Sign a container image.<br><br>[ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) Restore a deleted container image from the trash.<br><br>[ibmcloud cr image-tag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_tag) Create a container image that refers to a source image. Writer, Manager 
 container-registry.namespace.list [ibmcloud cr namespace-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_namespace_list) List your namespaces. Reader, Manager 
 container-registry.retention.analyze [ibmcloud cr retention-policy-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_policy_set) Set a policy to clean up your namespaces by retaining only container images that meet your criteria.<br><br>[ibmcloud cr retention-run](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_run) Clean up your namespaces by retaining only container images that meet your criteria.
* Infrastructure, such as classic or VPC compute, networking, and storage resources for your cluster.
* Key Protect or Hyper Protect Crypto Services, if you [enable a key management service provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms) in your cluster.
* Secrets Manager, for managing the Ingress certificates for your cluster.
* Container Registry, for setting up default access to pull images from the registry to your cluster.
* Log Analysis, if you [enable the logging service](https://cloud.ibm.com/docs/containers?topic=containers-health).
* Monitoring, if you [enable the monitoring service](https://cloud.ibm.com/docs/containers?topic=containers-health).
* Activity Tracker, for sending audit events from your cluster.







 How many API keys do I need? 

You have a different API key for each region and resource group where you use IBM Cloud Kubernetes Service. To check if an API key is already set up for the region and resource group, run the following command.

ibmcloud ks api-key info --cluster <cluster_name_or_ID>





 How do I set up the API key? 

To enable all users to access the infrastructure portfolio or other services, the user whose credentials are stored in the [API key must have the correct permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsowner_permissions). Then, log in as the user or functional ID and perform the first admin action in a region and resource group or [reset the API key](https://cloud.ibm.com/docs/containers?topic=containers-access-credsapi_key_most_cases). For example, one of your admin users creates the first cluster in the default resource group in the us-south region. As a result, the IBM Cloud IAM API key for this admin user is created in the account for this resource group and region.





 What permissions does the user who sets the API key need? How do I give the user these permissions?
* registry.tf creates the Container Registry that will hold your container images.
* iam.tf creates the access key that is needed to interact with the Container Registry.
* vpc.tf creates the VPC (Virtual Private Cloud) infrastructure that will be needed to deploy an OpenShift cluster. This includes a VPC, subnets and public gateways in three different availability zones.
* cos.tf create a single Cloud Object Storage instance that is needed by OpenShift to manage the cluster.
* openshift.tf creates a cluster of virtual machines inside your VPC, where you will deploy your applications.



It will take several minutes for the databases and other resources to be ready, but you should now have some VPC resources, a cluster of virtual machines, an IBM Cloud® Databases for Redis instance, a Cloudant database and an Event Streams instance in your account, as well as a Container Registry namespace for your container images. You can check by visiting the [Resources section](https://cloud.ibm.com/resources) of your IBM Cloud account.





 Step 4: Create container images and deploy to OpenShift 

At this point, all your infrastructure is ready to receive data. Now we have to build and deploy the different modules that will produce and consume the data, as well as the application that will display the truck position on a map.

Run the build script — but before you do, are you logged into the IBM Cloud CLI and Docker?

Go into the root of the project and type the following:

./build.sh





 Step 5: Watch your trucks truckin' 

The end of the script will output a URL — something like https:// some.thing.eu-gb.appdomain.cloud.

If you visit the URL that has been generated, you should be able to see a map of the US and, after a few seconds, several markers on the map that represent your trucks:

Zoom

!
For more information, see [Starting 1 February 2022, IBM Cloud Container Registry will be billing for the storage that is used by untagged images](https://www.ibm.com/cloud/blog/announcements/ibm-cloud-container-registry-to-bill-for-storage-used-by-untagged-images).





 17 January 2022 

View IBM Cloud Activity Tracker events for Red Hat signing
: You can view Activity Tracker events for [Red Hat Signing](https://www.redhat.com/en/blog/container-image-signing) operations.

For more information, see [Auditing events for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-at_events).





 7 December 2021 

Define configuration rules for Container Registry
: As a security or compliance focal, you can use the Govern resources section of the Security and Compliance Center dashboard to define

configuration rulesfor Container Registry.

For more information, see [Managing security and compliance for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-manage-security-compliance&interface=ui).





 1 November 2021 

Using Notary v1 for signing images is discontinued
: The Notary v1 service that supports [Docker Content Trust](https://docs.docker.com/engine/security/trust/) and docker trust commands in Container Registry is discontinued from 1 November 2021.

Container Registry supports the [Red Hat Signing](https://www.redhat.com/en/blog/container-image-signing) model. For more information, see [Signing images for trusted content by using Red Hat signatures](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent_red_hat_sig).





 5 October 2021 

Container Registry container builds are discontinued
: The ibmcloud cr build command is discontinued from 5 October 2021.
container-registry.image.delete docker trust revoke Delete the signature for a container image.<br><br>[ibmcloud cr image-prune-untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_image_prune_untagged) Delete all untagged images in your Container Registry account.<br><br>[ibmcloud cr image-rm](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_rm) Delete one or more container images.<br><br>[ibmcloud cr image-untag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_untag) Remove a tag, or tags, from each specified container image in Container Registry.<br><br>[ibmcloud cr retention-policy-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_policy_set) Set a policy to clean up your namespaces by retaining only container images that meet your criteria.<br><br>[ibmcloud cr retention-run](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_run) Clean up your namespaces by retaining only container images that meet your criteria. Writer, Manager<br><br>To run ibmcloud cr retention-run and ibmcloud cr retention-policy-set you must have Manager, or both Reader and Writer. 
 container-registry.image.inspect [ibmcloud cr image-inspect](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_inspect) Display details about a specific container image.<br><br>[ibmcloud cr manifest-inspect](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_manifest_inspect) View the contents of the manifest for an image. Reader, Manager
* Option to set up the internal registry to [pull images](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry) from or [push images](https://cloud.ibm.com/docs/openshift?topic=openshift-registrybuilds_registry) to a private registry such as IBM Cloud Container Registry.



: For more information, see [Using the internal registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_internal_registry).

Private registry
: Private registries are a good choice to protect your images from unauthorized users. Private registries must be set up by the cluster administrator to make sure that access, storage quotas, image trust and other features work as intended. By default, your [Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_iccr) are integrated with the private IBM Cloud Container Registry through image pull secrets in the default project. IBM Cloud Container Registry is a highly available, multi-tenant private registry to store your own images. You can also pull IBM-provided images from the global icr.io registry, and licensed software from the entitled registry. With IBM Cloud Container Registry, you can manage images for multiple clusters with integration with IBM Cloud IAM and billing. Advantages of using IBM Cloud Container Registry with the internal registry:



* Local image caching for faster builds via the internal registry.
* Deployments in other projects can see the image stream so that you don't have to copy pull secrets to each project.
* Sharing images across multiple clusters without needing to push images to multiple registries.
* [Automatically scanning](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index) the vulnerability of images.
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. Enter the value of your API Key that you previously retrieved.

--docker-email <docker-email>
: Required. If you have one, enter your Docker email address. If you don't, 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.
7. Verify that the secret was created successfully. Replace <namespace> with the namespace where you created the image pull secret.

kubectl get secrets --namespace <namespace>
8. [Add the image pull secret to a Kubernetes service account so that any pod in the namespace can use the image pull secret when you deploy a container](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret).







 Accessing images that are stored in other private registries 

If you already have a private registry, you must store the registry credentials in a Kubernetes image pull secret and reference this secret from your configuration file.

Before you begin:



1. [Create a Kubernetes cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
2. [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)



To create an image pull secret:



1. Create the Kubernetes secret to store your private registry credentials.
{"kubernetes":[{"major":1,"minor":19,"patch":16,"default":false,"end_of_service":""},{"major":1,"minor":20,"patch":13,"default":false,"end_of_service":""},{"major":1,"minor":21,"patch":7,"default":true,"end_of_service":""},{"major":1,"minor":22,"patch":4,"default":false,"end_of_service":""}],"openshift":[{"major":3,"minor":11,"patch":542,"default":false,"end_of_service":"2022-06-06T12:00:00+0000"},{"major":4,"minor":6,"patch":47,"default":false,"end_of_service":""},{"major":4,"minor":7,"patch":37,"default":false,"end_of_service":""},{"major":4,"minor":8,"patch":21,"default":true,"end_of_service":""}]}
5. Allow access to the [IBM Cloud Container Registry regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions) that you plan to use on port 443 in your allowlist. 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.