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.
Trust indicators in the Console UI
Badges are shown throughout Console to clearly delineate between trusted and unstrusted images.
The following badges are used:
- Trusted — Explicitly trusted by a user-defined rule (Defend > Compliance > Trusted Images > Policy).
- Untrusted. An image is considered untrusted if it’s untrusted on at least one host.
Badges are shown in the following pages:
- Scan reports (click on a row in the table to open an image scan report):
- Monitor > Compliance > Containers and Images
- Monitor > Vulnerabilities > Images
- Snapshot of all running containers and their trust status. The table is updated at scan-time.
- Monitor > Compliance > Trusted Images
Events Viewer
Prisma Cloud generates an audit for every image that is started in your environment, but fails to comply with your trust policy.
Audits can be reviewed under
Monitor > Events > Trust Audits
.
When reviewing audits, you can optionally add the image to a trust group.Establishing trust with rules
Prisma Cloud monitors the origin of all containers on the hosts it protects.
Policies are built on rules, and rules reference trust groups.
Trust groups are collections of related registries and repositories.
Trust is established by one of the following factors:
- Point of origin (registry and/or repository),
- Base layer(s).
Trusting images by image tag isn’t supported.
Establishing trust by registry and repository
Prisma Cloud lets you specify trust groups by registry and repository.
If you specify just a registry, all images in the registry are trusted.
Establishing trust by base layer
Images can have layers in common.
If your organization builds and approves specific base images for use in containerized apps, then you can use this mechanism to enforce compliance.
For example, consider the ubuntu:16.04 image.
If you run docker inspect, the layers are:
"Layers": [ "sha256:a94e0d5a7c404d0e6fa15d8cd4010e69663bd8813b5117fbad71365a73656df9", "sha256:88888b9b1b5b7bce5db41267e669e6da63ee95736cb904485f96f29be648bfda", "sha256:52f389ea437ebf419d1c9754d0184b57edb45c951666ee86951d9f6afd26035e", "sha256:52a7ea2bb533dc2a91614795760a67fb807561e8a588204c4858a300074c082b", "sha256:db584c622b50c3b8f9b8b94c270cc5fe235e5f23ec4aacea8ce67a8c16e0fbad" ]
Now consider a new image, where ubuntu:16.04 is the base OS.
The following Dockerfile shows how such an image is constructed:
FROM ubuntu:16.04 RUN apt-get update ADD hello.txt /home/hello.txt WORKDIR /home
After building the image, and inspecting the layers, you can see that both images share the same first five layers.
"Layers": [ "sha256:a94e0d5a7c404d0e6fa15d8cd4010e69663bd8813b5117fbad71365a73656df9", "sha256:88888b9b1b5b7bce5db41267e669e6da63ee95736cb904485f96f29be648bfda", "sha256:52f389ea437ebf419d1c9754d0184b57edb45c951666ee86951d9f6afd26035e", "sha256:52a7ea2bb533dc2a91614795760a67fb807561e8a588204c4858a300074c082b", "sha256:db584c622b50c3b8f9b8b94c270cc5fe235e5f23ec4aacea8ce67a8c16e0fbad", "sha256:29d16833b7ef90fcf63466967c58330bd513d4dfe1faf21bb8c729e69084058f", "sha256:1d622b0ae83a00049754079a2bbbf7841321a24cfd2937aea2d57e6e3b562ab9" ]
Creating trust groups manually
Trust groups are collections of related registries and repositories.
Policies are built on rules, and rules reference trust groups.
When setting up a trust group, you can explicitly specify registries and repositories to trust.
Prisma Cloud supports leading and trailing wildcard matches as described in the following table:
Match type | Registry only | Repository only | Both |
|---|---|---|---|
Exact match | reg | repo | reg/repo |
Suffix match | reg* | repo*
repo/* | reg/repo*
reg/repo/* |
Prefix match | *reg | *repo | *reg/repo |
Both suffix & prefix | *reg/* | *repo/* | *reg/repo/* |