Trusted images
Trusted images is a security control that guarantees that only images you trust can run in your container environment.
Image provenance is a core concern discussed in NIST SP 800-190 (Application Container Security Guide).
Section 4, which discusses countermeasures for major risks, says:
By default, Docker Engine runs any container you ask it to run.
Trusted images lets you define exactly which images are permitted to run in your environment.
If an untrusted image is run, Prisma Cloud can log an audit, raise an alert, or block the container from running.
Modern development makes 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 originate from approved providers and distribution points.
Prisma Cloud’s Trusted Images feature lets you specify registries and repositories that are considered trustworthy, and then alert or block the use of images from any other location.
Prisma Cloud uses automatic learning, along with a supplemental rule engine, to make it easy to put the Trusted Images feature into operation.
When Prisma Cloud is first installed, it automatically learns the origin of all the images in use across your environment, enumerates them in a way that future versions of the same app are included in this list, and suggests a policy that constrains the list of trusted images to just the learned images.
The sources for these trusted images can be numerous, from internal registries to public sources.
The rule based policy engine lets you override and supplement the learned list to explicitly allow or deny additional images, and control how the policy is applied across different nodes in your clusters.
Learning algorithm
When Prisma Cloud is first installed, it immediately commences a 24 hour learning period, and creates a model of trusted images.
An image is deemed trusted if:
- It exists locally on a host protected by Defender, and there’s a running instance of it.
- It’s a Prisma Cloud image, such as Console or Defender.
To see the model, go to
Monitor > Compliance > Trusted Images
.
After the learning period is over, you can manually initiate a relearn process, which adds new images to the model.
The manual relearn period lasts for 24 hours.
You can manually stop the learning period at any time.Prisma Cloud automatically learns about its environment one time only.
After that, all further learning must be user initiated.
In general, you should utilize the following strategy when using the Trusted Images feature:
- When you first install Prisma Cloud, it assumes that you’ve already deployed your apps, and that you might scale out later by adding more hosts and Defenders. Prisma Cloud automatically learns all the containers that make up your apps, and adds them to the model of trusted images. Scaling out an app creates new containers, not new images, so additional learning isn’t required after the initial learning period has completed.
- When you deploy a net new app, initiate the relearn process to capture new repos and images in the model.
- Use rules to augment the model. Rules let you further refine what images are considered trusted in your environment. They let you specify images to explicitly trust, and images to explicitly blacklist. You can raise alerts when untrusted images are detected, or block untrusted images from running entirely.To view and configure your rules, go toDefend > Compliance > Trusted Images. The default policy comprises of a single rule that alerts when any image not in the learned model is run in your environment.
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 the model (Monitor > Compliance > Trusted Images) or user-defined rule (Defend > Compliance > Trusted Images).
- Partially trusted — Referenced in a rule somewhere in Console, but not explicitly trusted.
- Not trusted.
Badges are shown in the following pages:
- Monitor > Compliance > Images
- Monitor > Vulnerabilities > Images
Hovering over the badge opens a tool tip that specifies how the trust rating for the image was determined:
- Learned as Trusted Image by Prisma Cloud
- Allowed by %rule.name
- Specific label/host selector in %rule.name
Events Viewer
After the learning period is completed, Prisma Cloud generates an audit for every image that is created and fails to comply with the trust groups policy.
Audits can be reviewed under
Monitor > Events > Trust Audits
.Establishing trust with rules
Prisma Cloud monitors the origin of all images on each host it protects.
Prisma Cloud lets you create a list of trusted images, where trust is established with:
- Image ID,
- Point of origin (registry/repository),
- Base layer(s).
The term "trust group" is utilized extensively throughout the UI.
It simply means all images that are captured by a rule’s specifications.
For example, an image group with the following spec captures exactly one image.
mydomain.com/myrepo/myimage:3.12
A trust group that specifies a single image ID contains exactly one image:
sha256:0cdd4174aaf030acd55400ba3315e15a7bb1f3411e6a8283bdfc77ab293c45c1
However, an image group with wildcards contains many images.
The following spec captures all images in a private registry.
mydomain.com/myrepo/*
Establishing trust by image ID or name
Prisma Cloud lets you specify trust groups by registry, repo, image name, image name and tag, and image ID.
If you specify just a registry, all images in the registry are trusted.
Matching for this field can be scoped with trailing wildcards.
For example:
Trust an entire registry:
registry.mydomain.com/*
Trust an entire Docker Hub repository:
myrepo/*
Trust all images in a repo in a private registry.
mydomain.com/myrepo/myimage:*
Trust a specific image:
sha256:0cdd4174aaf030acd55400ba3315e15a7bb1f3411e6a8283bdfc77ab293c45c1
Establishing trust by base layer
Images can have layers in common.
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, with ubuntu:16.04 as the base.
The following Dockerfile shows how it is constructed:
# # Test base layers # 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" ]
Augmenting the model with rules
In most cases, Prisma Cloud’s automatic learning process properly identifies and whitelists the full range of images in your environment that should be considered trusted.
In some cases, you might need to augment the model, which you can do by creating rules.
Prisma Cloud evaluates the rules in your trusted images policy from top to bottom, until a match is found based on resource filters.
When a match is found, Prisma Cloud applies the actions in the rule and stops processing any further rules.
If no match is found, then no action is applied
Rules are based on a construct called "trust groups", where a range of images is defined by registry, repo, image name, tags, image ID, and wild cards.
- Open Console.
- Go toDefend > Compliance > Trusted Images.
- Click theAddbutton.
- In the rule dialog:
- Enter a name for the rule.
- Select an effect.Ignore— Do nothing if an untrusted image is detected.Alert— Show the appropriate trust indicators in the Console UI.Block— Prevent the container from running on the affected host if the image isn’t trusted. Blocking isn’t supported for Windows containers.
- Specify the rule’s trigger.The fields inAdd resourcesfilter which images are to be evaluated by this rule (before even evaluating the groups defined in the whitelist/blacklist).If you specify a wildcard inAdd resources > Images, then the rule is evaluated for all images, and no subsequent rules will ever be evaluated. Although this is a suitable configuration for a catch-all rule at the bottom of the list, it’s probably not what you want for more granular rules higher up the list.Filtering by host is only applicable to blocking rules.
- Explicitly whitelist or blacklist image groups.ClickCreate group, then define the images in the set.Specify an image identifier to designate trust. You can use a registry, repo, image name, or image name and tag. If you specify just a registry, all images in the registry are trusted. Matching for this field can be scoped with trailing wildcards. For example:registry.mydomain.com/* myapplicationrepo/* mydomain.com/myapplicationrepo/myimage:*Prisma Cloud streamlines the process of specifying the base layers by letting you import the base layers from any image in your environment. If Prisma Cloud has seen and scanned an image, it is available in theImagedrop-down list.Select an image, import it, and then review the SHA256 hashes for the base layers.For example, if the secteam/ubuntu:16.04 is your trusted base OS, select it from theImagedrop-down list, and clickImport.(Optional) Append a custom message to the block action audit message.Custom messages help the operator better understand how to handle a blocked action. You can enhance Prisma Cloud’s default response by appending a custom message to the default message. For example, you could tell operators where to go to open a ticket.ClickSave.Your rule is added to the top of the rule list. Rules are processed in priority order. Rules at the top of the list have the highest priority.
Most Popular
