VMware PKS upgrade approach for CRITICAL CVE : 2019-3779
search cancel

VMware PKS upgrade approach for CRITICAL CVE : 2019-3779

book

Article ID: 345564

calendar_today

Updated On:

Products

VMware Cloud PKS

Issue/Introduction

VMware PKS versions 1.3.1 and earlier are effected by Common Vulnerabilites and Exposure (CVE) 2019-3779. PKS is addressing this issue by providing a series of patch releases that will update all Certificate Authority (CA) certificates for v1.2.X and 1.3.X.  This article describes the CVE and the process for upgrading your PKS installation.

This article describes the CVE and the process for upgrading your VMware PKS installation.


Cause:

PKS deployed Kubernetes clusters, created in VMware PKS versions prior to v1.3.1, trust the same CA used by the Kubernetes API to sign and trust certs for Etcd.

This could allow a user authenticated with a cluster to request a signed certificate leveraging the Kubernetes CSR capability to obtain a credential that could allow privileged access to Etcd.


Environment

VMware PKS 1.x

Resolution

To prevent this scenario, it is recommended to provision Kubernetes clusters with a dedicated CA for Etcd certificate trust chain.

PKS v1.3.2 and v1.2.9 implements this recommendation by default.

In order to replace the Etcd CA and reduce the impact to running workloads on clusters provisioned by previous versions of PKS, environments being upgraded must execute the following three phase sequence and upgrade all errands during each phase.

Phase I. Introduce a dedicated Etcd CA during new cluster creations or cluster upgrades. Clusters will trust both the new CA and the existing Kubernetes API CA.

Phase II. Regenerate Etcd Certificates signed by the new Etcd CA during new cluster creations or cluster upgrades. Clusters will trust both the new CA and the existing Kubernetes API CA.

Phase III. Remove the trust designation for the existing Kubernetes API CA during new cluster creations or cluster upgrades.


 


NOTE:  These Phases MUST be accomplished in succession in order to reduce the impact to deployed clusters with workloads and to address the CVE.  The image above depicts valid upgrade paths to ensure the CVE is addressed and the risk to running workloads is red.  


Important upgrade notes:

  • The image above depicts valid upgrade paths to ensure the CVE is appropriately addressed and the risk to running workloads is reduced.

  • It is STRONGLY recommended to upgrade to PKS v1.2.9 or PKS v1.3.2  to resolve this CVE.

  • Regardless of branch version, these Phases MUST be accomplished in succession. For example, v1.2.8 must be upgraded to v1.2.9 or v1.3.2.

  • Upgrading from v1.3.0 to v1.3.2 is not supported, v1.3.0 has been removed from download access.

  • You can choose to upgrade from 1.2.x to 1.3.x builds as long as PHASE order is maintained. For example, upgrading from v1.2.7 to v1.3.1 to v1.3.2. Doing so will help to ensure that the CVE is addressed and reduce impact to running workloads.

  • The CVE will be fully addressed only when all 3 phases have been applied in sequence.

  • Choosing to perform new installs directly with a phase II build still requires you to upgrade to a phase III build. For example, a new install with v1.3.1 must upgrade to v1.3.2.

  • You can choose to perform a new install directly to a phase III build or newer to address this CVE. For example, a new Install with v1.2.9 or v1.3.2 or greater is OK.

  • If you wish to remain on v1.2.x builds, you must start the upgrade path from v1.2.5 through v1.2.7, and complete phases II & III appropriately.

Additional Information

https://community.pivotal.io/s/article/pks-upgrade-approach-for-critical-cve

Powered by Wolken Software