Trusted images
Trusted images is a security control that lets you declare, by policy, which registries, repositories, and images you trust, and how to respond when untrusted images are started in your environment.
Image provenance is a core security concern.
In NIST SP 800-190 (Application Container Security Guide), the section on countermeasures for major risks (Section 4) says:
Container runtimes, such as Docker Engine, will run, by default, any container you ask it to run.
Trusted images lets you explicitly define which images are permitted to run in your environment.
If an untrusted image runs, Prisma Cloud emits an audit, raises an alert, and optionally blocks the container from running.
Modern development has made it easy to reuse open source software.
Pulling images from public registries, such as Docker Hub, is simple and fast, and it removes a lot of friction in operations.
Retrieving and executing software with such ease, however, runs contrary to many organizations' security policies, which mandate that software originates from approved providers and distribution points.
The Trusted Images rule engine lets you specify registries, repositories, and images that are considered trustworthy.
Feature overview
Trusted images is disabled by default.
To enable it, go to
Defend > Compliance > Trusted Images > Policy
.After enabling the feature, you must specify the images you trust.
Declare trust using objects called trust groups.
Trust groups collect related registries, repositories, and images in a single entity.
Then use those entities for writing policy rules.
The default policy consists of a single rule that alerts on all images started in your environment.
Build out your policy by writing new rules.
Rules let you define:
- Explicitly allowed trust groups.
- Explicitly denied trust groups
- An action to take when an image isn’t trusted.
When a container starts in your environment, Defender assesses the event against your trust policy, and then acts accordingly.
Rules in a policy are evaluated top-down.
The criteria for matching an event to a rule is the cluster or the hostname.
When a matching rule is found, the rule is processed.
No subsequent rules are processed.
The first rule that matches the cluster or hostname holds the verdict for all images that can run on that cluster/host.
If the image being started matches an explicitly denied trust group, the rule effect is applied.
If an image doesn’t match either the list of explicitly allowed trust groups or explicitly denied trust groups, the rule effect is also applied.
Audits are created when the effect of a rule is alert or block.
You can review audits in
Monitor > Events
.
When reviewing audits, you can optionally add the image to a trust group to quickly adjust your policy and clean up false positives.The Console UI provides a number of features to surface trust in your environment.
- Image scan reports have indicators in the report header to show whether an image is trusted or not. See:
- Monitor > Compliance > Containers and Images
- Monitor > Vulnerabilities > Images
- A dedicated page inMonitor > Compliance > Trusted Images, shows a snapshot of all running images in your environment and their trust status. The table is updated at scan-time, which is once per 24 hours by default. However, the page lets you force a re-scan and refresh the results.Also note that updated policies aren’t automatically reflected in the view. If you change a rule in your Trusted Images policy, re-scan the images in your environment to update the view.
Trusted images are not supported for Fargate tasks.