vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run ibmcloud, ibmcloud ks and ibmcloud cr commands, you must allow TCP access for IBM Cloud, IBM Cloud Kubernetes Service, and IBM Cloud Container Registry.



1. Allow access to cloud.ibm.com on port 443 in your allowlist.
2. Verify your connection by logging in to IBM Cloud through this API endpoint.

ibmcloud login -a https://cloud.ibm.com/
3. Allow access to containers.cloud.ibm.com on port 443 in your allowlist.
4. Verify your connection. If access is configured correctly, zones are displayed in the output.

curl https://containers.cloud.ibm.com/v1/zones

Example output

[{"id":"mon01","metro":""},{"id":"tor01","metro":""},{"id":"wdc04","metro":"Washington D.C."},{"id":"wdc06","metro":"Washington D.C."},{"id":"wdc07","metro":"Washington D.C."}]
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.
6. Verify your connection by [listing your container registry namespaces](https://cloud.ibm.com/apidocs/container-registrylist-namespaces).







 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.
The minimum that a workload section needs is the compose section. The other sections can be added based on the requirement.

type: workload
auths:
<registry url>:
password: <password>
username: <user name>
<registry url>:
password: <password>
username: <user name>

compose:
archive: <base64 encoded of tgz of docker-compose.yaml>
images:
dct:
<docker image name (without the tag, an example is docker.io/redbookuser/s390x:)>:
notary: "<notary URL>"
publicKey: <docker content trust signed public key>
<docker image name>:
notary: "<notary URL>"
publicKey: <docker content trust signed public key>

volumes:
<volume name>:
mount: "<data volume mount path>"
seed: "<Passphrase of the luks encryption>"
filesystem: "ext4"
Show more



 The auths subsection 

The auths section consists of information about the container's registry. If a public image is used in the contract, you do not need the auths section because no credentials are required. The auths subsection is required only if the container images are private. This subsection does not have any image information, as shown in the following sample. This subsection needs to contain the name of the image registry and the credentials such as username-password for the same. The key must be the hostname of the container registry or the following string for the default docker registry:

https://index.docker.io/v1/

The following snippet shows an example for IBM Cloud Registry. For more information about using the API key, see [Using client software to authenticate in automation](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth).

auths:
us.icr.io:
Click the Access policies tab, and then click Assign access.
2. Click the Account management card.
3. Select Support Center.
4. To allow the user to view, add, and edit support cases, select Administrator.
5. Click Assign.





Downgrading permissions? The action can take a few minutes to complete.





 Assigning infrastructure access through the CLI 

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).

Before you begin:



* Make sure that you are the account owner or have Super User and all device access. You can't grant a user access that you don't have.
* Review the [required and suggested classic infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles).



To customize classic infrastructure permissions through the CLI:



1. Check whether the credentials for classic infrastructure access for IBM Cloud Kubernetes Service in the region and resource group have any missing required or suggested permissions.

ibmcloud ks infra-permissions get --region <region>

Example output if classic infrastructure access is based on an API key.

...with infrastructure access set up by linked account API key.

Example output if classic infrastructure access is based on manually set credentials.

...with infrastructure access set up by manually set IaaS credentials.
2. Get the user whose classic infrastructure credentials are used.



* API key: Check the API key that is used for the region and resource group of the cluster. Note the Name and Email of the API key owner in the output of the following command.

ibmcloud ks api-key info --cluster <cluster_name_or_ID>
* Manually-set credentials: Get the username in the output of the following command.

ibmcloud ks credential get --region <region>



Need to change the infrastructure credential owner?
Giving containers access to the private network through PIM 

You can give containers access to your private network. But, you need to understand the implications in providing access to your internal infrastructure to your customers, which can lead to security issues.



1.  Go to the container that you want to grant private network access.
2.  Click the Network tab and click Configure.
3.  You can now set up the Bridged Network Section:



*  Bridged Network: Select the check box.
*  Connect to: Is not required to provide access to the IBM Cloud® private network.
*  Get IP address by DHCP: Clear this check box.
*  IP address / Subnet Mask: Choose an INTERNAL IP address from your pool of private addresses.
*  Click Submit





You now need to refresh the page from the link on the upper right and you are done.
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_index&interface=uiva_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.
Why can't the cluster pull images from IBM Cloud Container Registry during creation? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

When you created a cluster, you received an error message similar to the following.

Your cluster can't pull images from the 'icr.io' domains because an IAM access policy could not be created. Make sure that you have the IAM Administrator platform access role to. Then, create an image pull secret with IAM credentials to the registry by running 'ibmcloud ks cluster pull-secret apply'.

  Why it’s happening 

During cluster creation, a service ID is created for your cluster and assigned the Reader service access policy to IBM Cloud Container Registry.

Then, an API key for this service ID is generated and stored in [an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth) to authorize the cluster to pull images from IBM Cloud Container Registry.

  How to fix it 

To successfully assign the Reader service access policy to the service ID during cluster creation, you must have the Administrator platform access policy to IBM Cloud Container Registry.

Steps:



1.  Make sure that the account owner gives you the Administrator role to IBM Cloud Container Registry.

ibmcloud iam user-policy-create <your_user_email> --service-name container-registry --roles Administrator
2.  [Use the ibmcloud oc cluster pull-secret apply command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_pull_secret_apply) to re-create an image pull secret with the appropriate registry credentials.
Push your image to namespace_b by running the following command.

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

This command works because the user has the Writer role in namespace_b.



3. Clean up:



1. Log back in to IBM Cloud Container Registry as User A.

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).
2. List your service policies by running the following command.

ibmcloud iam service-policies cr-roles-tutorial

Note your Policy IDs.
3. Delete your service policies by running the following command for each policy.

ibmcloud iam service-policy-delete cr-roles-tutorial <Policy_ID>
4. Delete your service ID by running the following command.

ibmcloud iam service-id-delete cr-roles-tutorial









 Step 4: Cleaning up your account 

Remove the resources that you created in previous sections to leave your account as it was at the start of this tutorial.



1. Log in to User A's account by running the following command.

ibmcloud login
2. Delete namespace_a, namespace_b, and namespace_c by running the following commands.

ibmcloud cr namespace-rm namespace_a

ibmcloud cr namespace-rm namespace_b

ibmcloud cr namespace-rm namespace_c
3. Remove User B from your account by running the following command.

ibmcloud account user-remove <user.b@example.com>
oc create secret image-registry internal-registry --namespace default --docker-server image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000 --docker-username serviceaccount --docker-password <eyJ...> --docker-email a@b.c
5. Add the image pull secret to the default service account of your project.

oc patch -n <namespace_name> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"<image_pull_secret_name>"}}]'
6. Repeat these steps for each project that you want to pull images from the internal registry.





Now that you set up the internal registry with an accessible route, you can log in, push, and pull images to the registry. For more information, see the [Red Hat OpenShift documentation](https://docs.openshift.com/container-platform/4.11/registry/accessing-the-registry.html).





 Importing images from IBM Cloud Container Registry into the internal registry image stream 

By default, your Red Hat OpenShift on IBM Cloud cluster is set up to pull images from the remote, private IBM Cloud Container Registry icr.io domains in the default project. You can import an image from IBM Cloud Container Registry into the internal registry of your Red Hat OpenShift cluster by tagging the image as an [image stream](https://docs.openshift.com/container-platform/4.11/openshift_images/image-streams-manage.html). With this setup, you can deploy apps from the image by using the local cache of the internal registry, which can make your app deployments build faster. Also, deployments in other projects can refer to the image stream so that you don't have to create image pull secret credentials to IBM Cloud Container Registry in each project.
If your cluster is not in a healthy state, review the [Debugging clusters](https://cloud.ibm.com/docs/containers?topic=containers-debug_clusters) guide for help. For example, if your cluster is provisioned in an account that is protected by a firewall gateway appliance, you must [configure your firewall settings to allow outgoing traffic to the appropriate ports and IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-firewall).
5. In the output of the cluster details from the previous step, check the Public or Private Service Endpoint URL of the cluster.



* Public Service Endpoint URL only: Continue with [Accessing clusters through the public cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_public_se).
* Private Service Endpoint URL only: Continue with [Accessing clusters through the private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_private_se).
* Both service endpoint URLs: You can access your cluster either through the [public](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_public_se) or the [private](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_private_se) service endpoint.



6. You can also access your VPC cluster through the [Virtual Private Endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clustervpc_vpe).







 Accessing clusters through the public cloud service endpoint 

To work with your cluster, set the cluster that you created as the context for a CLI session to run kubectl commands.
For more information, see [Automating access to IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_access).







 Enforcing access to your account over a private network 

You can prevent or allow image pulls or pushes over public network connections for your account by using the [ibmcloud cr private-only](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_private_only) command.

You can also use this command to check whether the use of private connections is set for your account.

After you enable the use of private connections on your account, any attempts to pull and push images or access signatures over the public network are rejected.

Because the use of private connections doesn't apply to the management API, you can still use the CLI over a public connection.



* To prevent image pulls or pushes over public network connections for your account, run the following command.

ibmcloud cr private-only --enable
* To reinstate image pulls or pushes over public network connections for your account, run the following command.

ibmcloud cr private-only --disable
* To check whether the use of public connections is prevented for image pushes or pulls in your account, run the following command.

ibmcloud cr private-only --status
.dockercfg: ey...=
3. Decode the value of the data field.

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

Example output

{"172.21.xxx.xxx:5000":{"username":"serviceaccount","password":"eyJ...
4. Create a new image pull secret for the internal registry.



* secret_name: Give your image pull secret a name, such as internal-registry.
* --namespace: Enter the project to create the image pull secret in, such as default.
* --docker-server: Instead of the internal service IP address (172.21.xxx.xxx:5000), enter the hostname of the image-registry route with the port (image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000).
* --docker-username: Copy the "username" from the previous image pull secret, such as serviceaccount.
* --docker-password: Copy the "password" from the previous image pull secret.
* --docker-email: 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.



oc create secret image-registry internal-registry --namespace default --docker-server image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000 --docker-username serviceaccount --docker-password <eyJ...> --docker-email a@b.c
5. Add the image pull secret to the default service account of your project.
For more information about the components of your cluster and how you can meet security standards for each component, see [Security for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-securitysecurity).





 What access policies do I give my cluster users? 

IBM Cloud Kubernetes Service uses Cloud Identity and Access Management (IAM) to grant access to cluster resources through IAM platform access roles and Kubernetes role-based access control (RBAC) policies through IAM service access roles. For more information about types of access policies, see [Pick the correct access policy and role for your users](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewaccess_roles).

The access policies that you assign users vary depending on what you want your users to be able to do. You can find more information about what roles authorize which types of actions on the [User access reference page](https://cloud.ibm.com/docs/containers?topic=containers-access_reference) or in the following table's links. For steps to assign policies, see [Granting users access to your cluster through IBM Cloud IAM](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).



Types of roles you might assign to meet different use cases.

 Use case Example roles and scope 

 App auditor [Viewer platform access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles), [Reader service access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles).
container-registry.settings.get Get registry service settings for the targeted account, such as whether platform metrics are enabled. 
 container-registry.settings.set Update registry service settings for the targeted account, such as enabling platform metrics. 







 Actions that generate events for signing images 



Table 14. Actions that generate events for signing images

 Action Description Data Event 

 container-registry.signature.delete Delete a signature from an image in Container Registry. True 
 container-registry.signature.read Read a signature from an image in Container Registry. True 
 container-registry.signature.write Write a signature to an image in Container Registry. True 







 Actions that generate events for trash 



Table 15. Actions that generate events for trash

 Action Description Data Event 

 container-registry.trash.list Display all the images in the trash in your IBM Cloud account. 
 container-registry.trash.restore Restore a deleted image from the trash. If the deleted image is signed, the signature is restored too. 







 Actions that generate events for vulnerabilities 



Table 16. Actions that generate events for vulnerabilities

 Action Description Data Event 

 container-registry.account-vulnerability-report.list View the Vulnerability Advisor reports for images in your Container Registry account.<br><br>For more information about request data, see [Request data for the account vulnerability report](https://cloud.ibm.com/docs/Registry?topic=Registry-at_eventsat_events_analyze_report_list). 
 container-registry.account-vulnerability-status.list View Vulnerability Advisor security status for images in your Container Registry account.<br><br>For more information about request data, see [Request data for the account vulnerability status](https://cloud.ibm.com/docs/Registry?topic=Registry-at_eventsat_events_analyze_status_list).
Why am I getting a Forbidden error when I'm using Code Engine? 

You are trying to access IBM Cloud® Container Registry but you are getting a Forbidden error.

  What’s happening 

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

Status code 403 Forbidden

  Why it’s happening 

No token is sent, which means that you are trying to access a private namespace but you didn't send any credentials.

  How to fix it 

If you are accessing Container Registry through Code Engine, confirm that Code Engine is using a pull secret with a valid API key. For more information, see [Add registry access to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce).
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.

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





1. Create a build configuration to build an image from a public Git repo and let Code Engine automatically store and access the image. For example, the following build create command creates a build configuration that is called helloworld-build that builds from source in the public Git repo https://github.com/IBM/CodeEngine. In this example, the command uses the default dockerfile strategy, and the default medium build size. Because the branch name of the repository is not specified with the --commit option, Code Engine automatically uses the default branch of the specified repository, which is main for this Git repo. By not specifying the location of the image registry or a registry secret, Code Engine pushes the build output to IBM Cloud Container Registry with automatic access.

ibmcloud ce build create --name helloworld-build --source https://github.com/IBM/CodeEngine --context-dir /hello

Example output

Creating build helloworld-build...
OK

The following table summarizes the options that are used with the build create command in this example. For more information about the command and its options, see the [ibmcloud ce build create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-create) command.



Table 1. Command description

 Option Description 

 --name The name of the build. Use a name that is unique within the project.