Configure registry scans
Prisma Cloud can scan container images in both public and private repositories on both public and private registries.
The registry is a system for storing and distributing Docker images. The most well-known public registry is Docker Hub, although there are also registries from Amazon, Google, and others. Organizations can also set up their own internal private registries. Prisma Cloud can scan container images on all of these types of registries.
Registry scanning is handled by Defender. When you configure Prisma Cloud to scan a registry, you can either:
- Let Prisma Cloud automatically distribute the scan job across a pool of available Defenders, or
- Explicitly specify the Defender to do the job.
Any Container Defender running on a host with the Docker Engine container runtime can scan a registry, and any number of them can simultaneously operate as registry scanners. This gives you a lot of options when you’re trying to determine how to cover disparate environments.
In general, you should configure Prisma Cloud to automatically distribute scan jobs because it reduces operational complexity and improves resiliency. At scan-time, Prisma Cloud enumerates the available Defenders, manages the resource pool, and handles issues such as restarting partially completed jobs. If you explicitly select a specific Defender to handle scanning, the host where Defender runs is a single point of failure. If the host fails, or gets destroyed, you have to manually reconfigure your scan configuration with a different Defender.
When selecting the automatic algorithm for registry scanning, you can specify the number of Defenders in the resource pool. For large registries or aggressive scan intervals, increase the number of Defenders to improve throughtput and reduce scan time.
Registry scanning is scoped by OS type. Windows Defenders can only scan Windows images, and Linux Defenders can only scan Linux images.
If you remove an image from the registry, or the registry becomes unavailable, Prisma Cloud maintains the scan results for 30 days. After 30 days, the scan results are purged.
When you have very large registries, you must optimize your scan configuration to maximize throughput and minimize scan time. The first obvious optimization is to set the scan algorithm to automatic and increase the number of scanners. The second optimization is to specify a version matching pattern in your registry scan configuration.
Optimizing registry scans with version pattern matching is only necessary for very large registries with tens of thousands of repositories and millions of images.
The scanner makes many API calls to the registry to retrieve metadata for the registry, repos, and images. All metadata must be collected, collated, and sorted before scanning can start. Consider the normal flow for collecting metadata:
Get a list of all repos in the registry For each repo: Get a list of all image tags For each image tag: Get the image manifest (which contains the last modified date) Sort, Cap, Scan
After fetching all metadata, the scanner sorts the images by last modified date, and caps the list if a cap value is specified in the scan configuration. The default cap value is 5. With a cap of 5, the scanner fetches the five most recently modified images from the registry for scanning.
If you specify a version matching pattern, the scanner looks to the image tag for sort order. Without a version matching pattern, the sort order is last modified date. With a version matching pattern, you customize how the scanner interprets image tags for sorting. For example, if you utilize semantic versioning in your image names, you could specify the following version pattern:
The scanner parses each image tag, extracts the pattern from the tag, and splits it into its constituent parts. After all tags are parsed, they are sorted, and capped according to your configuration. The optimized flow for collecting metadata eliminates the inner loop, substantially reducing the number of requests to the registry so scanning can start sooner.
Get a list of all repos in the registry For each repo: Get a list of all images tags Sort, Cap, Scan
If your repo had three images, and your scan configuration specified a cap of
2and version pattern of
*-%d.%d.%d, you’d get the following result:
myimage-3.0.0 <<<--- Scan myimage-2.0.1 <<<--- Scan myimage-2.0.0 (Not scanned)
Registry scan settings
Each rule has the following parameters, although the parameters can vary according to registry type. For step-by-step instructions for a registry from a specific vendor, see the appropriate registry-specific guide.
Specify the type of registry to scan. If you do not find your vendor’s registry in the drop-down list, try
Docker Registry v2. Most vendors comply with the Docker Registry version 2 API.
Docker Registry v2.
Specify the URL for the registry. For Docker Hub, leave this field blank.
Harborspecify the FQDN of your Harbor registry.
Specify the repository to scan. This field supports pattern matching. To scan all repositories, simply enter wildcard (
Docker Hub:To specify an official Docker repository, enter library/, followed by the short string used to designate the repo. For example, to scan the images in the official Alpine Linux repository, enter library/alpine.
To specify non-official repositories, enter the user name or organization name, followed by a slash, followed by the name of the repo. For example, to specify the alpine repository in onescience’s account, enter onescience/alpine.
To scan all repos from a user or organization, simply enter the user or organization name, followed by a wildcard (
*). For example, to scan all repos created by onescience, enter onescience*.
Amazon EC2 Container Registry:Enter the repositoryName.
Google Cloud Platform Container Registry:Enter your project ID and image name in the following format: project-id/image-name. Or, leave this field blank to sync all the repos in your GCR account with Prisma Cloud automatically.
Harbor:To specify a repository, enter the name of the repository, followed by a wildcard (
*). For example, to scan repository library, enter library*.
Any Docker Registry version 2 API compliant registry:To scan all images in all repositories in the registry, leave this field blank. Prisma Cloud automatically stays synchronized with the registry. When repos are added, images are automatically scanned for vulnerabilities. If there is no activity in the registry, periodic scans are run at interval specified in Configure > SYSTEM > SCAN (by default, once every 24 hours).
Docker Hub, Docker Registry, Amazon Container Registry, Google Container Registry, and Alibaba Container Registry all support the Docker Registry version 2 API.
Specify an image tag. Leave this field blank to scan all tags (limited by the value in Cap).
Specify the credentials required to access the registry. If the credentials have already been created in the Prisma Cloud credential store, select it. If not, click
Public repositories on public registries (such as Docker Hub):Leave this field blank. No credentials are required.
AWS EC2 Container Registry:Use the IAM access keys for authentication. For more information, see Scan images on Amazon EC2 Container Registry (ECR).
Google Container Registry:Use the service account and JSON token. For more information, see Scan images on Google Container Registry.
Harbor Registry:Create a
Basic authenticationcredential. Credential has to be an
Administrator, being just a Project Admin does not work.
Registries that support token authentication (e.g. Quary, GitLab):Create a
Usernameis the name of the token and the token value is entered into the
Specify whether the image is built on a Windows or Linux base OS.
Specify the Defender to scan this registry.
Only Linux Defenders can scan Linux container images, and only Windows Defenders can scan Windows container images.
Number of scanners
Number of Defenders across which the scan job can be distributed. Increase the number of Defenders to increase throughtput and reduce scan time.
Specify the maximum number of images to scan in the given repository, sorted according to last modified date. That is, the most recently modified image in the repository is scanned first, followed by the image next most recently modified, and so on.
The Docker Registry API does not support directly querying for the most recently updated images. To handle your CAP setting, Prisma Cloud first polls the registry for all tags and manifests in the given repository to discover the last updated dates. This is a low overhead operation because images do not need to be downloaded. Prisma Cloud then sorts the results by date, and then scans the most recently updated images up to the limit specified by CAP. Even when CAP is set to a low number, you might still notice the Prisma Cloud UI polling the registry for data about the images in the repository.
To scan all images in a repository, set CAP to 0.
Version matching pattern
Customize sort order by values in the image tag. Specify a pattern from which a version or date can be extracted from the image tag. There are two use cases for specifying version matching patterns:
Specify patterns with strings, wildcards, timedate elements, and integers.
For image tags that match the pattern, the tag is split into its constituent parts. After all image tags are parsed, they’re ordered and capped according to the value set in Cap.
Ordering is best-effort. Tags that don’t conform to the pattern are ignored.
If both date and version are specified in your pattern, date takes precendence.
If the version matching pattern is left unspecified, Prisma Cloud orders images by last modified date.
Configure Prisma Cloud to scan a registry
To scan images in a registry, create a new registry scan rule.
Prerequisites:You have deployed at least one Defender in your environment.
- Open Console.
- Go toDefend > Vulnerabilities > Registry.
- ClickAdd registry settings.
Additional scan settings
Additional scan settings can be found under
Manage > System > Scan, where you can set the registry scan interval.
Manage > System > Scanpage has an option called
Only scan images with running containers. This option does NOT apply to registry scanning; all images targeted by your registry scanning rule will be scanned regardless of how
Only scan images with running containersis set.
For registry scanning in CRI/containerd-only environments: You must install a Linux Container Defender on a separate host.With the current CRI design, Prisma Cloud CRI Defenders can only scan running containers, but not images from a registry. In Docker environments, Prisma Cloud scans an image by creating a
scanning container, which is a running instance of the image to be scanned. In a CRI environment, the kubelet syncs the pods that exist on the localhost with those that exist on the api-server, deleting anything else, including Prisma Cloud’s scanning container pods. For this reason, Prisma Cloud doesn’t support registry scanning with CRI Defenders.
Recommended For You
Recommended videos not found.