> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/admin-guide/32/configure/collections.md). # 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 a collection, 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](/admin-guide/32/configure/rule-ordering-pattern-matching.md) expressions that are evaluated against attributes such as image name, container name, hostname, labels, function name, namespace, registry tag, 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:\" (e.g. "osDistro:Ubuntu") * Distro version — "osVersion:\" (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.
collections policy table scopes
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 rule scope
## 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 a collection with a name that already exists, but with a different scope, the collection is created with the following name and description: * Name: \ - \ \ * 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. 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 the 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](https://docs.docker.com/config/labels-custom-metadata/), Azure registry tags (`key:value`), Kubernetes pod template labels, Kubernetes namespace labels, Kubernetes deployment labels, AWS tags, distribution name for hosts (`osDistro:`), and operating system version for hosts (`osVersion:`). Prisma Cloud extracts registry tags from Azure registry. You can use these registry tags to implement role-based access control to regulate the visibility of registry vulnerability scan findings to a user role. Prisma Cloud designates all identified Azure registry tags as **Registry labels** under **Monitor > Vulnerabilities > Images > Registries, Image details > Labels**. To use Kubernetes namespace and deployment labels, enable the following setting when deploying Defenders: **Manage > Defenders > Defenders: Deployed > Manual deploy > Collect Deployment and Namespace labels**. To use AWS tags for hosts, enable **VM tags** for relevant accounts under **Manage > Cloud accounts > Add/edit account > Discovery features**. To scope App-Embedded policy rules (e.g., vulnerability, compliance, and runtime rules), use the collection’s **App ID** field. For Fargate tasks protected by App-Embedded Defenders, you can additionally scope rules by image. You cannot have collections that specify a combination of both: * Host and cluster * Container and image You must leave a wildcard in one of the fields, or else the collection won’t be applied correctly. For example, 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, and the second should only include the image name. Filtering on both collections at the same time will not 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. Select **Add collection**. 4. In **Create new collection**, enter a **Name**, and **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](/admin-guide/32/configure/rule-ordering-pattern-matching.md).
collections specify filter
5. Select **Save**. You can view a summary of each Collection in the sidecar, which shows the resources' data and usage of the Collection.
collection sidecar view
## Selecting a collection Collections filter data in the **Monitor** section of the Console. When a collection (or multiple collections) is selected, only the objects that match the filter are shown in those views. When a collection is selected, it remains selected for all views until it is explicitly disabled. To select a collection, go to any view under **Monitor**. In the Collections drop-down list in the top right of the view, select a collection. In the following screenshot, the view is filtered based on the collection named **google images**, which shows all images that contain the string **google\_containers**.
collections 792004
When multiple collections are selected, the effective scope is the union of each individual query. Individual filters on each collection aren’t applicable to all views. For example, a collection created with only functions won’t include any resources when viewing the hosts results. Similarly, a collection created with hosts won’t filter images by hosts when viewing image results. The **Collections** column shows to which collection a resource belongs. The color assigned to a collection distinguishes objects that belong to specific collections. This is useful when multiple collections are displayed simultaneously. Collections can also be assigned arbitrary text tags to make it easier for users to associate other metadata with a collection. ## Use Collections with TAS Metadata Fields Prisma Cloud automatically collects metadata fields such as Foundation, Organization Name, Application Name and ID, and Space Name and ID. To utilize these fields, you’ll have to **manually create** appropriate collections that can then be used for filtering and aggregation. | Resource type | Supported Labels | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Host | tas-foundation | | Containers (running applications) | tas-application-id, tas-application-name, tas-space-id, tas-space-name, tas-org-id, tas-org-name, tas-foundation | | Droplets | tas-application-id, tas-application-name, tas-space-id, tas-space-name, tas-org-id, tas-org-name, tas-foundation | * To use the **tas-fundation** label, enter a **Foundation** name in the Prisma Cloud TAS tile configuration screen at the time of [deploying a TAS Defender](/admin-guide/32/install/deploy-defender/orchestrator/install-tas-defender.md). ## Limitations Different views in Console are filtered by different resource types. If a collection specifies resources that are unrelated to the view, filtering by this collection returns an empty result. | Section | View | Supported resources in collection | | ------------------------------------------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Monitor/Vulnerabilities

Monitor/Compliance

| Images | Images, Hosts, App IDs (App-Embedded), Namespaces, Clusters, Labels, Cloud Account IDs | |

Monitor/Vulnerabilities

Monitor/Compliance

| Registry images | Images, Hosts (of the scanner host), Labels, Cloud Account IDs | |

Monitor/Vulnerabilities

Monitor/Compliance

| Containers | Images, Containers, Hosts, Namespaces, Clusters, Labels, Cloud Account IDs | |

Monitor/Vulnerabilities

Monitor/Compliance

| Hosts |

Hosts, Clusters, Cloud Account IDs

Note: As Kubernetes nodes and namespaces are not scanned, the Monitor/Vulnerabilities Hosts view cannot filter hosts using K8s node and namespace labels. However, you can filter hosts using K8s pod label.

| |

Monitor/Vulnerabilities

Monitor/Compliance

| VM images | VM images (under Images), Cloud Account IDs | |

Monitor/Vulnerabilities

Monitor/Compliance

| Functions | Functions, Cloud Account IDs, Labels (Region, AWS tag) | | Monitor/Vulnerabilities | Code repositories | Code repositories | | Monitor/Vulnerabilities | VMware Tanzu blobstore | Hosts (of the scanner host), Cloud Account IDs, Labels (tas-application-id, tas-application-name, tas-space-id, tas-space-name, tas-org-id, tas-org-name, tas-foundation) | | Monitor/Vulnerabilities | Vulnerability Explorer | Images, Hosts, Clusters, Labels, Functions, Cloud Account IDs | | Monitor/Compliance | Cloud Discovery | Cloud Account IDs | | Monitor/Compliance | Compliance Explorer | Images, Hosts, Namespaces, Clusters, Labels, Cloud Account IDs | | Monitor/Events | Container audits | Images, Containers, Namespaces, Clusters, Container Deployment Labels (under Labels), Cloud Account IDs. (Cluster collections are not currently able to filter some events such as container audits, specifically.) | | Monitor/Events | WAAS for Containers | Images, Namespaces, Cloud Account IDs | | Monitor/Events | Trust Audits | Images, Clusters, Cloud Account IDs | | Monitor/Events | Admission Audits | Namespaces, Clusters, Cloud Account IDs | | Monitor/Events | Docker Audits | Images, Containers, Hosts, Clusters, Cloud Account IDs | | Monitor/Events | App-Embedded audits | App IDs (App-Embedded), Cloud Account IDs, Clusters, Images | | Monitor/Events | WAAS for App-Embedded | App IDs (App Embedded), Cloud Account IDs | | Monitor/Events | Host audits | Hosts, Clusters, Labels, Cloud Account IDs | | Monitor/Events | WAAS for Hosts | Hosts, Cloud Account IDs | | Monitor/Events | Host Log Inspection | Hosts, Clusters, Cloud Account IDs | | Monitor/Events | Host File Integrity | Hosts, Clusters, Cloud Account IDs | | Monitor/Events | Host Activities | Hosts, Clusters, Cloud Account IDs | | Monitor/Events | Serverless audits | Functions, Cloud Account IDs, Labels (Region, Provider) | | Monitor/Events | WAAS for Serverless | Functions, Cloud Account IDs, Labels (Region) | | Monitor/Runtime | Container incidents | Images, Containers, Hosts, Namespaces, Clusters, Cloud Account IDs | | Monitor/Runtime | Host incidents | Hosts, Clusters, Cloud Account IDs | | Monitor/Runtime | Serverless incidents | Functions, Cloud Account IDs, Labels (Region) | | Monitor/Runtime | App Embedded incidents | App IDs (App Embedded), Cloud Account IDs | | Monitor/Runtime | Container models | Images, Namespaces, Clusters, Cloud Account IDs | | Monitor/Runtime | App-Embedded observations | App IDs, Images, Containers, Clusters, Account IDs, Regions (under Labels) | | Monitor/Runtime | Host observations | Hosts, Clusters, AWS tags (under Labels), OS tags (under Labels), Cloud Account IDs | | Monitor/Runtime | Image analysis sandbox | Images, Labels | | Radar | Containers Radar | Images, Containers, Hosts, Namespaces, Clusters, Labels, Cloud Account IDs | | Radar | Hosts Radar | Hosts, Clusters, AWS tags (under Labels), OS tags (under Labels), Cloud Account IDs | | Radar | Serverless Radar | Functions, Cloud Account IDs, Labels (Region, AWS tag) | | Manage | Defenders | Hosts, Clusters, Cloud Account IDs | ### Using Collections After collections are created or updated, some views require a rescan before you can see the change: * Deployed Images vulnerabilities and compliance views * Registry Images vulnerabilities and compliance views * Code repositories vulnerabilities view * Trusted images * Cloud Discovery * Vulnerability Explorer * Compliance Explorer After collections are created or updated, some views are affected by the change only for future records. These views include historical records that keep their collections from creation time: * Images and Functions CI results view * Events views * Incidents view * Image analysis sandbox results view --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prismacloud.io/admin-guide/32/configure/collections.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.