Policy Mappings

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

1. From the Policies screen, click Mappings.

   

2. Under Container Images, click on the “Let’s add one!” button.

3. 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.

   

4. 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:

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.

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.

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

1. From the Policies screen, click Mappings.

   

2. Under Source Repositories, click on the “Let’s add one!” button.

3. From the Add New Source Repository Mapping dialog, add a name for the mapping, choose the policy for which the mapping will apply, a host (such as github.com), and a repository. 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.

   

4. Click OK to create the new mapping.

3 - Policy Mappings Example

Mappings in the policy are a set of rules, evaluated in order, that describe matches on an image, id, digest, or tag and the corresponding sets of policies and allowlists to apply to any image that matches the rule’s criteria.

Policies can contain one or more mapping rules that are used to determine which rule_sets and allowlists apply to a given image. They match images on the registry and repository, and finally be one of id, digest, or tag.

Examples

Example 1, all images match a single catch-all rule:

[
  {
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": ["defaultpolicy"],
    "allowlist_ids": ["defaultallowlist"]
  }
]

Example 2, all “official” images from DockerHub are evaluated against officialspolicy and officialsallowlist (made up names for this example), while all others from DockerHub will be evaluated against defaultpolicy and defaultallowlist , and private GCR images will be evaluated against gcrpolicy and gcrallowlist:

[
  {
    "registry": "docker.io",
    "repository": "library/*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": [ "officialspolicy"],
    "allowlist_ids": [ "officialsallowlist"]
  },
  {
    "registry": "gcr.io",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": [ "gcrpolicy"],
    "allowlist_ids": [ "gcrallowlist"]
  },
  {
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "rule_set_ids": [ "defaultpolicy"],
    "allowlist_ids": [ "defaultallowlist"]
  }
]

Example 3, all images from a unknown registry will be evaluated against defaultpolicy and defaultallowlist, and an internal registry’s images will be evaluated against a different set (internalpolicy and internalallowlist):

[
  {
    "registry": "myregistry.mydomain.com:5000",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "policy_ids": [ "internalpolicy"],
    "allowlist_ids": [ "internalallowlist"]
  },
  {
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*"},
    "policy_ids": [ "defaultpolicy"],
    "allowlist_ids": [ "defaultallowlist"]
  }
]

Using Multiple Policies and Allowlists

The result of the evaluation of the mapping section of a policy is the list of rule sets and allowlists that will be used for actually evaluating the image. Because multiple rule sets and allowlists can be specified in each mapping rule, you can use granular rule sets and allowlists and then combine them in the mapping rules.

Examples of schemes to use for how to split-up policies include:

• Different policies for different types of checks such that each policy only uses one or two gates (e.g. vulnerabilities, packages, dockerfile)
• Different policies for web servers, another for database servers, another for logging infrastructure, etc.
• Different policies for different parts of the stack: os-packages vs. application package