vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To find a list of supported actions per role, see [platform access roles reference page](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles). Note that if you assign a user the Administrator platform access role for only one cluster, you must also assign the user the Viewer platform access role for all clusters in that region in the resource group.
* Service access role: Grants access to the Kubernetes API from within a cluster so that users can manage Kubernetes resources such as pods, deployments, services, and namespaces. To find a list of supported actions per role, see [service access roles reference page](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles). don't assign a platform access role at the same time as you assign a service access role. If you also want the user to have a platform access role, repeat these steps but leave the namespace field blank and assign only a platform access role (don't assign a service access role again).



8. Click Add.
9. If you assigned only service access roles to users, the users must [launch the Kubernetes dashboard from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appdb_cli) instead of the IBM Cloud console. Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_platform).



4. Assign the users Viewer access to the resource group so that they can work with clusters in resource groups other than default. Note that users must have access to the resource group to create clusters.



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



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



Table 6. Role ID values for API use

 Role name Role CRN 

 Administrator crn:v1:bluemix:public:container-registry::::serviceRole:Administrator 
 Reader crn:v1:bluemix:public:container-registry::::serviceRole:Reader 
 Writer crn:v1:bluemix:public:container-registry::::serviceRole:Writer 
 Manager crn:v1:bluemix:public:container-registry::::serviceRole:Manager 



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

Use container-registry for the service name, and refer to the Role ID values table to ensure that you're using the correct value for the CRN.



* Curl
* Java
* Python
* Go
* Node



curl -X POST 'https://iam.cloud.ibm.com/v1/policies' -H 'Authorization: Bearer $TOKEN' -H 'Content-Type: application/json' -d '{
"type": "access",
"description": "Manager role for Container Registry",
"subjects": [
{
"attributes":
{
"name": "iam_id",
"value": "IBMid-123453user"
}
]
}'
],
"roles":[
{
"role_id": "crn:v1:bluemix:public:container-registry::::serviceRole:Manager"
}
This command requires a name of the registry secret, the URL of the registry server, and the username and password information to access the registry server, and also allows other optional arguments. For a complete listing of options, see the [ibmcloud ce secret create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command.

For example, the following command creates registry access to an IBM Cloud Container Registry instance called myregistry that is on the us.icr.io registry server:

ibmcloud ce secret create --format registry --name myregistry --server us.icr.io --username iamapikey --password API_KEY

Example output

Creating registry secret 'myregistry'...
OK

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



Table 3. Command description

 Option Description 

 --name The name of the registry secret. Use a name that is unique within the project. This value is required.<br><br><br><br> * The name must begin and end with a lowercase alphanumeric character.<br> * The name must be 253 characters or fewer and can contain lowercase letters, numbers, periods (.), and hyphens (-).<br><br><br> 
 --server Enter the URL of the registry server. For Container Registry, the server name is <region>.icr.io. For example, us.icr.io. For [Docker Hub](https://hub.docker.com/), the value is https://index.docker.io/v1/. 
 --username Enter the username to access the registry server. For Container Registry, it is iamapikey.
Click Next to advance to the last section.
7. In the Output section, enter the details of your container image. Select an existing registry access secret, or click Create registry access secret to add a new one. If you are building your image to a Container Registry instance that is in your account, you can select Code Engine managed secret and let Code Engine create and manage the secret for you. Then, select the namespace, repository, and tag of the image you want to build. You can choose to let Code Engine create and manage the namespace in Container Registry for you. If your image exists in Container Registry, you can select from the existing images, or enter a new repository or tag.
8. Click Done to finish the creation of the build.



After you create the build, you must [run the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-run).





 Creating a build configuration with the CLI (private repo) 

To create a build configuration with the CLI, use the build create command. For a complete listing of options, see the [ibmcloud ce build create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-create) command.

With the build create command, you can choose to let Code Engine take care of building the image from your source for you and storing the image in IBM Cloud Container Registry. For this automatic access case, you do not need to specify a registry secret or the location of the image registry. Or, you can specify the location for your build image output and provide a registry secret so that Code Engine can access and push the build result to your registry.



 Creating a build configuration with the CLI (with private repo source and automatic access to registry) 

In this scenario, Code Engine builds an image from your private repository source, and automatically uploads the image to IBM Cloud Container Registry.
Use the API key and [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth) to log in to the registry by running the following Buildah command, replace <apikey> with the API key and <registry_domain> with the domain:

buildah login -u iamapikey -p <apikey> <registry_domain>





 Using Docker to authenticate with the registry 

You can use Docker to authenticate with the registry so that you can push and pull images to and from the registry.

Use the API key and [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth) to log in to the registry by running the following Docker command, replace <apikey> with the API key and <registry_domain> with the domain:

docker login -u iamapikey -p <apikey> <registry_domain>





 Using Podman to authenticate with the registry 

You can use Podman to authenticate with the registry so that you can push and pull images to and from the registry.

Use the API key and [domain](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_apikey_auth) to log in to the registry by running the following Podman command, replace <apikey> with the API key and <registry_domain> with the domain:

podman login -u iamapikey -p <apikey> <registry_domain>





 Using Skopeo to authenticate with the registry 

You can use Skopeo to authenticate with the registry so that you can push and pull images to and from the registry.

For example, you can use the following Skopeo command to pull an image from Docker Hub and push it to your namespace.
* [Setting organizational exemption policies](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_managing_policy)



* [Setting exemption policies by using the console](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_managing_policy_gui)
* [Setting exemption policies by using the CLI](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_managing_policy_cli)









 Setting up Terraform for Container Registry 

[Setting up Terraform for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_terraform-setupregistry_terraform-setup)



* [Installing Terraform and creating a Container Registry namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_terraform-setupregistry_terraform-install)
* [Next steps](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_terraform-setupregistry_terraform-setup-next)







 Enhancing security 

[Managing security and compliance](https://cloud.ibm.com/docs/Registry?topic=Registry-manage-security-compliancemanage-security-compliance)

[Using VPE for VPC to privately connect](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vperegistry_vpe)



* [Before you begin](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vperegistry_vpe_prereqs)
* [Virtual private endpoints](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vperegistry_vpe_endpoints)
* [Setting up a VPE for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vperegistry_vpe_endpoint_setup)
* 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?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login) for assistance.
2. Upload (push) the image to your namespace. Replace <my_namespace> with the namespace that you created in [Set up a namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_namespace_add). Replace <image_repo> and <tag> with the repository and the tag of the image that you chose when you tagged the image. For example, depending on the tool that you are using, run one of the following commands.



* If you are using Docker, run the following command.

docker push <region>.icr.io/<my_namespace>/<image_repo>:<tag>

Example, where <region> is uk, <my_namespace> is namespace1, <image_repo> is hw_repo, and <tag> is 1:

docker push uk.icr.io/namespace1/hw_repo:1

If you have a problem when you try to push a Docker image, see [Why can't I push or pull a Docker image?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-push-pull-docker) for assistance.
* If you are using Podman, run the following command.

podman push <region>.icr.io/<my_namespace>/<image_repo>:<tag>
Classic infrastructure roles 

A user with the Super User infrastructure access role [sets the API key for a region and resource group](https://cloud.ibm.com/docs/containers?topic=containers-access-creds) so that infrastructure actions can be performed, or more rarely, [manually sets different account credentials](https://cloud.ibm.com/docs/containers?topic=containers-access-credscredentials). Then, the infrastructure actions that other users in the account can perform is authorized through IBM Cloud IAM platform access roles. You don't need to edit the other users' classic infrastructure permissions. Use the following table to customize classic infrastructure permissions only when you can't assign Super User to the user who sets the API key. For instructions to assign permissions, see [Customizing infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access).

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

Need to check that the API key or manually set credentials have the required and suggested infrastructure permissions? Use the ibmcloud ks infra-permissions get[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliinfra_permissions_get).

The following table shows the classic infrastructure permissions that the credentials for a region and resource group can have for creating clusters and other common use cases. The description includes how you can assign the permission in the IBM Cloud IAM Classic infrastructure console or the ibmcloud sl command. For more information, see the instructions for the [console](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_console) or [CLI](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_cli).

Create clusters
If you want to limit access to only images in certain [IBM Cloud Container Registry namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_setup_cli_namespace_plan), enter namespace for the resource type and specify the <registry_namespace>. To list registry namespaces, run ibmcloud cr namespaces.
4. Create an API key for the service ID. Name the API key similar to your service ID, and include the service ID that you previously created, <cluster_name>-<kube_namespace>-id. Be sure to give the API key a description that helps you retrieve the key later.

ibmcloud iam service-api-key-create <cluster_name>-<project>-key <cluster_name>-<project>-id --description "API key for service ID <service_id> in Red Hat OpenShift on IBM Cloud cluster <cluster_name> project <project>"
5. Retrieve your API Key value from the output of the previous command.

Please preserve the API key! It can't be retrieved after it's created.

Name <cluster_name>-<kube_namespace>-key
Description key_for_registry_for_serviceid_for_kubernetes_cluster_multizone_namespace_test
Bound To crn:v1:bluemix:public:iam-identity::a/1bb222bb2b33333ddd3d3333ee4ee444::serviceid:ServiceId-ff55555f-5fff-6666-g6g6-777777h7h7hh
Created At 2019-02-01T19:06+0000
API Key i-8i88ii8jjjj9jjj99kkkkkkkkk_k9-llllll11mmm1
Locked false
UUID ApiKey-222nn2n2-o3o3-3o3o-4p44-oo444o44o4o4
6.
Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_platform).
5. Optional: After a couple minutes, verify that the user is added to the corresponding [RBAC role binding or cluster role binding](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-rbac).



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







 Understanding RBAC permissions 

RBAC roles and cluster roles define a set of permissions for how users can interact with Kubernetes resources in your cluster.

With IBM Cloud IAM, you can automatically manage RBAC from IBM Cloud, by assigning users [service access roles](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users). You might want a deeper understanding of RBAC to customize access for resources within your cluster, like service accounts.



 What are the types of RBAC roles? 



* A Kubernetes role is scoped to resources within a specific namespace, such as a deployment or service.
* A Kubernetes cluster role is scoped to cluster-wide resources, such as worker nodes, or to namespace-scoped resources that can be found in each namespace, like pods.







 What are RBAC role bindings and cluster role bindings? 

Role bindings apply RBAC roles or cluster roles to a specific namespace. When you use a role binding to apply a role, you give a user access to a specific resource in a specific namespace. When you use a role binding to apply a cluster role, you give a user access to namespace-scoped resources that can be found in each namespace, like pods, but only within a specific namespace.

Cluster role bindings apply RBAC cluster roles to all namespaces in the cluster. When you use a cluster role binding to apply a cluster role, you give a user access to cluster-wide resources, like worker nodes, or to namespace-scoped resources in every namespace, like pods.





 What do these roles look like in my cluster?
If you assigned only service access roles to users, the users must [launch the Kubernetes dashboard from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appdb_cli) instead of the IBM Cloud console. Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_platform).





 Overview of RBAC 

In Kubernetes, role-based access control (RBAC) is a way of securing the resources inside your cluster. RBAC roles determine the Kubernetes actions that users can perform on those resources, such as Kubernetes pods, namespaces, or services. Example actions that are permitted by RBAC roles are creating objects such as pods or reading pod logs.

You can assign RBAC roles through the following methods.

By using IBM Cloud IAM
: You can use IAM to automatically create and manage RBAC in your cluster, by assigning [service access roles](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewservice-roles-ov) to users. Every user who is assigned a service access role is automatically assigned a corresponding RBAC cluster role. This RBAC cluster role is applied either in a specific namespace or in all namespaces, depending on whether you scope the policy to a namespace. Change that you make to the user in IAM, such as updating or removing the service access policy, are automatically synchronized to the RBAC in your cluster. The synchronization of service roles to RBAC might take a couple minutes, depending on the number of users and namespaces in your cluster.

Managing your own RBAC
: See [Assigning RBAC permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewrole-binding).





 Overview of classic infrastructure 

Classic infrastructure roles enable access to your classic IBM Cloud infrastructure resources.

Set up a user with Super User infrastructure role, and store this user's infrastructure credentials in an API key.
* For IBM Cloud Container Registry: [Copy the <region>.icr.io secrets](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret) from the default project.
* For other private registries: [Create an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryprivate_images) with image pull access to the private registry.



2. [Add the secret to the builder service account](https://cloud.ibm.com/docs/openshift?topic=openshift-registrystore_imagePullSecret) or [specify the image pull secret in the build configuration file](https://cloud.ibm.com/docs/openshift?topic=openshift-imagespod_imagePullSecret).

Example to link the secret to the builder service account in a project.

oc secrets link builder <pull-secret>

Example to refer to the secret in the build configuration file.

spec:
output:
to:
kind: "DockerImage"
name: "<private.registry.com>/<namespace>/<image>:<tag>"
pushSecret:
name: "<pull-secret>"



* Use an image stream from the internal registry: [Create an image stream in the internal registry from an imported image from the private registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry). Then, update the build configuration file to refer to the image stream instead of pulling the image directly from the private registry.
Bound To crn:v1:bluemix:public:iam-identity::a/1bb222bb2b33333ddd3d3333ee4ee444::serviceid:ServiceId-ff55555f-5fff-6666-g6g6-777777h7h7hh
Created At 2019-02-01T19:06+0000
API Key i-8i88ii8jjjj9jjj99kkkkkkkkk_k9-llllll11mmm1
Locked false
UUID ApiKey-222nn2n2-o3o3-3o3o-4p44-oo444o44o4o4
6. Create an image pull secret to store the API key credentials in the cluster project. Repeat this step for each project of each cluster for each icr.io domain that you want to pull images from.

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

--namespace <project>
: Required. Specify the Red Hat OpenShift project of your cluster that you used for the service ID name.

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

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

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

--docker-password <token_value>
: Required.
In such a case, it's possible to dynamically override the registry as well as the pull credentials. This is a coordinated effort between the workload provider and the deployer.

The templating approach only works for a [compose](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_compose)-based workload and also only for images referenced via a digest (no support for DCT-based workloads).



 Workload provider 

The workload provider marks the registry as dynamic by using a replacement variable in the docker compose file:

services:
helloworld:
image: ${REGISTRY}/hpse-docker-hello-world-s390x@sha256:43c500c5f85fc450060b804851992314778e35cadff03cb63042f593687b7347

Note that the digest of the image is identical across registries, so the workload provider can lock down the desired version of the image by setting the key, independent of what registry is actually being used. Using tokens in the compose file is a native feature of the [compose specification](https://docs.docker.com/compose/compose-file/interpolation).

Now the workload provider can prepare (encrypt) the workload section without specifying the pull secrets for that registry.





 Deployer 

The deployer fills in the missing information about the registry and the associated pull secrets.

The registry is set as an environment variable. Both the deployer and the workload provider can provide pieces to the overall environment and these are overlaid (with workload taking precedence).

The pull credentials are passed in via an auth section in the environment part of the contract. Just as environment variables, these sections are overlaid with the workload section taking precedence.

---
env:
type: env
auths:
de.icr.io:
username: xxx
password: yyy
env:
REGISTRY: de.icr.io