Collections are predefined filters for segments of your environment. They’re centrally defined, and they’re used in rules and views across the product.
Collections are used to:
  • Scope rules to target specific resources in your environment. For example, you might create a vulnerability rule that applies to all container images in an app called sock-shop. The rule might reference collectionA, which specifies sock-shop** in the image resource filter.
  • Partition views. Collections provide a convenient way to browse data from related resources.
  • Enforce which views specific users and groups can see. Collections can control access to data on a need-to-know basis. These are known as assigned collections.
Collections are created with pattern matching expressions that are evaluated against attributes such as image name, container name, host name, labels, function name, namespace, and more.
For labels, Prisma Cloud supports AWS tags, as well as distro attributes. Distro attributes are designed for central security teams that manage the policies in Console, but have little influence over the operational practices of the groups that run apps in the environments being secured. If the central security team can’t rely on naming conventions or labels to apply policies that are OS-specific (e.g. different compliance checks for different OSs), they can leverage the distro attributes. Supported distro attributes are:
  • Distro name — "osDistro:<value>" (e.g. "osDistro:Ubuntu")
  • Distro version — "osVersion:<value>" (e.g. "osVersion:20.04")

Partitioning views

While a single Console manages data from Defenders spread across all hosts, collections let you segment that data into different views based on attributes.
Collections are useful when you have large container deployments with multiple teams working on multiple apps all in the same environment. For example, you might have a Kubernetes cluster that runs a shopping app, a travel app, and an expenses app. Different teams might be responsible for the development and operation of each app. An internal tools team might be responsible for the travel and expenses app, while a product team runs the shopping app.
Selecting a collection reduces the scope displayed in Console to just the relevant resources. For example, the developer for the travel app only cares about vulnerabilities in the images that make up the travel app. All other vulnerabilities are just noise. Collections help focus the data.

Scoping rules

The scope of a rule is defined by referencing the relevant collections. Collections offer a centralized way to create and manage scope settings across the product. Collections make it easy to consistently reuse scope settings across policies. Policy tables give you a clear picture of what resources are being targeted in your rules.
When creating new rules, you can either select from a list of previously defined collections, or create a new one. By default, Prisma Cloud sets a rule’s scope to the
collection, which captures all resources in the environment.
Collections cannot be deleted as long as they’re being used by a rule. This mechanism ensures that rules are never left unscoped. Click on a specific collection to see how it’s being used.

Importing and exporting rules

Rules can be exported from one Console and imported into another Console. When importing rules, any associated collections are also imported and created.
  • If the imported rule uses a collection that doesn’t exist in Console, the collection is automatically created.
  • If the imported rule uses collection with a name that already exists, but with a different scope, the collection is created with the following name and description:
    • Name: <policyType> - <ruleName> <collectionName>
    • Description: Automatically generated collection for an imported rule/entity
  • If the imported rule uses a collection that already exists, and a matching scope, the existing collection is used as-is.