Release v2.1.6

    For a more detailed explanation of the CVEs and how we’ve addressed them, you can read our blog article.

    With this release, the following are now latest and stable:

    The known issues for this release remain unchanged from v2.1.5: Clusters created through Rancher can sometimes get stuck in provisioning [#15970] [] [#15695] The upgrade for Rancher node-agent daemonset can sometimes get stuck due to pod removal failure on a Kubernetes side []

    • Addressed CVE-2018-20321 that allowed users in the Default project of a cluster to escalate privileges to that of a cluster admin through a service account. [#17725]
    • rancher/rancher:v2.1.6
    • rancher/rancher-agent:v2.1.6

    Because the fix for CVE-2018-20321 involves a data migration (deleting a service account and creating it elsewhere), rolling Rancher back from v2.1.6 to a version prior to the patch is more complicated than usual. We have documented the extra steps . Review these steps prior to upgrading so that you understand their implications.

    The following information regarding upgrades and rollbacks remains unchanged from v2.1.5:

    Rancher supports both upgrade and rollback starting with v2.0.2. Please note the version you would like to upgrade or to change the Rancher version.

    If you are currently using the RKE add-on install method, see Migrating from a RKE add-on install for details on how to move to using a helm chart.

    Any upgrade from a version prior to v2.0.3, when scaling up workloads, new pods will be created [] - In order to update scheduling rules for workloads [#13527], a new field was added to all workloads on , which will cause any pods in workloads from previous versions to re-create.

    Note: When rolling back, we are expecting you to rollback to the state at the time of your upgrade. Any changes post upgrade would not be reflected. In the case of rolling back using a , you must specify the exact version you want to change the Rancher version to, rather than using the default tag.