Container Image Mapping
Introduction
The container image policy mapping editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of an image based on the registry, repository name, and tag of the image.
Create a New Image Container Mapping
From the Policies screen, click Mappings.
Under Container Images, click on the “Let’s add one!” button.
From the Add New Container Image Mapping dialog, add a name for the mapping, the policy for which the mapping will apply (added automatically), a registry, a repository, and a tag. You can optionally add an allowlist for the mapping.
Note Once you have created your first mapping, any mapping that is created afterwards will contain an additional optional field called Position. Image evaluation is performed sequentially from top to bottom. The system will stop at the first match, so the order or position of the mapping is important.
| Field | Description |
|---|---|
| Name | A unique name to describe the mapping. For example: “Mapping for webapps”. |
| Position | Set the order for the new mapping. |
| Rule Sets | Rule Sets in the policy to be used for evaluation. A drop down will be displayed allowing selection of a single policy. |
| Allowlist(s) | Optional: The allowlist(s) to be applied to the image evaluation. Multiple allowlists may be applied to the same image. |
| Registry | The name of the registry to match. Note the name should exactly match the name used to submit the image or repo for analysis. For example: foo.example.com:5000 is different to foo.example.com. Wildcards are supported. A single * would specify any registry. |
| Repository | The name of the repository, optionally including namespace. For example: webapp/foo. Wildcards are supported. A single * would specify any repository. Partial names with wildcards are supported. For example: web*/*. |
| Tag | Tags mapped by this rule. For example: latest. Wildcard are supported. A single * would match any tag. Partial names with wildcards are supported. For example: 2018*. |
Click OK to create the new mapping.
It is recommended that a final catch-all mapping is applied to ensure that all container images are mapped to a policy. This catch-all mapping should specify wildcards in the registry, repository, and tag fields.
Using the policy editor, you can set up different policies that will be used on different images based on use case. For example the policy applied to a web facing service may have different security and operational best practices rules than a database backend service.
Mappings are set up based on the registry, repository, and tag of an image. Each field supports wildcards. For example:
| Field | Example | Description |
|---|---|---|
| Registry | registry.example.com | Apply mapping to the registry.example.com |
| Repository | anchore/web\* | Map any repository starting with web in the anchore namespace |
| Tag | * | Map any tag |
In this example, an imaged named registry.example.com/anchore/webapi:latest would match this mapping, so the policy and allowlist configured for this mapping would be applied.
The mappings are applied in order, from top to bottom and the system will stop at the first match.
Note: The allowed images and denied images lists take precedence over the mapping. See Allowed / Denied Images for details.
Last modified September 16, 2024