Edit on GitHub

20.12 Update 1 Release Notes

1. Overview

This section lists the issues addressed in this release.

This release will be available for download on January 19, 2021.

2. Improvements, fixes, and performance enhancements

  • Fixes an issue with naming collisions for DaemonSet Defenders deployed in AWS and Azure. This fix has a number of implications, so you must explicitly enable it when upgrading. For more information, see Defender name collisions and upgrade considerations.

  • Enables Defender-to-Console network connection configuration (port and proxy) for Defender deployments in VMware Tanzu Application Service (TAS).

  • Extends the WAAS proxy to support localhost. As part of this change, you can now configure an external port (where WAAS listens) and an internal port (where WAAS forwards requests).

  • Fixes a UI issue where charts with insufficient data appeared corrupted.

  • Fixes an issue in the UI where the table of credentials couldn’t be sorted by credential type.

  • Adds support to admission control (Open Policy Agent, OPA) for exec’ing or attaching to a pod. To use this new capability, you must redeploy the admission webhook.

  • Updates open source packages used in Prisma Cloud Compute components.

3. Defender name collisions and upgrade considerations

The name assigned to a Defenders has been the name of the underlying host where it runs. It’s been assumed that hostname is a unique value. However, on some cloud platforms, hostname isn’t unique. Hostnames can be duplicated across environments, causing naming conflicts for deployed Defenders. For example, in AWS if you have VPCs with the same network ranges, nodes in EKS clusters can have the same hostname because hostnames are derived from the private ip address of the instance. This results in Defenders with duplicate names.

Update 1 fixes the issue for DaemonSet Defenders (Kubernetes and OpenShift) running on AWS or Azure. The fix extracts a unique context from the cloud metadata, and wraps hostnames with this context to generate unique hostnames.

3.1. Defender naming scheme

The Defender naming scheme has been updated to guarantee uniqueness.

In AWS, the Defender name is derived as follows: <hostname>-<instance ID>. For example, ip-172-31-80-18.ec2.internal-i-07dcaXXXXXXXXXXXX.

In Azure, the Defender name is dervived as follows: <hostname>-<resource group name>-<subscription ID>. For example, aks-agentpool-16600000-vmss000000-MC_user-aks_user-aks_eastus-ae0XXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.

3.2. Enabling the new naming scheme on upgrade

You can configure Prisma Cloud to rename Defenders with unique strings on upgrade. Renaming Defenders might break other product configurations, so it is disabled by default.

To enable Defender renaming on upgrade, redeploy Defenders in your EKS (AWS) and AKS (Azure) clusters.

  1. Generate the Defender DaemonSet YAML from the Console UI or with twistcli.

  2. Open the YAML file, and set the CLOUD_HOSTNAME_ENABLED environment variable to true.

    - name: CLOUD_HOSTNAME_ENABLED
  value: "true"

  3. Update the Prisma Cloud objects.

    $ kubectl apply -f defender.yaml

Upon upgrade, old Defenders appear in Console as disconnected until they’re automatically cleaned up by Console. Upgraded Defenders, with their longer unique name, appear alongside the old disconnected Defenders.

3.3. Known issues

There are some implications when renaming Defenders:

  • If you’ve assigned a specific Defender in your AWS or Azure environment to scan your registries, this setting will break when Defenders reconnect to Console with their longer unique names. In your registry settings (Defend > Vulnerabilities > Images > Registry settings) you’ll see the following error:

    Registry Scan: no available defender was found

    To fix the issue, open the registry setting, and select the renamed Defender.

  • Policy rules with host-specific scopes will no longer match for AWS and Azure hosts. Manually reconfigure any collections with this type of scope.