vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Kubernetes version 1.27 change log 

View information about version changes for major, minor, and patch updates that are available for your IBM Cloud® Kubernetes Service clusters that run version 1.27. Changes include updates to Kubernetes and IBM Cloud Provider components.



 Overview 

In clusters that run version 1.23 or earlier, the IBM Cloud provider version enables Kubernetes APIs and features that are at beta. In version 1.24 and later, most new beta features are disabled by default. Kubernetes alpha features, which are subject to change, are disabled in all versions. For more information, see the [Default service settings for Kubernetes components](https://cloud.ibm.com/docs/containers?topic=containers-service-settings) and the [feature gates](https://cloud.ibm.com/docs/containers?topic=containers-service-settingsfeature-gates) for each version.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes.
Kubernetes version 1.24 change log 

View information about version changes for major, minor, and patch updates that are available for your IBM Cloud® Kubernetes Service clusters that run version 1.24. Changes include updates to Kubernetes and IBM Cloud Provider components.



 Overview 

In clusters that run version 1.23 or earlier, the IBM Cloud provider version enables Kubernetes APIs and features that are at beta. In version 1.24 and later, most new beta features are disabled by default. Kubernetes alpha features, which are subject to change, are disabled in all versions. For more information, see the [Default service settings for Kubernetes components](https://cloud.ibm.com/docs/containers?topic=containers-service-settings) and the [feature gates](https://cloud.ibm.com/docs/containers?topic=containers-service-settingsfeature-gates) for each version.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes.
Kubernetes version 1.25 change log 

View information about version changes for major, minor, and patch updates that are available for your IBM Cloud® Kubernetes Service clusters that run version 1.25. Changes include updates to Kubernetes and IBM Cloud Provider components.



 Overview 

In clusters that run version 1.23 or earlier, the IBM Cloud provider version enables Kubernetes APIs and features that are at beta. In version 1.24 and later, most new beta features are disabled by default. Kubernetes alpha features, which are subject to change, are disabled in all versions. For more information, see the [Default service settings for Kubernetes components](https://cloud.ibm.com/docs/containers?topic=containers-service-settings) and the [feature gates](https://cloud.ibm.com/docs/containers?topic=containers-service-settingsfeature-gates) for each version.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes.
The CI toolchain implements the following best practices:



* Runs a static code scanner on the infrastructure code repositories and performs Terraform linting checks on the Infrastructure code.
* Runs compliance checks on the infrastructure code to detect secrets and security vulnerabilities.
* Builds artifacts on every Git commit.
* Stores the built artifacts metadata in inventory repository.
* Automatically builds and validates any code that is merged into the target Git repository branch.



Zoom

![DevSecOps IaC Continuous Integration toolchain](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-ci-terraform-toolchain-diagram.png)

Figure 1. DevSecOps Continuous Integration toolchain





 Guided setup overview for the CI toolchain 

The Continuous Delivery service provides templates to guide you through the toolchain setup process in a logical order, presenting you with the recommended configuration options that you need to create your toolchain.

A progress indicator shows the steps to complete the configuration. Use the progress indicator to navigate to previous steps. The configuration options for the current step are displayed in the main area of the page.

Zoom

![DevSecOps IaC Continuous Integration toolchain welcome page](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-ci-terraform-welcome-page.png)

Figure 2. DevSecOps Continuous Integration toolchain welcome page

To advance to the next step, click Start. You can advance to the next step only when the configuration for the current step is complete and valid. Navigate to the previous step by clicking Back.

Some steps include a Switch to advanced configuration toggle. These steps by default present you with the minimum recommended configuration needed.
Ingress ALB and Fluentd version change log 

Your IBM Cloud® Kubernetes Service cluster comes with components, such as the Fluentd and Ingress ALB components, that are updated automatically by IBM. You can also disable automatic updates for some components and manually update them separately from the master and worker nodes. Refer to the tables in the following sections for a summary of changes for each version.

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM Security Bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

For more information about managing updates for Fluentd and Ingress ALBs, see [Updating cluster components](https://cloud.ibm.com/docs/containers?topic=containers-updatecomponents).



 Kubernetes Ingress image change log 

View version changes for Ingress application load balancers (ALBs) that run the [community Kubernetes Ingress image](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about).

When you create a new ALB, enable an ALB that was previously disabled, or manually update an ALB, you can specify an image version for your ALB in the --version option. The latest three versions of the Kubernetes Ingress image are supported for ALBs. To list the currently supported versions, run the following command:

ibmcloud ks ingress alb versions

The Kubernetes Ingress version follows the format <community_version>_<ibm_build>_iks.
It is recommended to use the Terraform provider plug-ins for Kubernetes. 
 OpenShift client Yes Red Hat OpenShift CLI for your Terraform automation. It is recommended to use the Terraform provider plug-ins for IBM Cloud and Kubernetes. 
 Python v3.6 No For use in your Terraform automation. 
 Python libraries netaddr No Red Hat OpenShift CLI for your Terraform automation. It is recommended to use the Terraform provider plug-ins for IBM Cloud and Kubernetes. 







 Runtime-ansible-job image 

The Schematics Actions use the Ansible v2.9.27 in the Ansible-runtime-job image. The current minor version of the Ansible CLI is used in the Schematics.



Schematics runtime ansible job image

 Software Versions In agent Description 

 Ansible v2.9.27 v2.9.27 Ansible CLI 
 IBM Cloud CLI Latest Latest Latest version of the IBM Cloud CLI plug-ins are pre-installed, to use in your Ansible automation. 
 JQ v1.6 v1.6 As the [JSON processor](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorialsgetting-started-macos_jq) in your Ansible automation. 
 Kubectl client Latest Yes For use in your Ansible automation. 
 OpenShift client Latest Yes Red Hat OpenShift CLI for your Ansible automation. 
 Python v3.8 v3.8 For use in your Ansible automation. 
 Python libraries netaddr, <br>kubernetes, <br>openshift, <br>pywinrm, <br>boto3, <br>boto, <br>botocore, <br>PyVmomi No For use in your Ansible automation.
It is a security best practice to replace user-facing certificates with certificates that are signed by a third-party or enterprise certificate authority (CA). Certificates for machine-to-machine communication can remain as VMCA–signed certificates. However, it is recommended that you follow best practices for your organization, which typically involve the use of an identified enterprise CA.

You can use the Windows AD servers within this design to create certificates that are signed by the local instance. However, you can also choose to configure CA services if needed.





 Related links 



* [Physical infrastructure design](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-design_physicalinfrastructure)
* [Virtual infrastructure design](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-design_virtualinfrastructure)
* Delete the Slack app.







 Expand the Tutorial 

Do you want to learn more? Here are some ideas of what you can do next:



* [Analyze logs and monitor application health](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-application-log-analysisapplication-log-analysis).
* Add a 3rd environment dedicated to testing.







 Related Content 



* End to end Kubernetes solution guide, [moving VM based apps to Kubernetes](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vm-to-containers-and-kubernetesvm-to-containers-and-kubernetes).
* [Security](https://cloud.ibm.com/docs/containers?topic=containers-security) for IBM Cloud Kubernetes Service.
* Toolchain [integrations](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-integrationsintegrations).
* Analyze logs and monitor [application health](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-application-log-analysisapplication-log-analysis).
20 April 2023 

Updates to the IBM Cloud for Financial Services profile
: Version 1.2.0 of the IBM Cloud for Financial Services profile are now available. For more information, see the [Change log](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-fs-change-log).





 17 April 2023 

Updates to the IBM Cloud Security Best Practices library and profile
: Updates to version 1.1.0 of the IBM Cloud Security Best Practices library and profile are now available. For more information, see the [Change log](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-ibm-sec-best-practices-change-log).





 10 April 2023 

Customize notifications per attachment
: As part of creating an attachment, you can now configure notifications by attachment. You can set a customized failure threshold or select specific controls that you want to be alerted for. By default, when notifications are enabled for your account, you are notified if 15% of the controls in a single scan fail. To adjust this you can adjust the threshold or you can turn off notifications as you create an attachment.

If you already have notifications configured they were migrated to the new format. To update your notification settings, you can do so in the settings of each attachment.





 31 March 2023 

deprecated

Collector-based architecture
: Starting 30 June 2023 Security and Compliance Center will be a provision-able, regional service offering in the IBM Cloud catalog. As this change is made, support for the collector-based architecture (v1) that currently resides in the Hybrid Cloud section of the UI will be removed. If you are exclusively evaluating IBM Cloud resources, you can start migrating at any time to the improved user experience by creating an attachment. If you are working using a collector to evaluate a hybrid cloud scenario, additional information will be available about your migration plan soon.





 13 March 2023 

New version of the IBM Cloud Security Best Practices library
: Version 1.1.0 of the IBM Cloud Security Best Practices library and profile are now available.
How IBM Cloud ensures high availability and disaster recovery 

Your global strategy is important, and IBM Cloud® uses global load balancing to ensure a redundant, highly available platform is available for you to host your workloads and applications.



 High availability for the platform 

The IBM Cloud console is available globally and load balanced from a single URL. It is highly available and continues to run even if your resources are unavailable.

Other platform services, including catalogs, global search and tagging, identity and access management, and account management are also globally available and load balanced across multiple regions. A failover design is in place to keep your resources up and running without you having to take action.

Each platform service is categorized as a general availability service with a [Service Level Agreement](https://cloud.ibm.com/docs/overview?topic=overview-slas) of 99.99% availability. While each platform service might be available from various regions, each region in which the service is deployed has multiple data centers for redundancy.



Table 1. Platform services

 Platform service Details 

 Account management [Best practices for setting up your account](https://cloud.ibm.com/docs/account?topic=account-account_setup) and [Best practices for billing and usage](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-best-practices) 
 Catalogs [Managing catalog settings](https://cloud.ibm.com/docs/account?topic=account-filter-account) 
 Cloud Shell [Understanding high availability and disaster recovery for Cloud Shell](https://cloud.ibm.com/docs/cloud-shell?topic=cloud-shell-ha-dr) 
 Console [Navigating the console](https://cloud.ibm.com/docs/overview?topic=overview-ui) 
 Global search and tagging [Searching for resources](https://cloud.ibm.com/docs/account?topic=account-searching-for-resources) and [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag) 
 IAM [What is IBM Cloud Identity and Access Management?]
Prepare your IBM Cloud account 



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/kubernetes-on-vpc/images/prepare-account/journey-map.png)





 Setup Resource Group 

Resource Groups allow you to organize the resources/instances into groups (i.e. ProjectA_Resources, ProjectB_Resources, Dev_Env, Prod_Env, etc.), and can be used as part of the access management strategy (i.e. Developers granted access to resources in Dev_Env resourcce group but no access to Prod_env). When a IBM Cloud Kubernetes Service is provisioned, it must be placed within a resource group. Please refer to the follow assets to understand the best practices for using resource groups:



* [Best practices for resource groups and assigning access](https://cloud.ibm.com/docs/account?topic=account-account_setup)







 User access permissions 

When you assign cluster permissions, it can be hard to judge which role you need to assign to a user. Use the tables in the following links to determine the minimum level of permissions that are required to perform common tasks in IBM Cloud Kubernetes Service.



* [Permissions to create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_referencecluster_create_permissions)
* [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceiam_platform)
* [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceservice)
* [Kubernetes resource permissions per RBAC role](https://cloud.ibm.com/docs/containers?topic=containers-access_referencerbac_ref)
Part 1: Set up prerequisites 

This tutorial is part 1 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 1 of this tutorial series, you review some background information and set up prerequisites.



 Before you begin 

See the following documentation to get more information about DevSecOps and its implementation in Continuous Delivery:



* [What is DevSecOps](https://www.ibm.com/cloud/learn/devsecops)
* [DevSecOps architecture](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-arch)
* [DevSecOps with Continuous Delivery](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops_intro)
* [Understanding DevSecOps pipelines](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-pipelines)







 Step 1: Set up an IBM Cloud account 

Set up an [IBM Cloud account](https://cloud.ibm.com/registration). Depending on your IBM Cloud account type, access to certain resources might be limited. Depending on your account plan limits, certain capabilities that are required by some DevSecOps toolchains might not be available. For more information, see [Setting up your IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-account-getting-started) and [Upgrading your account](https://cloud.ibm.com/docs/account?topic=account-upgrading-account).





 Step 2: Store secrets values in a secrets management vault 

Ensure that all of the secret values that you need are stored in a secrets management vault.
Prepare your IBM Cloud account 



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/roks-on-vpc/images/prepare-account/journey-map.png)





 Setup Resource Group 

Resource Groups allow you to organize the resources/instances into groups (i.e. ProjectA_Resources, ProjectB_Resources, Dev_Env, Prod_Env, etc.), and can be used as part of the access management strategy (i.e. Developers granted access to resources in Dev_Env resourcce group but no access to Prod_env). When a IBM Cloud Kubernetes Service is provisioned, it must be placed within a resource group. Please refer to the follow assets to understand the best practices for using resource groups:



* [Best practices for resource groups and assigning access](https://cloud.ibm.com/docs/account?topic=account-account_setup)







 User access permissions 

When you assign cluster permissions, it can be hard to judge which role you need to assign to a user. Use the tables in the following links to determine the minimum level of permissions that are required to perform common tasks in IBM Cloud Kubernetes Service.



* [Permissions to create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_referencecluster_create_permissions)
* [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceiam_platform)
* [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceservice)
* [Kubernetes resource permissions per RBAC role](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference&interface=uirbac_ref)
Database design best practices 

IBM® Db2® Warehouse on Cloud is a managed cloud data warehouse service that is preconfigured for optimal performance. The following section provides best practices for Db2 Warehouse on Cloud database design.



 Design tips 



* In Db2 Warehouse on Cloud, all tables are column organized by default for optimal performance on analytical workloads. While you can create row-organized tables, it is strongly recommended that you create all tables as column organized for good performance on analytical queries.
* As a SaaS offering, Db2 Warehouse on Cloud automatically manages table spaces, buffer pools, and database partition groups to ensure optimal performance. When you create your Db2 Warehouse on Cloud instance, you'll find the following database objects created by default:



* One regular table space: USERSPACE1 (32K page size)
* One temporary table space: TEMPSPACE1 (32K page size)
* One buffer pool: IBMDEFAULTBP (32K page size)
* One database partition group: IBMDEFAULTGROUP



It is strongly recommended to not create additional table spaces, temporary table spaces, buffer pools, or database partition groups.
* If you’re using any one of the Db2 Warehouse on Cloud [multi-partitioned plans](https://cloud.ibm.com/docs/Db2whc?topic=Db2whc-aboutplans_cfgs), you can optimize performance by defining a good set of table distribution keys. A good distribution key distributes data evenly across database partitions so that all of your database partitions can help process data for your queries. A poorly-chosen distribution key results in data skew. This means that data is stored unevenly across database partitions such that only a subset of data partitions participate in the processing while the rest remain idle. For more information about distribution keys, see [Distribution keys for multi-partitioned plans](https://cloud.ibm.com/docs/Db2whc?topic=Db2whc-distribution_keys).

If you’re using a single-partitioned plan, there’s no need to worry about distribution keys because all of the data is stored on one data partition.