Upgrade considerations

PCF Defender — If you’re upgrading from 20.04, you must completely remove the 20.04 tile before installing the 20.09 tile. Previous versions of the tile deployed a single Defender on a single stand-alone VM for blobstore scanning only. The new tile deploys Defender to every Diego cell to protect your apps at runtime. Blobstore scanning is still supported with the new deployment architecture.
Windows Defender — The upgrade process uninstalls and then reinstalls the Windows driver. Although unlikely, there’s a potential race condition where the uninstall might run after the install. You’ll know you’re impacted if the status page for your Windows Defender shows a warning icon for process monitoring. To resolve the issue, run the following command, then restart Defender:
C:\Program Files\Twistlock\defender.exe driver --install
Enforcment in CNNF is not supported in 20.09 but will return in the next major release. If you rely on CNNF enforcement, consider skipping 20.09. When the next major release ships, steps will be provided to export rules from 20.04 and import them into it. CNNF rules will be deleted on upgrade.
After upgrading from 20.04 to 20.09, App-Embedded Defenders will continue to protect your application as specified by existing runtime and CNAF rules. However, you won’t be able to modify these rules. To do away with this restriction, redeploy your apps with 20.09 App-Embedded Defenders.
Defender DaemonSet has been updated to support Istio 1.4 and later. Defenders now request Authorization Policies from security.istio.io. If your environment supports Istio Authorization Policy, you must manually redeploy the Defender DaemonSet.

The behavior for flags passed to twistcli scan images has been updated. The default value for the --publish flag is now true, which means that scan results are published to Console by default (see
Monitor > Vulnerabilities > Images > CI
). To output results to a local file, use the --output-file option. Use both the --output-file and --publish in conjunction to control where results are sent. For example, you might want to get local scan results only without spamming Console’s database. Remember that Console stores a maximum of 1000 scan reports on a FIFO basis.
If you’re using the --ci flag, update your scripts to use --output-file and --publish instead. The --ci flag is considered deprecated, although it’s still available as a hidden option However, starting with this release, you won’t be able to depend on support for it.
As part of the revamped host runtime protection feature in 20.09, all host models, host audits, and host incidents will be deleted when you upgrade.

Audit logs are now subject to the caps documented here. When you upgrade, the oldest audits that exceed these caps will be dropped.

Breaking changes

The heading for the image vulnerabilities CSV file has changed from
Tags
to
Vulnerability Tags
.
To control Console resource consumption, limits have been put in place. As part of this change:
Container models will be dropped when you upgrade 20.09. New models will be created from scratch using the normal learning process.
Vulnerability alerts that arise from registry scans will now trigger for the 50 most recent images only, as sorted by last modified date.

Breaking changes in the API

Starting in 20.09, all endpoints that take credentials now uniformly reference them by credential ID. Credential details are no longer specified inline with POST requests or returned in GET responses in the credential object. If you’re configuring registry or serverless scanning via the API, you’ll need to update the way you invoke the following endpoints to reference the credential ID:
/api/v1/settings/registry

/api/v1/settings/serverless-scan

The following snippet shows the response from GET /api/v1/settings/registry in 20.09. Notice that the credential object now holds null values. The credentialID is what Primsa Cloud uses to scan the registry.

    {
      "registry": "gcr.io",
      "repository": "sandbox/jon/prom/*",
      "tag": "*",
      "cap": 5,
      "os": "linux",
      "hostname": "",
      "namespace": "",
      "useAWSRole": false,
      "version": "gcr",
      "credential": {
        "_id": "",
        "type": "",
        "accountID": "",
        "accountGUID": "",
        "secret": {
          "encrypted": ""
        },
        "apiToken": {
          "encrypted": ""
        },
        "lastModified": "0001-01-01T00:00:00Z",
        "owner": "",
        "tokens": null
      },
      "credentialID": "GCR Scanning",
      "roleArn": "",
      "scanners": 2,
      "versionPattern": ""
    }
The method for calling the following Defender-related endpoints has changed from GET to POST:
/api/v1/scripts/defender.sh
/api/v1/scripts/defender.ps1
/api/v1/defenders/helm/twistlock-defender-helm.tar.gz
/api/v1/defenders/daemonset.yaml
The subresource for endpoints that manage serverless autoprotect have changed from from serverless-auto-protect to serverless-auto-deploy. The new endpoints in 20.09 are:
POST /api/v1/settings/serverless-auto-deploy
GET /api/v1/settings/serverless-auto-deploy
GET /api/v1/statuses/serverless-auto-deploy
For a complete list of deprecated endpoints in 20.09, see the porting guide.

Deprecated this release

Prisma Cloud High Availability (HA). For HA, use a container orchestrator, such as Kubernetes, to run and manage the Console container.

Known issues

On OpenShift 4 clusters, we do not currently show any image labels or layer information. This is being addressed in our next major release, which will continue our goal of parity for dockerless OpenShift environments.

Upcoming deprecations

Support for deploying Prisma Cloud to DC/OS will be deprecated next release.
SCAP support will be deprecated in the next release.
Scale projects will be deprecated in the next release. Starting in the next release, each Console, including each tenant project Console, will be able to support 10,000 Defenders. For information about how to migrate your scale projects to a supported configuration, see here.