vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Release timeline for IBM Cloud Kubernetes Service version 1.19

 Version Supported? IBM Cloud Kubernetes Service <br>release date IBM Cloud Kubernetes Service <br>unsupported date 

 1.19 Deprecated 13 Oct 2020 14 Mar 2022 † 







 Preparing to update 

This information summarizes updates that are likely to have and impact on deployed apps when you update a cluster to version 1.19. For a complete list of changes, review the [community Kubernetes change log](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md) and [IBM version change log](https://cloud.ibm.com/docs/containers?topic=containers-changelog_119) for version 1.19. You can also review the [Kubernetes helpful warnings](https://kubernetes.io/blog/2020/09/03/warnings/).



 Update before master 

The following table shows the actions that you must take before you update the Kubernetes master.



Changes to make before you update the master to Kubernetes 1.19

 Type Description 

 Calico data store driver change When you update your cluster to version 1.19, Calico is updated to use the Kubernetes data store driver (KDD). During the update, you can request resources that require Calico, such as pods that are subject to Calico policies, but the resources remain pending until the update is complete.<br><br><br><br> * Before the update, you must delete any NetworkPolicy resources that are scoped to namespaces that no longer exist. When you delete a namespace, Kubernetes cleans up all resources that are associated with that namespace. However, resources that you created for Calico by using the calicoctl CLI, such as NetworkPolicy resources that you scoped to that namespace, are not cleaned up and remain in your cluster even after the namespace is deleted.
Review the changes that are in version 1.0.2 of the managed cluster autoscaler add-on.



 Change log for patch update 1.0.2_267, released 10 May 2021 

Review the changes in version 1.0.2_267 of the cluster autoscaler add-on.



* Image tags: 1.17.4-3, 1.18.3-3, 1.19.1-3, and 1.20.0-3.
* Supported cluster versions: 4.3 - 4.6
* Includes a bug fix for the worker replace command on VPC clusters that caused worker creation to fail.







 Change log for patch update 1.0.2_256, released 19 April 2021 

Review the changes in version 1.0.2_256 of the cluster autoscaler add-on.



* Image tags: 1.17.4-2, 1.18.3-2, 1.19.1-2, and 1.20.0-2
* Supported cluster versions: 4.3 - 4.6
* Includes fixes for [CVE-2021-27919](https://nvd.nist.gov/vuln/detail/CVE-2021-27919) and [CVE-2021-27918](https://nvd.nist.gov/vuln/detail/CVE-2021-27918).







 Change log for patch update 1.0.2_249, released 01 April 2021 

Review the changes in version 1.0.2_249 of the cluster autoscaler add-on.



* Image tags: 1.16.7-1, 1.17.4-1, 1.18.3-1, 1.19.1-1, and 1.20.0-1.
* Supported cluster versions: 4.3 - 4.6
* Includes fixes for [CVE-2021-3114](https://nvd.nist.gov/vuln/detail/CVE-2021-3114) and [CVE-2021-3115](https://nvd.nist.gov/vuln/detail/CVE-2021-3114).
* Removes the init container.
ibmcloud ks worker reload --cluster CLUSTER --worker WORKER_ID [--skip-master-healthcheck] [-f] [-q]

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

Command options:

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

-w, --worker WORKER
: Specify a worker node ID. To reload multiple worker nodes, use multiple options, such as -w worker1_id -w worker2_id.

--skip-master-healthcheck
: Skip a health check of your master before reloading or rebooting your worker nodes.

-f
: Optional: Force the command to run with no user prompts.

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



 Example worker reload command 

ibmcloud ks worker reload --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2







 ibmcloud ks worker replace 

Virtual Private Cloud

Classic infrastructure

Delete a worker node and replace it with a new worker node in the same worker pool.

The replacement worker node is created in the same zone and has the same flavor as the old worker node, but might be assigned new public or private IP addresses. You might replace a worker node if you can't reload or update the worker node, such as if it enters a troubled state.

You can also use this command to update the Kubernetes version of the worker node to match the major and minor version of the Kubernetes master by including the --update option. If you don't include the --update option, patch version updates are applied to your worker node, but not major or minor updates.
1. [Disable the public cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_clusterdisable-public-se).
2. [Set up access to the master on the private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_private_se).









 Setting up the public cloud service endpoint 

Enable or disable the public cloud service endpoint for your cluster.

The public cloud service endpoint makes your Kubernetes master publicly accessible. Your worker nodes and your authorized cluster users can securely communicate with the Kubernetes master over the public network. For more information, see [Worker-to-master and user-to-master communication](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsinternet-facing).



 Steps to enable the public cloud service endpoint 

If you previously disabled the public endpoint, you can re-enable it.



1. Enable the public cloud service endpoint.

ibmcloud ks cluster master public-service-endpoint enable --cluster <cluster_name_or_ID>
2. Refresh the Kubernetes master API server to use the public cloud service endpoint. You can follow the prompt in the CLI, or manually run the following command. It might take several minutes for the master to refresh.

ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
3. [Create a configmap](https://cloud.ibm.com/docs/containers?topic=containers-updateworker-up-configmap) to control the maximum number of worker nodes that can be unavailable at a time in your cluster. When you update your worker nodes, the ConfigMap helps prevent downtime for your apps as the apps are rescheduled orderly onto available worker nodes.
4. Update all the worker nodes in your cluster to remove the public cloud service endpoint configuration.
Change log for master fix pack 1.22.3_1529, released 17 November 2021 

The following table shows the changes that are in the master fix pack update 1.22.3_1529. Master patch updates are applied automatically.



Changes since version 1.22.2_1526

 Component Previous Current Description 

 Cluster health image v1.2.16 v1.2.18 Updated Go module dependencies and to use Go version 1.16.9. Updated image for [CVE-2021-22946](https://nvd.nist.gov/vuln/detail/CVE-2021-22946), [CVE-2021-22947](https://nvd.nist.gov/vuln/detail/CVE-2021-22947), [CVE-2021-33928](https://nvd.nist.gov/vuln/detail/CVE-2021-33928), [CVE-2021-33929](https://nvd.nist.gov/vuln/detail/CVE-2021-33929) and [CVE-2021-33930](https://nvd.nist.gov/vuln/detail/CVE-2021-33930). 
 etcd v3.4.17 v3.4.18 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.18). 
 Gateway-enabled cluster controller 1510 1567 Updated to use Go version 1.16.9.
* [Updating the IBM Cloud CLI](https://cloud.ibm.com/docs/containers?topic=containers-cli-updatecli-update-include-update-ibmcloud-cli)
* [Updating installed plug-ins](https://cloud.ibm.com/docs/containers?topic=containers-cli-updatecli-update-include-cli-update-plugin)



[Setting up the API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installcs_api_install)



* [About the API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installapi_about)
* [Automating cluster deployments with the API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installcs_api)
* [Working with your cluster by using the Kubernetes API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installkube_api)
* [Refreshing IAM access tokens and obtaining new refresh tokens with the API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installcs_api_refresh)
* [Refreshing IBM Cloud IAM access tokens and obtaining new refresh tokens with the CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installcs_cli_refresh)



[Uninstalling the stand-alone IBM Cloud CLI](https://cloud.ibm.com/docs/containers?topic=containers-uninstall-ibmcloud-cliuninstall-ibmcloud-cli)



* [Uninstalling on Windows](https://cloud.ibm.com/docs/containers?topic=containers-uninstall-ibmcloud-cliuninstall-cli-windows)
* [Updating your Satellite Config configuration](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-manage-direct-uploadsatcon-manage-update)



* [Updating your Satellite Config from the console](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-manage-direct-uploadsatcon-manage-update-console)
* [(TO UPDATE WITH NEW COMMANDS:) Updating your Satellite Config with the CLI](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-manage-direct-uploadsatcon-manage-update-cli)





[Removing Satellite Config from your cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-remove-satconfigremove-satconfig)

[Reviewing resources that are managed by Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-resourcessatcon-resources)



* [Enabling Watch-keeper collection methods](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-resourcessatconfig-enable-watchkeeper)



* [Watch all the resources that my Satellite subscription creates](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-resourcessatconfig-enable-watchkeeper-all)
* [Watch a particular resource in my Satellite Config version](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-resourcessatconfig-enable-watchkeeper-specific)
* [Watch a particular resource that I label in my cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-resourcessatconfig-enable-watchkeeper-label)



* [Review the resources from Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-resourcessatconfig-review-resources)
CIS Kubernetes Benchmark 

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations.

When a new [Kubernetes version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions) is released, IBM engineers compare the default configuration of a cluster that runs that Kubernetes version against the benchmark and publishes the results in this documentation. You can review how specific versions of your IBM Cloud® Kubernetes Service clusters meet the CIS Kubernetes Benchmark.



 Available benchmark versions 

Use the list to find CIS Kubernetes Benchmark results for available versions.



* [Version 1.27](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-127)
* [Version 1.26](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-126)
* [Version 1.25](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-125)
* [Version 1.24](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-124)
* [Version 1.23](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-123)







 Using the benchmark 

As a security administrator or auditor, you might want to compare your company's internal standards and external regulatory requirements with the CIS Kubernetes Benchmark. The benchmark recommendations are provided by the Center for Internet Security, not by IBM. IBM might not configure default settings in a way that meets every recommendation, but documents whether the recommendation is met to help you in your review. For example, you might use the benchmark in an audit to confirm that basic security measures are in place, and to identify areas where you might enhance your security.
Version 1.21 CIS Kubernetes benchmark 

Kubernetes version 1.21 becomes unsupported on 14 September 2022. Update your cluster to at least [version 1.22](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions_122) as soon as possible.

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations. This document contains the results of the version 1.5 CIS Kubernetes benchmark for clusters that run Kubernetes version 1.21. For more information or help understanding the benchmark, see [Using the benchmark](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark).



 1 Master node security configuration 

Review the Master node security configuration results of the version 1.5 CIS Kubernetes benchmark.



 1.1 Master node configuration files 



Section 1.1 Master node benchmark results

 Section Recommendation Scored/Not Scored Level Result Responsibility 

 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.2 Ensure that the API server pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM
Version 1.26 CIS Kubernetes benchmark 

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations. This document contains the results of the version 1.5 CIS Kubernetes benchmark for clusters that run Kubernetes version 1.26. For more information or help understanding the benchmark, see [Using the benchmark](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark).



 1 Master node security configuration 

Review the Master node security configuration results of the version 1.5 CIS Kubernetes benchmark.



 1.1 Master node configuration files 



Section 1.1 Master node benchmark results

 Section Recommendation Scored? Level Result Responsibility 

 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive Scored 1 Pass IBM 
 1.1.2 Ensure that the API server pod specification file ownership is set to root:root Scored 1 Pass IBM 
 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive Scored 1 Pass IBM 
 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root Scored 1 Pass IBM 
 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive Scored 1 Pass IBM 
 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root Scored 1 Pass IBM 
 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive Scored 1 Pass IBM 
 1.1.8 Ensure that the etcd pod specification file ownership is set to root:root Scored 1 Pass IBM 
 1.1.9 Ensure that the Container Network Interface file permissions are set to 644 or more restrictive Not Scored 1 Pass IBM 
 1.1.10 Ensure that the Container Network Interface file ownership is set to root:root Not Scored 1 Pass IBM
Version 1.19 CIS Kubernetes benchmark 

Kubernetes version 1.19 is unsupported.

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations. This document contains the results of the version 1.5 CIS Kubernetes benchmark for clusters that run Kubernetes version 1.19. For more information or help understanding the benchmark, see [Using the benchmark](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark).



 1 Master node security configuration 

Review the Master node security configuration results of the version 1.5 CIS Kubernetes benchmark.



 1.1 Master node configuration files 



Section 1.1 Master node benchmark results

 Section Recommendation Scored/Not Scored Level Result Responsibility 

 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive Scored 1 Pass IBM 
 1.1.2 Ensure that the API server pod specification file ownership is set to root:root Scored 1 Pass IBM 
 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive Scored 1 Pass IBM 
 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.8 Ensure that the etcd pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.9 Ensure that the Container Network Interface file permissions are set to 644 or more restrictive. Not Scored 1 Pass IBM
CIS Kubernetes Benchmark 

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations.

When a new Kubernetes version is released as part of a [supported Red Hat OpenShift version](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions), IBM engineers compare the default configuration of a cluster that runs that Kubernetes version against the benchmark and publishes the results in this documentation. You can review how specific versions of your Red Hat® OpenShift® on IBM Cloud® clusters meet the CIS Kubernetes Benchmark.



 Available benchmark versions 

Use the list to find CIS Kubernetes Benchmark results for available versions.



* [Version 4.12](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-412)
* [Version 4.11](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-411)
* [Version 4.10](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-410)
* [Version 4.9](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-49)
* [Version 4.8](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-48)







 Using the benchmark 

As a security administrator or auditor, you might want to compare your company's internal standards and external regulatory requirements with the CIS Kubernetes Benchmark. The benchmark recommendations are provided by the Center for Internet Security, not by IBM.
Version 1.24 CIS Kubernetes benchmark 

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations. This document contains the results of the version 1.5 CIS Kubernetes benchmark for clusters that run Kubernetes version 1.24. For more information or help understanding the benchmark, see [Using the benchmark](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark).



 1 Master node security configuration 

Review the Master node security configuration results of the version 1.5 CIS Kubernetes benchmark.



 1.1 Master node configuration files 



Section 1.1 Master node benchmark results

 Section Recommendation Scored? Level Result Responsibility 

 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.2 Ensure that the API server pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.8 Ensure that the etcd pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.9 Ensure that the Container Network Interface file permissions are set to 644 or more restrictive. Not Scored 1 Pass IBM
Version 1.23 CIS Kubernetes benchmark 

The Center for Internet Security (CIS) publishes the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as a framework of specific steps to configure Kubernetes more securely and with standards that are commensurate to various industry regulations. This document contains the results of the version 1.5 CIS Kubernetes benchmark for clusters that run Kubernetes version 1.23. For more information or help understanding the benchmark, see [Using the benchmark](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark).



 1 Master node security configuration 

Review the master node security configuration results of the version 1.5 CIS Kubernetes benchmark.



 1.1 Master node configuration files 



Section 1.1 Master node benchmark results

 Section Recommendation Scored/Not Scored Level Result Responsibility 

 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.2 Ensure that the API server pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive. Scored 1 Pass IBM 
 1.1.8 Ensure that the etcd pod specification file ownership is set to root:root. Scored 1 Pass IBM 
 1.1.9 Ensure that the Container Network Interface file permissions are set to 644 or more restrictive. Not Scored 1 Pass IBM