vania-janet/multiturn-rag-retrieval-data huggingface dataset:
}
Show more



Table 1. Understanding options for service access role policy

 Component Description 

 subjects.attributes Enter the IBM Cloud IAM details for the individual user or access group that you previously retrieved.<br><br><br><br> * For individual users, set iam_id for the name field. Enter the previously retrieved ibmUniqueId for the value field.<br><br><br> 
 roles.role_id Choose the [IAM service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles) that you want to assign. Possible values are:<br><br><br><br> * crn:v1:bluemix:public:iam::::serviceRole:Manager<br> * crn:v1:bluemix:public:iam::::serviceRole:Writer<br> * crn:v1:bluemix:public:iam::::serviceRole:Reader<br><br><br> 
 resources.attributes Configure the scope of the policy to your account, cluster, and namespace. Leave the "name" fields as given in the example, and enter certain "value" fields as follows.<br><br><br><br> * For "accountId": Enter your IBM Cloud account ID that you previously retrieved.<br> * For "serviceName": Leave the service name as given: containers-kubernetes.<br> * For "serviceInstance": Enter your cluster ID. For multiple clusters, separate with a comma. To get your cluster ID, run ibmcloud oc cluster ls.<br> * For "namespace": Enter a Kubernetes namespace in your cluster. To list the namespaces in your cluster, run oc get namespaces.<br><br><br><br>To assign the access policy to all namespaces in a cluster, remove the entire {"name": "namespace", "value": "<namespace_name"} entry. 



3.
The CLI steps vary depending on which access role you want to assign:



* [Assign platform access roles from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_platform)
* [Assign service access roles from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-usersadd_users_cli_service)







 Assigning IBM Cloud IAM platform roles from the CLI 

Create an IBM Cloud IAM access policy to set permissions for IBM Cloud Kubernetes Service (--service-name containers-kubernetes). Scope the access policy based on what you want to assign access to with the following options.

User
: CLI option: N/A
: You can assign the policy to an individual or group of users. Place this positional option immediately following the command.



* Individual user: Enter the email address of the user.
* Access group: Enter the name of the access group of users. You can create an access group with the ibmcloud iam access-group-create command. To list available access groups, run ibmcloud iam access-groups. To add a user to an access group, run ibmcloud iam access-group-user-add <access_group_name> <user_email>.



Resource group
: ClI option: --resource-group-name
: You can grant a policy for a resource group. If you don't specify a resource group or a specific cluster ID, the policy applies to all clusters for all resource groups. To list available resource groups, run ibmcloud resource groups.

Cluster
: ClI option: --service-instance
: You can limit the policy to a single cluster. To list your cluster IDs, run ibmcloud ks cluster ls. 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 the region within the resource group.

Region
: ClI option: --region
Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--alb ALB_ID
: Required: The ID for an ALB. To view the IDs for the ALBs in a cluster, run ibmcloud ks ingress alb ls --cluster CLUSTER.

-c, --cluster CLUSTER
: The name or ID of the cluster.

-q
: Optional: Do not show the message of the day or update reminders.



 Example ingress alb disable command 

ibmcloud ks ingress alb disable --alb public-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --cluster mycluster







 ibmcloud ks ingress alb enable classic 

Classic infrastructure

Enable an ALB in your classic cluster.

The previous alias for this command, ibmcloud ks ingress alb configure classic, is deprecated.

You can use this command to:



* Enable a default private ALB. When you create a cluster, a default private ALB is created for you in each zone where you have workers and an available private subnet, but the default private ALBs are not enabled. However, all default public ALBs are automatically enabled, and any public or private ALBs that you create with the ibmcloud ks ingress alb create classic command are enabled by default too.
* Enable an ALB that you previously disabled.



ibmcloud ks ingress alb enable classic --alb ALB_ID --cluster CLUSTER [--ip IP_ADDRESS] [--version IMAGE_VERSION] [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--alb ALB_ID
: Required: The ID for an ALB. To view the IDs for the ALBs in a cluster, run ibmcloud ks ingress alb ls --cluster CLUSTER.

-c, --cluster CLUSTER
: The name or ID of the cluster.
IAM service access roles 

Every user who is assigned an IBM Cloud IAM service access role is also automatically assigned a corresponding Kubernetes role-based access control (RBAC) role in a specific namespace. To assign service access roles, see [Granting users access to your cluster through IBM Cloud IAM](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms). Do not assign IBM Cloud IAM platform access roles at the same time as a service access role. You must assign platform and service access roles separately.

Looking for which Kubernetes actions each service access role grants through RBAC? See [Kubernetes resource permissions per RBAC role](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-rolesrbac_ref). To learn more about RBAC roles, see [Assigning RBAC permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewrole-binding) and [Extending existing permissions by aggregating cluster roles](https://cloud.ibm.com/docs/openshift?topic=openshift-usersrbac_aggregate). For the username details, see [IBM Cloud IAM issuer details for RBAC users](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-rolesiam-issuer-users).

See the IAM Policy Management [API reference](https://cloud.ibm.com/apidocs/iam-policy-managementlist-roles) for more information on managing IAM roles with the API.



 Kubernetes Service 

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 containers-kubernetes for the service name.

Platform roles

Service roles

Actions



Table 25. Platform roles - Kubernetes Service
Use the tab buttons to change the context of the table.
ibmcloud ob logging config create 

Virtual Private Cloud

Classic infrastructure

Create a logging configuration for your cluster to automatically collect pod logs and send them to IBM Log Analysis.

This command deploys a Log Analysis agent as a Kubernetes daemon set in your cluster. The agent collects logs with the extension .log and extensionless files that are stored in the /var/log directory of your pod from all namespaces, including kube-system. For more information, see [Forwarding cluster and app logs to IBM Log Analysis](https://cloud.ibm.com/docs/containers?topic=containers-healthlogging). For more information about IBM Log Analysis, see [Securing your data](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-mng-data).

ibmcloud ob logging config create --cluster CLUSTER --instance LOGGING_INSTANCE [--logdna-ingestion-key INGESTION_KEY] [--private-endpoint]

Minimum required permissions:



* Administrator platform access role and Manager service access role for all Kubernetes namespaces in IBM Cloud Kubernetes Service
* Editor platform access role and Manager server access role for IBM Log Analysis



Command options:

--cluster CLUSTER
: The name or ID of the cluster for which you want to create a logging configuration for IBM Log Analysis. To retrieve your cluster name or ID, run ibmcloud ks clusters. This value is required.

--instance LOGGING_INSTANCE
: The ID or name of the IBM Log Analysis service instance that you want to use to create the logging configuration. The service instance must be in the same IBM Cloud account as your cluster, but can be in a different resource group or region than your cluster. To create a service instance, follow the steps in [Provision an instance](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-provision). This value is required.

--logdna-ingestion-key INGESTION_KEY
: The Log Analysis ingestion key that you want to use for your configuration. This value is optional.
* Content-Type: application/x-www-form-urlencoded
* Authorization: Basic a3ViZTprdWJla3ViZTprdWJl equals the URL-encoded authorization for the username kube and the password kube.
* cache-control: no-cache

<-- </ul> -->

Body
: <-- <ul> -->

* refresh_token: Your IBM Cloud IAM delegated refresh token.
* grant_type: urn:ibm:params:oauth:grant-type:delegated-refresh-token

<-- </ul> -->

The following example shows output from the previous API request.

{
"access_token": "<iam_access_token>",
"id_token": "<iam_id_token>",
"refresh_token": "<iam_refresh_token>",
"token_type": "Bearer",
"expires_in": 3600,
"expiration": 1553629664,
"scope": "ibm openid containers-kubernetes"
}
4. Retrieve the URL of the default service endpoint for your Kubernetes master by using the IAM access token and the name or ID of your cluster. You can find the URL in the masterURL of your API output.
If only the public cloud service endpoint or only the private cloud service endpoint is enabled for your cluster, that endpoint is listed for the masterURL. If both the public and private cloud service endpoints are enabled for your cluster, the public cloud service endpoint is listed by default for the masterURL. To use the private cloud service endpoint instead, find the URL in the privateServiceEndpointURL field of the output.

GET https://containers.cloud.ibm.com/global/v2/getCluster?cluster=<cluster_name_or_ID>

Header
: <-- <ul> -->
Kubernetes admission controllers configuration N/A N/A Added DenyServiceExternalIPs to the --enable-admission-plugins option for the cluster's [Kubernetes API server](https://cloud.ibm.com/docs/containers?topic=containers-service-settingskube-apiserver). The update resolves CVE-2020-8554 (see the [IBM security bulletin](https://www.ibm.com/support/pages/node/6428013)). 
 Kubernetes configuration N/A N/A Updated the [feature gate configuration](https://cloud.ibm.com/docs/containers?topic=containers-service-settingsfeature-gates). 
 Kubernetes add-on resizer 1.8.12 1.8.13 See the [Kubernetes add-on resizer release notes](https://github.com/kubernetes/autoscaler/releases/tag/addon-resizer-1.8.13). 
 Kubernetes Dashboard v2.1.0 v2.2.0 See the [Kubernetes Dashboard release notes](https://github.com/kubernetes/dashboard/releases/tag/v2.2.0). 
 Pause container image 3.2 3.5 See the [pause container image release notes](https://github.com/kubernetes/kubernetes/blob/master/build/pause/CHANGELOG.md).
Learning path for developers 

Following a curated learning path to deploy highly available containerized apps in Kubernetes clusters and use the powerful tools of IBM Cloud Kubernetes Service to automate, isolate, secure, manage, and monitor your app workloads across zones or regions.



 Access the cluster 

Begin working with your cluster by setting up the CLI and accessing the cluster.



1. CLI setup: [Set up the CLIs](https://cloud.ibm.com/docs/containers?topic=containers-cli-install) that are necessary to create and work with clusters. As you work with your cluster, refer to the [command reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli) and keep track of CLI version updates with the [CLI change log](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog).
2. User permissions: Ensure that your cluster administrator gives you the proper [IBM Cloud IAM role](https://cloud.ibm.com/docs/containers?topic=containers-learning-path-adminadmin_secure) to access the cluster.
3. Cluster access: [Access your cluster through the public or private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster).



Need help? Check out [Troubleshooting clusters and masters](https://cloud.ibm.com/docs/containers?topic=containers-debug_clusters) and [Troubleshooting worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-debug_worker_nodes).





 Plan your deployment 

Before you deploy an app, decide how you want to set up your app so that your app can be accessed properly and be integrated with other services.



1. Kubernetes-native: [Plan your strategy for developing a Kubernetes-native app](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploy).
2.
List the services that are bound to one or all the Kubernetes namespace in a cluster. If no options are specified, the services for the default namespace are displayed.

ibmcloud ks cluster service ls --cluster CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces] [--output json] [-q]

Minimum required permissions
: Viewer platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-n, --namespace KUBERNETES_NAMESPACE
: Optional: Include the services that are bound to a specific namespace in a cluster.

--all-namespaces
: Optional: Include the services that are bound to all the namespaces in a cluster.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example cluster service ls command 

ibmcloud ks cluster service ls --cluster my_cluster --namespace my_namespace







 ibmcloud ks cluster service unbind 

Virtual Private Cloud

Classic infrastructure

Remove an IBM Cloud service from a cluster by unbinding it from a Kubernetes namespace.

When you remove an IBM Cloud service, the service credentials are removed from the cluster. If a pod is still using the service, it fails because the service credentials can't be found.

ibmcloud ks cluster service unbind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service SERVICE_INSTANCE [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service and Developer Cloud Foundry role

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-n, --namespace KUBERNETES_NAMESPACE
: Required: The name of the Kubernetes namespace.

--service SERVICE_INSTANCE
When you update the major or minor Kubernetes version of your cluster, IBM automatically makes necessary changes to the Ingress deployment, but does not change the image version of your Ingress ALB add-on. You are responsible for checking the compatibility of the latest Kubernetes versions and your Ingress ALB add-on images.

ibmcloud ks ingress alb autoupdate disable --cluster CLUSTER [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-q
: Optional: Do not show the message of the day or update reminders.



 Example ingress alb autoupdate disable command 

ibmcloud ks ingress alb autoupdate disable --cluster mycluster







 ibmcloud ks ingress alb autoupdate enable 

Virtual Private Cloud

Classic infrastructure

Enable automatic updates of all Ingress ALB pods in a cluster.

If automatic updates for the Ingress ALB add-on are disabled, you can re-enable automatic updates. Whenever the next image version becomes available, the ALBs are automatically updated to the latest build.

ibmcloud ks ingress alb autoupdate enable --cluster CLUSTER [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-q
: Optional: Do not show the message of the day or update reminders.





 ibmcloud ks ingress alb autoupdate get 

Virtual Private Cloud

Classic infrastructure

Check whether automatic updates for the Ingress ALB add-on are enabled and whether your ALBs are updated to the latest image version.

ibmcloud ks ingress alb autoupdate get --cluster CLUSTER [--output json] [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
IAM service access roles 

Every user who is assigned an IBM Cloud IAM service access role is also automatically assigned a corresponding Kubernetes role-based access control (RBAC) role in a specific namespace. To assign service access roles, see [Granting users access to your cluster through IBM Cloud IAM](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms). Do not assign IBM Cloud IAM platform access roles at the same time as a service access role. You must assign platform and service access roles separately.

Looking for which Kubernetes actions each service access role grants through RBAC? See [Kubernetes resource permissions per RBAC role](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-rolesrbac_ref). To learn more about RBAC roles, see [Assigning RBAC permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewrole-binding) and [Extending existing permissions by aggregating cluster roles](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac_aggregate). For the username details, see [IBM Cloud IAM issuer details for RBAC users](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-rolesiam-issuer-users).

See the IAM Policy Management [API reference](https://cloud.ibm.com/apidocs/iam-policy-managementlist-roles) for more information on managing IAM roles with the API.



 Kubernetes Service 

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 containers-kubernetes for the service name.

Platform roles

Service roles

Actions



Table 25. Platform roles - Kubernetes Service
Use the tab buttons to change the context of the table. This table has row and column headers.
IBM Cloud Object Storage event source controller Manage the lifecycle of event subscriptions from the IBM Cloud Object Storage service. 
 Cluster node autoscaler Scales the shard by adding and removing worker nodes based on capacity demand. 
 IBM Cloud Monitoring Sends service metrics to IBM Cloud Monitoring. For more information about these metrics, see [Monitoring for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-monitor). 
 IBM® Log Analysis Forward platform logs and metrics to IBM Log Analysis. For more information, see [Auditing events for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-at_events). 





 Code Engine workload isolation 

Code Engine is a multi-tenant, regional service where tenants share the same network and compute infrastructure. In particular, the network and compute infrastructure are shared resources and some management components are common to all tenants. Code Engine implements the following controls to separate tenants:



* Code Engine project resources are separated within a secured Kubernetes environment that is running in an IBM Cloud multi-zone region.
* Code Engine projects and its containing resources, such as application, builds, and jobs that run on shared clusters that use shared management components.
* To separate the access to project resources, Code Engine performs several levels of authentication and authorization checks within the apiserver and kube-api-proxy components (see previous table),



* IAM authentication and access policies checks are performed on a project level.
* To manage multi-tenant access to the underlying Kubernetes API, direct access to the API server is not allowed. Instead, use the Code Engine custom Kube-api-proxy API for access.
* Role-based access control checks are performed on a resource level to allow only authorized users to perform certain operations on project resources.



* The authorization is controlled by the customer by assigning manager, reader, or writer roles to users for a Code Engine project resource within IAM.
* To restrict customer workload, Code Engine enforces the following concepts,



* Container isolation through various Linux isolation techniques. These techniques ensure multiple layers of security to prevent the privilege escalation of containers and to restrict containers to use a limited set of system privileges.
ibmcloud oc ingress alb update -c mycluster --version 1.1.2_2507_iks --alb public-crdf253b6025d64944ab99ed63bb4567b6-alb1







 ibmcloud oc ingress alb versions 

Virtual Private Cloud

Classic infrastructure

View the available images and image versions for Ingress ALBs in your cluster.

Red Hat OpenShift on IBM Cloud supports two types of NGINX Ingress controller images for the ALB: the Red Hat OpenShift on IBM Cloud Ingress image, and the Kubernetes Ingress image. The latest three version of each image type are supported for ALBs.



* The Red Hat OpenShift on IBM Cloud Ingress image is a custom implementation that is built on the NGINX Ingress controller.
* The Kubernetes Ingress image is built on the community Kubernetes project's implementation of the NGINX Ingress controller.



ibmcloud oc ingress alb versions [--output json] [-q]

Minimum required permissions
: Viewer platform access role for IBM Cloud Kubernetes Service

Command options:

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.





 ibmcloud oc ingress domain create 

Create an Ingress domain for a cluster.

ibmcloud oc ingress domain create --cluster CLUSTER [--crn CRN] [--default] [--domain DOMAIN] [--hostname HOSTNAME] [--ip IP] [--output OUTPUT] [--domain-provider PROVIDER] [-q] [--secret-namespace NAMESPACE] [--domain-zone ZONE]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where you want to create the domain.

--crn CRN
: Required for IBM Cloud Internet Services domains.