vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Checkmark](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker//images/checkmark-icon.svg) [Location-based events](https://cloud.ibm.com/docs/codeengine?topic=codeengine-at_events) 







 Container services 

The following table lists container platform services that send auditing events:



Table 4. Container events

 Service CRN service name Activity Tracker hosted event search offering Events 

 [IBM Cloud® Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started) container-registry ![Checkmark](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker//images/checkmark-icon.svg) [Location-based events](https://cloud.ibm.com/docs/Registry?topic=Registry-at_events) 
 [IBM Cloud® Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) containers-kubernetes ![Checkmark](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker//images/checkmark-icon.svg) [Location-based events](https://cloud.ibm.com/docs/containers?topic=containers-at_events) 
 [Red Hat® OpenShift® on IBM Cloud®](https://cloud.ibm.com/docs/openshift?topic=openshift-getting-started) openshift !
Getting information about Kubernetes logging agent images 

Kubernetes logging agent images are public images that are available in IBM Cloud through the [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started) service.

You can access the images that are provided by IBM® by using the command line.

Complete the following steps to get information about the logging agent images:



  Before you begin 

Before you begin, complete the following tasks:



1.  Ensure that the IBM Cloud Container Registry CLI is installed, see [Installing the container-registry CLI plug-in](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespacecli_namespace_registry_cli_install).
2.  Log in to [IBM Cloud](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login):

ibmcloud login







  Step 1. Target the global registry 

Run the following command:

ibmcloud cr region-set global





  Step 2. List the logging agent images that are hosted in the global registry 

Run the following command:

ibmcloud cr images --restrict ext/logdna-agent

The output of this command is the list of logging agent images. It includes information about the repository, icr.io/ext/logdna-agent, the image tag, the image digest, the image namespace, when the image was created, the image size, and the images security status.
docker tag <source_image>:<tag> <region>.icr.io/<my_namespace>/<new_image_repo>:<new_tag>

Example, where <source_image> is hello-world, <tag> is latest, <region> is uk, <my_namespace> is namespace1, <new_image_repo> is hw_repo, and <new_tag> is 1:

docker tag hello-world:latest uk.icr.io/namespace1/hw_repo:1
* If you are using Podman, run the following command.

podman tag <source_image>:<tag> <region>.icr.io/<my_namespace>/<new_image_repo>:<new_tag>

Example, where <source_image> is hello-world, <tag> is latest, <region> is uk, <my_namespace> is namespace1, <new_image_repo> is hw_repo, and <new_tag> is 1:

podman tag hello-world:latest uk.icr.io/namespace1/hw_repo:1







 Step 5: Push images to your namespace 



1. Log in to IBM Cloud Container Registry by using one of the following options.



* To log in by using Docker, run the ibmcloud cr login command to log your local Docker daemon in to IBM Cloud Container Registry.

ibmcloud cr login --client docker
* To log in by using Podman, run the ibmcloud cr login command to log in to IBM Cloud Container Registry.

ibmcloud cr login --client podman
* To log in by using other clients, see [Accessing your namespaces interactively](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive).



If you have a problem when you try to log in, see [Why can't I log in to Container Registry?]
* [Accessing the global endpoint](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesendpoint)



* [Logging in to IBM Cloud](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneslogin-ic)
* [Logging in to IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneslogin-iks)



* [Previous IBM Cloud region and zone structure](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesbluemix_regions)







 Supported IBM Cloud and third-party integrations 

[Supported IBM Cloud and third-party integrations](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationssupported_integrations)



* [Popular integrations](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationspopular_services)
* [DevOps services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationsdevops_services)
* [Hybrid cloud services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationshybrid_cloud_services)
* [Logging and monitoring services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationshealth_services)
* [Security services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationssecurity_services)
* [Storage services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationsstorage_services)
* [Database services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationsdatabase_services)







 Default service settings for Kubernetes components
You can use one of the following options to assign access in the console:



* Access policies per user. You can manage access policies per user from the Manage > Access (IAM) > Users page in the console. For more information about the steps to assign IAM access, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=uiaccess-resources-console).
* Access groups. Access groups are used to streamline access management by assigning access to a group once, then you can add or remove users as required from the group to control their access. You manage access groups and their access from the Manage > Access (IAM) > Access groups page in the console. For more information, see [Assigning access to a group in the console](https://cloud.ibm.com/docs/account?topic=account-groups&interface=uiaccess_ag).







 Assigning access to Container Registry in the CLI 

For step-by-step instructions for assigning, removing, and reviewing access, see [Assigning access to resources by using the CLI](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=cliaccess-resources-cli). The following example shows a command for assigning the Manager role for Container Registry:

Use container-registry for the service name.

ibmcloud iam user-policy-create <user@example.com> --service-name container-registry --roles Manager





 Assigning access to Container Registry by using the API 

For step-by-step instructions for assigning, removing, and reviewing access, see [Assigning access to resources by using the API](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=apiaccess-resources-api) or [Create a policy](https://cloud.ibm.com/apidocs/iam-policy-managementcreate-policy) in the API docs. Role cloud resource names (CRN) in the following table are used to assign access with the API.
* [Setting quota limits for storing and pulling images](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quotaregistry_quota_set)
* [Reviewing quota limits and usage](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quotaregistry_quota_get)
* [Staying within quota limits](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quotaregistry_quota_freeup)







 Managing user access 

[Accessing Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access)



* [Accessing your namespaces in automation](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_automating)



* [Creating a service ID API key manually](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_serviceid_apikey_create)
* [Creating a user API key manually](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_user_apikey_create)
* [Using client software to authenticate in automation](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth)



* [Using Buildah to authenticate with the registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth_example_other_buildah)
* [Using Docker to authenticate with the registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth_docker)
},
],
},
];
const policyRoles = [
{
role_id: 'crn:v1:bluemix:public:container-registry::::serviceRole:Manager',
},
];
const accountIdResourceAttribute = {
name: 'accountId',
value: 'ACCOUNT_ID',
operator: 'stringEquals',
};
const serviceNameResourceAttribute = {
name: 'serviceName',
value: 'container-registry',
operator: 'stringEquals',
};
const policyResources = [
{
attributes: accountIdResourceAttribute, serviceNameResourceAttribute]
},
];
const params = {
type: 'access',
subjects: policySubjects,
roles: policyRoles,
resources: policyResources,
};

iamPolicyManagementService.createPolicy(params)
.then(res => {
examplePolicyId = res.result.id;
console.log(JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});





 Assigning access to Container Registry by using Terraform 

The following example is for assigning the Manager role for Container Registry:

Use container-registry for the service name.

resource "ibm_iam_user_policy" "policy" {
ibm_id = "test@example.com"
roles = ["Manager"]

resources {
service = "container-registry"
}
}

For more information, see [ibm_iam_user_policy](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_user_policy) in the Terraform documentation.
[Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Make sure that you have the following permissions: IBM Cloud IAM Operator or Administrator platform access role for Red Hat OpenShift on IBM Cloud. The account owner can give you the role by running the following command.

ibmcloud iam user-policy-create <your_user_email> --service-name containers-kubernetes --roles <(Administrator|Operator)>
3. IBM Cloud IAM Administrator platform access role for IBM Cloud Container Registry, across all regions and resource groups. The policy can't be scoped to a particular region or resource group. The account owner can give you the role by running the following command.

ibmcloud iam user-policy-create <your_user_email> --service-name container-registry --roles Administrator
4. If your account [restricts service ID creation](https://cloud.ibm.com/docs/account?topic=account-restrict-service-id-create), add the Service ID creator role to Identity and Access Management in the console (iam-identity in the API or CLI).
5. If your account [restricts API key creation](https://cloud.ibm.com/docs/account?topic=account-allow-api-create), add the User API key creator role to Identity and Access Management in the console (iam-identity in the API or CLI).





 Updating your image pull secret 

To update your cluster image pull secret in the default Kubernetes namespace.



1. Get your cluster ID.

ibmcloud oc cluster ls
2. Run the following command to create a service ID for the cluster and assign the service ID an IAM Reader service access role for IBM Cloud Container Registry. The command also creates an API key to impersonate the service ID credentials and stores the API key in a Kubernetes image pull secret in the cluster. The image pull secret is in the default Red Hat OpenShift project.
For more information about the command and its options, see the [ibmcloud iam service-policy-create](https://cloud.ibm.com/docs/account?topic=cli-ibmcloud_commands_iamibmcloud_iam_service_policy_create) command.



Table 4. iam service-policy-create command components

 Option Description 

 <service_ID> Required. Replace with the codeengine-<project_name>-id service ID that you previously created. 
 --roles <service_access_role> Required. Enter the [service access role for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamservice_access_roles) that you want to scope the service ID access to. Possible values are Reader, Writer, and Manager. If you are pulling images, then Reader access is sufficient. For more information, see [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry). 
 --service-name <container-registry> Required. Enter container-registry to create an IAM policy for IBM Cloud Container Registry. 



3. Create a custom service policy to allow access to iam-identity service so that Code Engine can retrieve the API key for your service ID with the iam service-policy-create command.

For example, create a policy for codeengine-myproject-id service ID with the role of Operator:

ibmcloud iam service-policy-create codeengine-myproject-id --roles Operator --service-name iam-identity

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



Table 5.
Editor As an editor, you can perform all platform actions except for managing the account and assigning access policies. 
 Operator As an operator, you can perform platform actions required to configure and operate service instances, such as viewing a service's dashboard. 
 Viewer As a viewer, you can view service instances, but you can't modify them. 







 Consult with IBM Cloud Garage 

Review the available platform and service roles and the actions mapped to each to help you assign access. If you're using the CLI or API to assign access, use consult-with-icg-wes for the service name.

Platform roles

Service roles

Actions



Table 23. Platform roles - Consult with IBM Cloud Garage
Use the tab buttons to change the context of the table. This table has row and column headers. The row headers provide the platform role name and the column headers identify the specific information available about each role.

 Role Description 

 Administrator As an administrator, you can perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users. 
 Editor As an editor, you can perform all platform actions except for managing the account and assigning access policies. 
 Operator As an operator, you can perform platform actions required to configure and operate service instances, such as viewing a service's dashboard. 
 Viewer As a viewer, you can view service instances, but you can't modify them. 







 Container Registry 

Review the available platform and service roles and the actions mapped to each to help you assign access. If you're using the CLI or API to assign access, use container-registry for the service name.

Service roles

Actions



Table 24. Service roles - Container Registry
Use the tab buttons to change the context of the table. This table has row and column headers. The row headers provide the service role name and the column headers identify the specific information available about each role.

 Role Description 

 Manager As a manager, you have permissions beyond the writer role to complete privileged actions as defined by the service. In addition, you can create and edit service-specific resources. 
 Reader As a reader, you can perform read-only actions within a service such as viewing service-specific resources.
(https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) 
 List and view items within a project. ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) 







 Code Engine CLI access requirements 

To work with a Code Engine project with the CLI, you must first target a resource group. To target a resource group with the CLI, you need Viewer access to the resource group.





 Code Engine container registry requirements 

For more information about Code Engine requirements for accessing images in a container registry, see [Accessing container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).





 Code Engine service binding access requirements
To work with a Code Engine project with the CLI, you must first target a resource group. To target a resource group with the CLI, you need Viewer access to the resource group.





 Code Engine container registry requirements 

For more information about Code Engine requirements for accessing images in a container registry, see [Accessing container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).





 Code Engine service binding access requirements 

For more information about Code Engine service binding access requirements, see [Configuring access for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccess).





 Code Engine access requirements for your toolchain 

For more information about Code Engine access requirements for building and deploying an app or job with a toolchain, see [Configuring access for your toolchain](https://cloud.ibm.com/docs/codeengine?topic=codeengine-toolchain-cepermissions-toolchain).
: Choose the [platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles) that you want to assign. Possible values are: Administrator, Operator, Editor, or Viewer.



1. Assign the platform access for the user.



* Assign an individual user the Viewer platform access role to one cluster in the default resource group and US East region:

ibmcloud iam user-policy-create user@email.com --resource-group-name default --service-name containers-kubernetes --region us-east --service-instance clusterID-1111aa2b2bb22bb3333c3c4444dd4ee5 --roles Viewer
* Assign an individual user Administrator platform access to all clusters in a HR resource group:

ibmcloud iam user-policy-create user@email.com --resource-group-name HR --service-name containers-kubernetes [--region <region>] --roles Administrator
* Assign an auditors group of users the Viewer platform access role to all clusters in all resource groups:

ibmcloud iam access-group-policy-create auditors --service-name containers-kubernetes --roles Viewer



2. 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. You can find the resource group ID by running ibmcloud resource group <resource_group_name> --id.



* For individual users:

ibmcloud iam user-policy-create <user@email.com> --resource-type resource-group --resource <resource_group_ID> --roles Viewer
* For access groups:

ibmcloud iam access-group-policy-create <access_group> --resource-type resource-group --resource <resource_group_ID> --roles Viewer



3. Verify that the user or access group has the assigned platform access role.



* For individual users:

ibmcloud iam user-policies <user@email.com>
ibmcloud iam user-policy-create user@email.com --resource-group-name HR --service-name containers-kubernetes [--region <region>] --roles Administrator
* Assign an auditors group of users the Viewer platform access role to all clusters in all resource groups:

ibmcloud iam access-group-policy-create auditors --service-name containers-kubernetes --roles Viewer



2. 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. You can find the resource group ID by running ibmcloud resource group <resource_group_name> --id.



* For individual users:

ibmcloud iam user-policy-create <user@email.com> --resource-type resource-group --resource <resource_group_ID> --roles Viewer
* For access groups:

ibmcloud iam access-group-policy-create <access_group> --resource-type resource-group --resource <resource_group_ID> --roles Viewer



3. Verify that the user or access group has the assigned platform access role.



* For individual users:

ibmcloud iam user-policies <user@email.com>
* For access groups:

ibmcloud iam access-group-policies <access_group>





Users must run the ibmcloud ks cluster config command for their role changes to take effect.





 Assigning IBM Cloud IAM service roles from the CLI:** 



1. Get the user information for the individual user or access group that you want to assign the service access role to.



1. Get your Account ID.

ibmcloud account show
2. For individual users, get the user's userID and ibmUniqueId.

ibmcloud account users --account-id <account_ID> --output JSON
3. For access groups, get the Name and ID.

ibmcloud iam access-groups



2.
service_name_resource_attribute = ResourceAttribute(
name='serviceName', value='container-registry')
policy_resources = PolicyResource(
attributes=[account_id_resource_attribute,
service_name_resource_attribute])

policy = iam_policy_management_service.create_policy(
type='access',
subjects=[policy_subjects],
roles=[policy_roles],
resources=[policy_resources]
).get_result()

print(json.dumps(policy, indent=2))

subjectAttribute := &iampolicymanagementv1.SubjectAttribute{
Name: core.StringPtr("iam_id"),
Value: core.StringPtr("IBMid-123453user"),
}
policySubjects := &iampolicymanagementv1.PolicySubject{
Attributes: []iampolicymanagementv1.SubjectAttribute{subjectAttribute},
}
policyRoles := &iampolicymanagementv1.PolicyRole{
RoleID: core.StringPtr("crn:v1:bluemix:public:container-registry::::serviceRole:Manager"),
}
accountIDResourceAttribute := &iampolicymanagementv1.ResourceAttribute{
Name: core.StringPtr("accountId"),
Value: core.StringPtr("ACCOUNT_ID"),
Operator: core.StringPtr("stringEquals"),
}
serviceNameResourceAttribute := &iampolicymanagementv1.ResourceAttribute{
Name: core.StringPtr("serviceName"),
Value: core.StringPtr("container-registry"),
Operator: core.StringPtr("stringEquals"),
}