1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Configure
    6. Collections
    End-of-Life (EoL)

    Collections

    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
    All
     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.

    Creating collections

    You can create as many collections as you like. Collections cannot be nested. In tenant projects, collections are created and managed on a per-project basis.
    Prisma Cloud ships with a built-in set called
    All
     that is not editable. The
    All
     collection contains all objects in the system. It is effectively the same as creating a collection manually and setting a wildcard (*) for each resource type (e.g., containers, images, hosts, labels, etc).
    Collections can be created in
    Manage > Collections and Tags > Collections
    . Alternatively, collections can be created directly from a new rule dialog when you’re setting the rule’s scope. When creating collections from a new rule dialog, Prisma Cloud automatically disables any irrelevant scope fields. When selecting previously defined collections in a rule’s scope field, any improperly scoped collections are hidden from display. For example, you can’t select a collection that specifies serverless functions in a container runtime rule.
    By default, new collections set a wildcard for each resource, effectively capturing all resources in the system. Customize the relevant fields to capture some segment of the universe of resources.
    The labels field supports Docker labels, Kubernetes pod template labels, Kubernetes namespace labels, Kubernetes deployment labels, AWS tags, osDistro:<name> (for hosts), and osVersion:<version> (also for hosts).
    To use Kubernetes namespace and deployment labels, enable the following setting when deploying Defenders:
    Manage > Defenders > Deploy > DaemonSet > Collect Deployment and Namespace labels
    .
    To use AWS tags for hosts, enable the VM tags setting for relevant accounts under
    Defend > Compliance > Cloud platforms
    .
    For vulnerability and compliance rules, Fargate tasks are specified in the
    Hosts
     field of a collection. For runtime rules, Fargate tasks are specified in the App IDs field.
    You cannot have collections that specify both containers and images. You must leave a wildcard in one of the fields, or else the collection won’t be applied correctly. If you want to create collections that apply to both a container and an image, create two separate collections. The first collection should only include the container name, the second should only include the image name. Filtering on both collections at the same time will yield the desired result.
    Filtering by cloud account ID for Azure Container Instances isn’t currently supported.
    To create a new collection:
    1. Open Console.
    2. Go to
      Manage > Collections and Tags > Collections
      .
    3. Click
      Add collection
      .
    4. In the
      Create a new collection
       dialog, enter a name, description, and then specify a filter to target specific resources.
      For example, create a collection named
      Raspberry images
       that shows all raspberry images in the fruit namespace. Pick a color for easy visibility and differentiation.
      The following collection selects all images that start with the string raspberry. You can also create collections that exclude resources. For more information on syntax that can be used in the filter fields (e.g., containers, images, hosts, etc), see Rule ordering and pattern matching.
    5. Click
      Save
      .

    Assigned collections

    Collections provide a light-weight mechanism to provision least-privilege access to the resources in your environment. You can assign collections to specific users and groups to limit their view of data and resources in the environment.
    Projects is the other mechanism for partitioning your environment. Projects are Prisma Cloud’s solution for multi-tenancy. They let you provision multiple independent environments, and federate them behind a single Console URL, interface, and API. Projects take more effort to deploy than collections. Collections and Projects can work together. Collections can be utilized in both non-Project and Project-enabled environments.
    By default, users and groups can access all collections and are not assigned with any collection.
    Users with admin or operator roles can always see all resources in the system. They can also see all collections, and utilize them to filter views. When creating users or groups with the admin or operator role, there is no option for assigning collections.
    When creating users or groups with any other role, admins can optionally assign one more collections. These users can only see the resources in the collections they’ve been assigned.
    If a user is assigned multiple system roles, either directly or through group inheritance, then the user is grante the higest role, and access to the assigned collections of all the groups to which the user belongs. If a user is assigned both system and custom roles, then the user will be randomly granted the rights of one of the groups, including its role and assigned collections.
    Collections cannot be deleted as long as they’ve been assigned to users or groups. This enforcement mechanism ensures that users and groups are never left stateless. Click on a specific collection to see who is using them.
    Changes to a user or group’s assigned collections only take affect after users re-login.

    Assigning collections

    Assign collections to specific users and groups to restrict their view of data in the environment.
    If a role al