vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Use platform access roles in IBM Cloud Identity and Access Management (IAM) to grant users access to manage cluster resources in IBM Cloud Kubernetes Service. When you configure permissions for IBM Cloud Kubernetes Service in IAM, use the name containers-kubernetes for the API or CLI, and Kubernetes Service for the console.

What types of actions do platform access roles permit?
: With platform access roles, users can manage resources like clusters, worker pools, worker nodes, and add-ons. Example actions that are permitted by platform access roles are creating or removing clusters, binding services to a cluster, managing networking and storage resources, or adding extra worker nodes. You can set the policies for these roles by resource group, region, or cluster instance. You can't scope a platform access role by namespace within a cluster.

For more information, see [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles).

Platform access roles don't grant access to the Kubernetes API to manage resources within the cluster, like Kubernetes pods, namespaces, or services. However, users can still perform the ibmcloud ks cluster config command to set the Kubernetes context to the cluster. Then, you can authorize the users to perform select Kubernetes actions by using [custom RBAC policies](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewrole-binding). You might do this if your organization currently uses custom RBAC policies to control Kubernetes access and plans to continue using custom RBAC instead of service access roles.

Although platform access roles authorize you to perform infrastructure actions on the cluster, they don't grant access to the IBM Cloud infrastructure resources. Access to the IBM Cloud infrastructure resources is determined by the [API key that is set for the region](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewapi_key).





 Overview of IBM Cloud IAM service access roles
ibmcloud iam service-policy-create <cluster_service_ID> --roles <service_access_role> --service-name container-registry [--region <IAM_region>] [--resource-type namespace --resource <registry_namespace>]

cluster_service_ID
: Required. Replace with the <cluster_name>-<kube_namespace>-id service ID that you previously created for your Kubernetes cluster.

--service-name container-registry
: Required. Enter container-registry so that the IAM policy is for IBM Cloud Container Registry.

--roles <service_access_role>
: Required. Enter the [service access role](https://cloud.ibm.com/docs/Registry?topic=Registry-iamservice_access_roles) for IBM Cloud Container Registry that you want to scope the service ID access to. Possible values are Reader, Writer, and Manager.

--region <IAM_region>
: Optional. If you want to scope the access policy to certain IAM regions, enter the regions in a comma-separated list. Possible values are global and the [local registry regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions_local).

--resource-type namespace --resource <registry_namespace>
: Optional. 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.
Note: You must [expose the master endpoint through a private load balancer](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_private_se) so that users can access the master through a VPN or IBM Cloud® Direct Link connection.

curl --insecure <private_service_endpoint_URL>/version

Example command

curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version

Example output

{
"major": "1",
"minor": "7+",
"gitVersion": "v1.7.4-2+eb9172c211dc41",
"gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
"gitTreeState": "clean",
"buildDate": "2017-11-16T08:13:08Z",
"goVersion": "go1.8.3",
"compiler": "gc",
"platform": "linux/amd64"
}



7. Optional: Repeat these steps for each cluster that you need to expose.







 Running calicoctl commands from behind an allowlist 

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

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



1.
Example, where <my_chart_package> is mychart-0.1.0.tgz, region is uk, and <my_namespace> is helm-charts:

helm push mychart-0.1.0.tgz oci://uk.icr.io/helm-charts

If you get an unauthorized: authentication required or a denied: requested access to the resource is denied message, run the ibmcloud cr login command.



After you push your chart to IBM Cloud Container Registry, you can [install the Helm chart to the cluster in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_chartsregistry_helm_charts_install).





 Copying charts between registries 

You can pull a chart from a registry in one region and push it to a registry in another region so that you can share the chart with users in both regions.

Zoom

![Copying charts between registries.](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/images/copying_images_mul.svg)

Figure 3. Copying charts between registries

Before you begin, complete the following tasks.



* [Install the CLI](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespacecli_namespace_registry_cli_install) to work with your namespace.
* [Set up your own namespace in IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_setup).
* Install the latest release of [Helm CLI](https://github.com/helm/helm/releases) to work with charts.



To copy a chart between two registries, complete the following steps:



1.
From the "Configure default registry access" page, you can optionally expand the What Code Engine does for you section to view information about what Code Engine automatically creates for you when you configure default registry access to a specific location. View information about the service ID and the access policies that are assigned to this service ID, the API key that Code Engine automatically generates for the service ID, and the registry secret that is used for this registry access.
4. Click Configure to configure the default registry access for a specific location.
5. From the table, you can view configuration status by location and the autogenerated registry secret.
6. (optional) For more details, click the Actions icon ![Actions](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/icons/action-menu-icon.svg) > View details. You can view information about the service ID and the access policies that are assigned to this service ID, the API key that Code Engine automatically generates for the service ID, and the registry secret that is configured for accessing Container Registry.



Now that you configured default registry access for a specific location to Container Registry, every user with writer or manager access to this Code Engine project can use this registry access secret with their apps, jobs, and builds to access images in Container Registry.

When you configure project-wide Container Registry access from the Integrations page, Code Engine automatically generates a service ID to enable registry access to Container Registry.

When you are working with a Code Engine autogenerated (and managed) registry access secret, do not manually delete the registry access secret. Also, do not manually remove the service ID or its associated API key for the configured Container Registry region. Do not attempt to rotate the API key that is associated with this service ID. Instead, go to the Project settings > Integrations page in the console, and remove the configuration for the desired Container Registry access for your project, and then configure registry access again.
Or, you can choose user-provided access and specify registry details along with a registry secret to access your built image in the registry.

For a complete listing of options for running a single build, see the [ibmcloud ce buildrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-submit) command.



 Running a single build with the CLI (with private repo source and automatic access to registry) 

In this automatic access scenario, Code Engine builds an image from your private repository source, and uploads the image to IBM Cloud Container Registry with automatic access by using build options with the buildrun submit command. In this case, you do not need to specify a registry secret or the location of the image registry.

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).
* [Create a Git repository secret to access your source](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories).





1. Run a build to build an image from a private repository and let Code Engine automatically store and access the image. For example, the following buildrun submit command runs a build run that is called helloworld-buildrun-private that builds from the private Git repo https://github.com/myprivaterepo/builds.
Deploy an application that uses an image in a container registry with the CLI with the ibmcloud ce app create command.

Before you begin



* Set up your [Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli) environment.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



Before you can work with a Code Engine application that references an image in a private registry, you must first add access to the registry, pull the image, and then deploy it.



1. To pull images from a private registry, you must first create a private registry. For example, to create a private Docker Hub registry, see [Docker Hub documentation](https://docs.docker.com/docker-hub/repos/). After you create a private registry, [push an image to it](https://docs.docker.com/docker-hub/repos/pushing-a-docker-container-image-to-docker-hub). You can also set up an access token. By using an access token, you can more easily grant and revoke access to your Docker Hub account without requiring a password change. For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).
2. Add access to your private registry to pull images. To add access to a private registry with the CLI, use the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command to create a registry secret. For example, the following command creates registry access to a Docker Hub registry called privatedocker that is at 'https://index.docker.io/v1/' and uses your username and password.
You might do this if your organization currently uses custom RBAC policies to control Kubernetes access and plans to continue using custom RBAC instead of service access roles.

Although platform access roles authorize you to perform infrastructure actions on the cluster, they don't grant access to the IBM Cloud infrastructure resources. Access to the IBM Cloud infrastructure resources is determined by the [API key that is set for the region](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewapi_key).





 Overview of IBM Cloud IAM service access roles 

Use service access roles in IBM Cloud Identity and Access Management (IAM) to grant users access to manage Kubernetes resources in Red Hat OpenShift on IBM Cloud clusters. When you configure permissions for Red Hat OpenShift on IBM Cloud in IAM, use the name containers-kubernetes for the API or CLI, and Kubernetes Service for the console.

Service access roles are synchronized with corresponding Kubernetes RBAC policies in a cluster. As such, service access roles grant access to the Kubernetes API, dashboard, and CLI (oc). Example actions that are permitted by service access roles include creating app deployments, adding namespaces, or setting up configmaps.

You can scope the policy for service access roles by resource group, region, or cluster instance. Further, you can also scope service access roles to Kubernetes namespaces that are in all, individual, or region-wide clusters. When you scope a service access role to a namespace, you can't apply the policy to a resource group or assign a platform access role at the same time.

If you assigned only service access roles to users, the users must be given the cluster master URL to open the Red Hat OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli_platform).





 Overview of RBAC
Deploy the application using the IBM Cloud Container Registry 

In this section, you will deploy the application to the cluster using the generated openshift_private_registry.yaml file. Once deployed, you will access the application by creating a route.



1. Create a new openshift app along with a buildconfig(bc), deploymentconfig(dc), service(svc), imagestream(is) using the updated yaml

oc apply -f openshift_private_registry.yaml
2. To check the builder container image creation and pushing to the Container Registry, run the below command

oc logs -f bc/$MYPROJECT

In the logs, you should see the below message if the container image is pushed to the private container registry

Pushing image us.icr.io/mods15/vmac-openshift-app-registry:latest ...
Getting image source signatures
Copying blob sha256:9d038e1c7afbe92c29313557c02110e8fb796818ebb78441c68929381103a94b
Copying blob sha256:61c671f49591a059c9b6728a9f84c16f5b00126470112ee9c9f9e01dbbfcc3ea
Copying blob sha256:e2787650308235c87eff7d2b88c3ab217e84b74a3fa9696103bd46bb99068c7a
Copying blob sha256:dcef409117430ed9906a59ad0a3ea0752061fbf8a9e544f4edd77667a25d85ae
Copying blob sha256:a1f889dd610c6510c7fc091a51c247463f3cc9a7c67bdc397c9632168808f7d2
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). 
 App developers [Editor platform access role for a cluster](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles), [Writer service access role scoped to a namespace](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles), [Cloud Foundry developer space role](https://cloud.ibm.com/docs/containers?topic=containers-cloud-foundry-roles). 
 Billing [Viewer platform access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles). 
 Create a cluster See [Permissions to create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_referencecluster_create_permissions).
You won’t be able to see this API key again, so be sure to record it in a safe place.

Now that you have your access policies in place for your service ID and your API key that is created, you can [add access to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce) to pull images from your container registry.









 Considerations for images in your registry 

The name of your image that is used for your app or job must be in one of the following formats.



* REGISTRY/NAMESPACEorDOCKERUSERorDOCKERORG/REPOSITORY:TAG where REGISTRY and TAG are optional. If REGISTRY is not specified, the default is docker.io. If TAG is not specified, do not include the colon (:). The default for TAG is latest.
* REGISTRY/NAMESPACEorDOCKERUSERorDOCKERORG/REPOSITORY@IMAGEID where REGISTRY is optional. If REGISTRY is not specified, the default is docker.io and ibm as the Docker organization.





Table 6. Rules for image name

 Component Characters allowed Length Additional rules 

 REGISTRY a-zA-Z0-9 -_. --__ 1-253 (0-127Periods)(label:1-63,noDashOnEnd) 
 NAMESPACE a-z 0-9 -_ --__ 4-30 (start/end with letterOrNumber) 
 DOCKERUSERorDOCKERORG a-z 0-9 4-30 
 REPOSITORY a-z 0-9 -_. / 2-255 (start/end with letterOrNumber) 
 TAG a-zA-Z0-9 -_. --__.. 0-128 (NOT start with periodOrDash) 
 IMAGEID a-z 0-9 : (startwith sha256: noOtherColon) 



The parts of the image name must meet the following criteria.



* REGISTRY must be 253 characters or fewer and can contain lowercase or uppercase letters, numbers, periods (.), hyphens (-), and underscores (_).
POST/v2/enablePullSecret Create image pull secret to IBM Cloud Container Registry in the default Kubernetes namespace. containers-kubernetes.cluster.operate containers-kubernetes.cluster.update 
 POST/v2/refreshMaster Refresh the Kubernetes master. containers-kubernetes.cluster.operate containers-kubernetes.account.update 
 POST/v2/updateMaster Update the version of the Kubernetes cluster master node. containers-kubernetes.cluster.operate containers-kubernetes.account.update 
 POST/v2/vpc/createCluster Create a VPC cluster. containers-kubernetes.cluster.create containers-kubernetes.cluster.create 
 PUT/v1/clusters/{idOrName} Update the version of the Kubernetes cluster master node. containers-kubernetes.cluster.operate containers-kubernetes.cluster.update 
 PUT/v1/clusters/{idOrName}/apiserverconfigs/auditwebhook Create or update an audit webhook configuration for a cluster. containers-kubernetes.cluster.update containers-kubernetes.cluster.update 
 PUT/v1/clusters/{idOrName}/masters Refresh the Kubernetes master. containers-kubernetes.cluster.operate containers-kubernetes.cluster.update 
 PUT/v1/clusters/{idOrName}/subnets/{subnetId} Add an existing IBM Cloud infrastructure subnet to an existing cluster. containers-kubernetes.cluster.operate containers-kubernetes.subnet.update 







 Image security 



Image security API methods, IAM actions, and Activity Tracker events.

 API Method Description IAM action for the API Activity Tracker event 

 POST/v2/enableImageSecurity Enable image security. containers-kubernetes.cluster.operate cluster-image-security.enable 
 POST/v2/disableImageSecurity Disable image security. containers-kubernetes.cluster.operate cluster-image-security.disable 







 Ingress
The image pull secrets are added to the default Kubernetes namespace and the list of secrets in the default service account for this Kubernetes namespace. By using image pull secrets, your deployments can pull images (read-only access) from the [global and regional IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions) to deploy containers in the default Kubernetes namespace.



* The global registry securely stores public images that are provided by IBM. You can refer to these public images across your deployments instead of having different references for images that are stored in each regional registry.
* The regional registry securely stores your own private Docker images.



What if I don't have image pull secrets in the default Kubernetes namespace?
: You can check the image pull secrets by [logging in to your cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster) and running kubectl get secrets -n default | grep "icr-io". If no icr secrets are listed, the person who created the cluster might not have had the required permissions to IBM Cloud Container Registry in IAM. See [Updating existing clusters to use the API key image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryimagePullSecret_migrate_api_key).

Can I restrict pull access to a certain regional registry?
: Yes, you can [edit the existing IAM policy of the service ID](https://cloud.ibm.com/docs/account?topic=account-serviceidsupdate_serviceid) that restricts the Reader service access role to that regional registry or a registry resource such as a namespace. Before you can customize registry IAM policies, you must [enable IBM Cloud IAM policies for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-useruser).
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? 

See [Permissions to create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_referencecluster_create_permissions) and [Ensuring that the API key or infrastructure credentials owner has the correct permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsowner_permissions).

To check a user's permissions, review the access policies and access groups of the user in the [IBM Cloud console](https://cloud.ibm.com/iam/users), or use the ibmcloud iam user-policies <user> command.

If the API key is based on one user, how are other cluster users in the region and resource group affected?

Other users within the region and resource group of the account share the API key for accessing the infrastructure and other services with IBM Cloud Kubernetes Service clusters. When users log in to the IBM Cloud account, an IBM Cloud IAM token that is based on the API key is generated for the CLI session and enables infrastructure-related commands to be run in a cluster.

To see the IBM Cloud IAM token for a CLI session, you can run ibmcloud iam oauth-tokens. IBM Cloud IAM tokens can also be used to [make calls directly to the IBM Cloud Kubernetes Service API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installcs_api).





 How do I limit which commands a user can run?