1. Overview

You can upgrade Prisma Cloud without losing any of your data or configurations. Upgrade Console first. After upgrading Console, upgrade your Defenders, and other Prisma Cloud components.

Before upgrading, check the Breaking changes section in the release notes to see if there are any special instructions or requirements.

You can upgrade from an immediate previous major version only. If your installation is more than one major release behind, you must upgrade in steps. For example, you cannot directly upgrade from version 19.11 to 20.09. You must upgrade from version 19.11 to 20.04, and then from 20.04 to 20.09.

Console notifies you when new versions of Prisma Cloud are available. Notifications are displayed in the top right corner of the dashboard.

update bell

When you upgrade Console, the old Console container is completely replaced with a new container. Because Prisma Cloud stores state information outside of the container, all your rules and settings are immediately available to the upgraded Prisma Cloud containers.

Prisma Cloud state information is stored in a database in the location specified by DATA_FOLDER, which is defined in twistlock.cfg. By default, the database is located in /var/lib/twistlock.

2. Overview of the upgrade process

First upgrade Console. Next, upgrade your Defenders. Finally, upgrade all other Prisma Cloud components, such as the Jenkins plugin. The upgrade process is vastly simplified when automatic Defender upgrades is enabled (it’s enabled by default).

The steps in the upgrade process are:

  1. Upgrade Console.

  2. Upgrade all deployed Defenders.

    • If Defender auto-upgrade is enabled — Console will upgrade deployed Defenders for you. If Console fails to upgrade one or more Defenders, it displays a banner at the top of the UI. If you’ve created an alert for Defender health events, Console emits a message on the alert channel for any Defender it fails to upgrade. Manually upgrade any Defenders that Console could not auto-upgrade.

    • If Defender auto-upgrade is disabled — Manually upgrade all deployed Defenders.

  3. Validate that all deployed Defenders have been upgraded.

    1. Review deployed Defenders and DaemonSets under Manage > Defenders > Manage.

    2. Filter the the Status column by Upgrade.

    3. If any Defenders have the Upgrade status, manually upgrade them.

  4. Manually upgrade all other Prisma Cloud Compute components, such as the Jenkins plugin, so that their versions exactly match Console’s version.

3. Version numbers of installed components

The currently installed version of Console is displayed in the bell menu.

upgrade compute version

The versions of your deployed Defenders are listed under Manage > Defenders > Manage:

upgrade defender version

3.1. Prisma Cloud Compute components

The versions of all deployed components should match exactly. To support the multi-step upgrade process, older versions of Prisma Cloud components can continue to interoperate with newer versions of Console in a limited way. Plan to upgrade all Prisma Cloud components as soon as possible.

After you upgrade Console, upgrade the following components:

  • Defenders. Console can automatically upgrade most Defender types for you. App-Embedded Defenders must be manually upgraded.

  • Jenkins plugin.

  • twistcli.

  • If you’re using projects, supervisor Consoles must match the Central Console version.

3.2. Defender support

Given a major version of Console, Prisma Cloud supports all minor versions of Defender. For example, if you’re running Prisma Cloud Compute Edition 20.09.345, and you upgrade Console to 20.09.365, then all deployed Defenders that are still on version 20.09.345 can continue to interoperate with Console 20.09.365 in what’s considered a supported configuration.

3.3. Version mismatches

Console interoperates with older components on a best-effort basis.

Defender is the only component where you can run an older version, and it’s considered a supported configuration. See Defender support.

When older components interact with Console, Console displays some indicators in the dashboard:

  • In Monitor > Events, any audits generated by unsupported versions of Defenders are marked with an out-of-date indicator. Links to the rules that triggered the audit are disabled (explanation follows).

  • In Monitor > Vulnerabilities and Monitor > Compliance, any scan reports generated by older/unspported components (Defender registry scanners, Jenkins plugins, twistcli) are marked with an out-of-date indicator.

Defenders from the immediate previous major release can interoperate with Consoles from the next major release, but their operation is restricted, and it’s considered an unsupported configuration. These types of Defenders fully protect your nodes using the policies and settings most recently cached before upgrading Console. They can emit audits to Console and local logs, including syslog. However, they cannot access API endpoints other than the upgrade endpoint, and they cannot share any new data with Console. No new policies or settings can be pushed from Console to older Defenders. When Defender is in this state, its status is shown as 'Upgrade needed' in Manage > Defenders > Manage. To restore it to a fully operational state, upgrade it.

4. Upgrading Console when using projects

When you have one or more tenant projects, upgrade all supervisor Consoles before upgrading the Central Console. During the upgrade process, there may be periods where the supervisors appear disconnected. This is normal, because supervisors are disconnected while the upgrade occurs and Central Console will try to reestablish connectivity every 10 minutes. Within 10 minutes of upgrading all supervisors and the Central Console, all supervisors should appear healthy.

Upgrade each Supervisor and then the Central Console using the appropriate procedure:

5. Defender auto-upgrade

Almost all Defender types can be auto-upgraded. Only App-Embedded Defenders must be upgraded manually.

Both App-Embedded and Serverless Defenders are backwards compatible with newer versions of Console. However, as a best practice, always upgrade them when Console is upgraded. App-Embedded Defenders whose versions are out of sync with Console’s version will continue to interoperate with Console, but some operations might be restricted, such as reconfiguring policy rules.

Incompatible Defenders can cause severe service disruptions such as disconnection from the upgraded Console, frozen runtime security of the environment (as new policies can’t be applied), Defender container panics, excessive alerts, and so on. The Defender auto-upgrade process ensures that there is no such impact caused by incompatibility between Console and Defenders when Console is upgraded. With this process, Defenders are always maintained in a supported and compatible state without any user intervention required.

The following table summarizes the Defender types, and which ones are auto-upgraded.

Defender type Auto-upgrade

Container Defender, which includes:

  • Single Container Defenders

  • Cluster Container Defenders

    • DaemonSets (Kubernetes, OpenShift)

    • ECS Defender task

    • Swarm global service

Y

Serverless Defender

Y* (see Serverless Defender auto-protect)

App-Embedded Defender

N

Tanzu Application Service (TAS) Defender

Y

Host Defender

Y

6. Enabling Defender auto-upgrade

By default, Defender auto-upgrade is enabled. You can check and change the setting in Console.

  1. Open Prisma Cloud Compute Console.

  2. Go to Manage > Defenders > Manage.

  3. Click on Advanced Settings.

  4. Set Automatically upgrade Defenders to On or Off.

    auto upgrade defenders