This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Policy Mappings

Introduction

The Mapping feature of the Policy Editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of a source repository or container image based on the registry, repository name, and tag of the image.

The policy editor lets you set up different policies that will be used on different images based on the 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 image named registry.example.com/anchore/webapi:latest would match this mapping, and 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 trusted images and denylisted images lists take precedence over the mapping. See Allowed / Denied Images for details.

If the policy includes no mappings, click the alt text to add your first mapping.

alt text

The Add a New Mapping dialog will be displayed and includes mandatory fields for Name, Policy, Registry, Repository and Tag. The Allowlist(s) field is optional.

alt text

Field	Description
Name	A unique name to describe the mapping. For example: `Mapping for webapps`.
Policies	Name of policy to use 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 source repository or container image evaluation. Multiple allowlists may be applied to the same source repository or container image.
Registry	The name of the registry to match. Note the name should exactly match the name used to submit the source repository or container image 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_`.

Each entry field includes an indicator showing if the current entry is valid alt text or has errors .

In the following screenshot you can see multiple policy mappings have been defined some of which include one or more allowlists.

alt text

Image evaluation is performed sequentially from top to bottom. The system will stop at the first match so particular care should be paid to the ordering.

Mappings can be reordered using the alt text buttons which will move a mapping up or down the list. Mappings may be deleted using the button.

It is recommended that a final catch all mapping is applied to ensure that all images are mapped to a policy. This catch-all mapping should specify wildcards in the registry, repository, and tag fields.

1 - 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.
Click Add New Mapping, then select Container Images to create the mapping from a container image.
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 and set the position for the mapping.
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.

The empty policy includes no mappings. Click Let’s add one! to add your first mapping.
From Add a New Container Image Mapping, fill in the mandatory fields for Name, Policy, Registry, Repository and Tag. The Allowlists and Position fields are optional. See the following table for more information about these fields.

alt text

Field	Description
Name	A unique name to describe the mapping. For example: “Mapping for webapps”.
Position	Set the order for the new mapping.
Policies	Name of policy to use 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`.

Each entry field includes an indicator showing if the current entry is valid alt text or has errors .

Image evaluation is performed sequentially from top to bottom. The system will stop at the first match, so particular care should be paid to the ordering.

Mappings can be reordered using the alt text buttons which will move a mapping up or down the list. Mappings may be deleted using the button.

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.

2 - Source Repository Mapping

The source repository policy mapping editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of a source repository based on the host, and repository name.

alt text

Using the policy editor organizations can set up multiple policies that will be used on different source repositories 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 Host and Repository of a source repository. Each field supports wildcards.

Create a Source Repository Mapping

From the Policies screen, click Mappings.
Click Add New Mapping, then select Source Repositories. By selecting source repositories, you are saying you want the new policy rule to apply to a source repository.
From the Add New Source Repository Mapping dialog, add a name for the mapping, choose the policy for which the mapping will apply, the position (optional) for the new mapping, a host (such as github.com), and a repository. You can optionally add an allowlist and set the position for the mapping.

Field	Description
Name	A unique name to describe the mapping.
Position	Optional: Set the order for the new mapping.
Policies	Name of policy to use 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 source repository evaluation. Multiple allowlists may be applied to the same source
Host	The name of the source host to match. For example: `github.com`.
Repository	The name of the source 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/*`.

Click OK to create the new mapping.