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.

A mapping has:

  • Registry - The registry url to match, including wildcards (e.g. ‘docker.io’, ‘quay.io’, ‘gcr.io’, ‘*’)
  • Repository - The repository name to match, including wildcards (e.g. ’library/nginx’, ‘mydockerhubusername/myrepositoryname’, ’library/*’, ‘*’)
  • Image - The way to select an image that matches the registry and repository filters
    • type: how to reference the image and the expected format of the ‘value’ property
      • “tag” - just the tag name itself (the part after the ‘:’ in a docker pull string: e.g. nginx:latest -> ’latest’ is the tag name)
      • “id” - the image id
      • “digest” - the image digest (e.g. sha256@abc123)
    • value: the value to match against, including wildcards

For example:

FieldExampleDescription
Registryregistry.example.comApply mapping to the registry.example.com
Repositoryanchore/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.

Unlike other parts of the policy, Mappings are evaluated in order and will halt on the first matching rule. This is important to understand when combined with wildcard matches since it enables sophisticated matching behavior.

Note: The trusted images and denylisted images lists take precedence over the mapping. See Allowed / Denied Images for details.

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.

Last modified June 11, 2024