Policies

1 - Policy

Introduction

The Policy Manager page shows a list of your policies. You can see the policy names, IDs, descriptions, when they were last updated, and which policies are active. From this view you can also create or add policies, as well as edit, copy, delete, or download policies.

Create a New Bundle.

Create a new policy and add it to the list of policies.

1. To add a new policy , click Create New Bundle.

   

2. Enter a unique name, along with an optional (but recommended) description for your new policy.

   

3. Click OK. Notice that when you create a new policy, it is populated with two policies. DefaultPolicy is for a container image, and DefaultSourcePolicy is for a source repository.

   

4. Start adding rules to your new policy. You can edit existing policies, add additional policies, add new mappings or edit existing mapping rules from either source repositories or container images, set up allow lists, or allowed/denied images for your policy.

Refresh a Policy

Click Refresh the Bundle Data if multiple users are accessing the Policy Manager, or if policy items are being added or removed through the API or AnchoreCTL then you may update the list of policies.

Rename a Policy

1. Click Edit Name to rename the policy.

   

2. Enter the new name.

3. Click the green check to rename the policy.

   

Policy Status

As described in the Managing Policies page, only one policy may be set as active (default). The management view for each policy includes a status indicator to represent the current status.

This label shows that the policy is active and that changes will have an immediate effect on your policy evaluation.

This label shows that the policy is not currently active and that changes can be made without altering the policy evaluation output.

Navigate Back to the Bundle List

Click Policies, or use the browsers navigation buttons to navigate back to the list of Policies.

Edit Bundle Content

You can edit the components of the policy at any time, including the policies, allowlists, mappings, and allowed or denied images.

Policies tab:

Edit or add policies and policy rules. See the Policies section for more information.

Allowlists tab:

Edit or add allowlists associated with the policy. See the Allowlists section for more information.

Mappings tab:

Edit or add mappings and mapping rules. See the Policy Mappings section for more information.

Allowed / Denied Images tab:

Edit or add images that you want allowed or denied in a policy. Each of the policy elements can be edited by selecting the appropriate tab in the navigation bar. See the Allowed / Denied Images section for more information.

2 - 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:

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 to add your first mapping.

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.

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

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

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

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

   

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 and set the position for the mapping.

   

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

5. The empty policy includes no mappings. Click Let’s add one! to add your first mapping.

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

Each entry field includes an indicator showing if the current entry is valid 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 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.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.

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

1. From the Policies screen, click Mappings.

   

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

   

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

   

4. Click OK to create the new mapping.

3 - Managing Policies

What is a Policy

A policy container includes the following elements:

• Rule Sets

  A policy is made up from a set of rules that are used to perform an evaluation on a source repository or container image. These rules can include checks on security vulnerabilities, package allowlists, denylists, configuration file contents, presence of credentials, manifest changes, exposed ports, or any user defined checks. These policies can be deployed site wide or customized for specific source repositories, container images, or categories of applications. A policy may contain one or more named rule sets.

• Allowlists

  An allowlist contains one or more exceptions that can be used during policy evaluation. For example allowing a CVE to be excluded from policy evaluation. A policy may contain multiple allowlists.

• Mappings

  A policy mapping defines which policies and allowlists should be used to perform the policy evaluation of a given source repository or container image. A policy may contain multiple mappings including wildcard mappings that apply to multiple elements.

• Allowed Image

  An allowed image defines one or more images that will always pass policy evaluation regardless of any policy violations. Allowed images can be specified by name, image ID, or image digest. A policy contains a single list of allowed images.

• Denied Images

  A denied Images list defines one or more images that will always fail policy evaluation. Denied images can be specified by name, image ID, or image digest. A policy contains a single list of denied images.

Policies

The Policy Manager displays a list of policies that are loaded in the system. Each policy has a unique name, unique ID (UUID), and an optional description.

Anchore Enterprise supports multiple policies. The Anchore API, CLI, and CI/CD plugins support specifying a policy when requesting an source repository or container image evaluation. For example, the development team may use a different set of policy checks than the operations team. In this case, the development team would specify their policy ID as part of their policy evaluation request.

If no policy ID is specified, then Anchore Enterprise will use the active policy which can be considered as the default policy. Only one policy can be set as default/active at any time. This policy will be highlighted with a green ribbon.

Note: policiess which are not marked as Active can still be explicitly requested as part of a policy evaluation.

If multiple users are accessing the Policy Manager, or if policy are being added or removed through the API or AnchoreCTL, then you may update the list of policies using the clicking Refresh the Bundle Data.

The following command can be run to list policies using AnchoreCTL:

# anchorectl policy list

Create a New Policy

1. To create a new, empty policy, click Create New Policy.

2. Add a name for the policy. This name should be unique.

3. Optional: You can add a description.

The following example shows a policy called test. Notice the unique Bundle ID (UUID) that was automatically created by Anchore Enterprise.

Upload a Policy Bundle

If you have a JSON document containing an existing policy, then you can upload it into Anchore Enterprise.

1. Click Add a Local File to upload or paste a valid policy JSON.

2. You can drag Policy Bundle files into the dropzone. Or, you can click the “Add a Local File” button to add from the local file system.

3. Click OK to perform a validation on a policy. Only validated policies may be stored by Anchore Enterprise.

Note: The following command can be run to add policies using AnchoreCTL

# anchorectl policy add --input /path/to/my/policy/bundle.json

Edit a Policy Bundle

You can edit existing policies at any time, including the policies, allowlists, mappings, and allowed or denied images.

1. Click Edit Policy to open the policy viewer which has the following options.

• Policies tab: Edit or add policies and policy rules. See the policies section for more information.

• Allowlists tab: Edit or add allowlists associated with the policy.

• Mappings tab: Edit or add mappings and mapping rules. See the Policy Mappings section for more information.

• Allowed / Denied Images tab: Edit or add images that you want allowed or denied in a policy. Each of the policy elements can be edited by selecting the appropriate tab in the navigation bar.

Copy an Existing Policy Bundle

If you already have a policy that you would like to use as a base for another policy, you can make a copy of it, give it a new name, and then work with the policies, mappings, allowlists, and allowed or denied images.

1. From the Tools list, select Copy Bundle.

2. Enter a unique name for the copy of the policy.

3. Optional: You can add a description to explain the new policy. This is recommended.

4. Click OK to copy the policy.

Delete a Policy Bundle

If you no longer use a policy, you can delete it. An active (default) policy cannot be deleted. To delete the active policy first you must mark another policy as active.

1. From the Tools menu, select Delete Bundle.

2. Click Yes to confirm that you want to delete the policy.

*Warning: Once the policy is deleted, you cannot recover it.

Note: Use the following command to delete a policy using AnchoreCTL. The policy must be referenced by its UUID. For example:

# anchorectl policy delete 4c1627b0-3cd7-4d0f-97da-00be5aa835f4

Download a Policy Bundle

1. From the Tools menu, select Download to JSON.

2. The JSON file is downloaded just like any other downloaded file to your computer. Save the downloaded JSON file to your location of choice.

Note: Use the following command to download a policy using AnchoreCTL. The policy must be referenced by its UUID. For example:

# anchorectl policy get 4c1627b0-3cd7-4d0f-97da-00be5aa835f4 --detail > policy.json

4 - Alowed / Denied Images

Introduction

You can add or edit allowed or denied images for your policy rules.

The Allowed / Denied Images tab is split into the following two sub tabs:

• Allowed Images: A list of images which will always pass policy evaluation irrespective of any policies that are mapped to them.

• Denied Images: A list if images which will always fail policy evaluation irrespective of any policies that are mapped to them.

  

Add an Allowed or Denied Image to Bundle

1. If you do not have any allowed or denied images in your policy, click Let’s add one! to add them.

The workflow for adding Allowed or Denied images is identical.

2. Images can be referenced in one of the following ways:

• By Name: including the registry, repository and tag. For example: docker.io/library/centos:latest

  The name does not have to be unique but it is recommended that the identifier is descriptive.

  

• By Image ID: including the full image ID. For example: e934aafc22064b7322c0250f1e32e5ce93b2d19b356f4537f5864bd102e8531f

  

  The full Image ID should be entered. This will be a 64 hex characters. There are a variety of ways to retrieve the ID of an image including using the anchorectl, Anchore UI, and Docker command.

• By Image Digest: including the registry, repository and image digest of the image. For example: docker.io/library/centos@sha256:989b936d56b1ace20ddf855a301741e52abca38286382cba7f44443210e96d16

  

3. Click OK to add the Allowed or Denied Image item to your policy.

See the following sections for more details about the Name, Image ID, and Image Digest.

For most use cases, it is recommended that the image digest is used to reference the image since an image name is ambiguous. Over time different images may be tagged with the same name.

If an image appears on both the Allowed Images and Denied Images lists, then the Denied Image takes precedence and the image will be failed.

Note: See Evaluating Images against Policies for details on image policy evaluation.

The Allowed Images list will show a list of any allowed images defined by the system includes the following fields:

• Allowlist Name A user friendly name to identify the image(s).

• Type Describes how the image has been specified. By Name, ID, or Digest.

• Image The specification used to define the image.

• Actions The actions you can set for the allowed image.

  The button can be used to copy the image specification into the clipboard.

  An existing image may be deleted using the or edited by pressed the button.

Adding an Image by Image ID

The full Image ID should be entered. This will be a 64 hex characters. There are a variety of ways to retrieve the ID of an image including using the anchorectl, Anchore UI and Docker command.

Using AnchoreCTL

$ anchorectl image get library/debian:latest | grep ID
ID: 8626492fecd368469e92258dfcafe055f636cb9cbc321a5865a98a0a6c99b8dd

Using Docker CLI

$ docker images --no-trunc debian:latest

REPOSITORY          TAG                 IMAGE ID                                                                  CREATED             SIZE
docker.io/debian    latest              sha256:8626492fecd368469e92258dfcafe055f636cb9cbc321a5865a98a0a6c99b8dd   3 days ago          101 MB

By default the docker CLI displays a short ID, the long ID is required and it can be displayed by using the –no-trunc parameter.

Note: The algorithm (sha256:) should not be entered into the Image ID field.

Adding an Image by Digest

When adding an image by Digest the following fields are required:

• Registry. For example: docker.io

• Repository. For example: library/debian

• Digest. For example: sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f

The full identifier for this image is: docker.io/library/debian@sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f

Note: The tag is not used when referencing an image by digest.

There are a variety of ways to retrieve the digest of an image including using the anchorectl, Anchore UI, and Docker command.

Using AnchoreCTL

$ anchorectl image get library/debian:latest | grep Digest
Digest: sha256:7df746b3af67bbe182a8082a230dbe1483ea1e005c24c19471a6c42a4af6fa82

Using Docker CLI

$ docker images --digests debian
REPOSITORY          TAG                 DIGEST                                                                    IMAGE ID            CREATED             SIZE
docker.io/debian    latest              sha256:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f   8626492fecd3        1 days ago          101 MB

Note: Unlike the Image ID entry, the algorithm (sha256:) is required.

Adding an Image by Name

When adding an image by Name, the following fields are required:

• Registry. For example: docker.io

• Repository. For example: library/debian

• Tag. For example: latest

Note: Wild cards are supported, so to trust all images from docker.io you would enter docker.io in the Registry field, and add a * in the Repository and Tag fields.

5 - Allowlists

Introduction

An allowlist contains one or more exceptions that can be used during policy evaluation. For example allowing a CVE to be excluded from policy evaluation.

The Allowlist tab shows a list of allowlists present in the policy. Allowlists are an optional element of the policy, and a policy may contain multiple instances.

Add a New Allowlist

1. Click Add New Allowlist to create a new, empty allowlist.

2. Add a name for the allowlist. A name is required and should be unique.

3. Optional: Add a description. A description is recommended. Often the description is updated as new entries are added to the allowlist to explain any background. For example “Updated to account for false positive in glibc library”.

   

Upload or Paste an Allowlist

If you have a JSON document containing an existing allowlist, then you can upload it into Anchore Enterprise.

1. Click Upload / Paste Allowlist to upload an allowlist. You can also manually edit the allowlist in the native JSON format.

   

2. Drag an allowlist file into the dropzone. Or, you can click the “Add a Local File” button and load it from a local filesystem.

3. Click OK to upload the allowlist. The system will perform a validation for the allowlist. Only validated allowlists may be stored by Anchore Enterprise.

Copying a Allowlists

You can copy an existing allowlist, give it a new name, and use it for a policy evaluation.

1. From the Tools drop down, select Copy Allowlist.

   

2. Enter a unique name for the allowlist.

3. Optional: Add a description. This is recommended. Often the description is updated as new entries are added to the allowlist to explain any background.

   

Downloading Allowlists

You can download an existing allowlists as a JSON file. From the Tools drop down, click Download to JSON.

Editing Allowlists

The Allowlists editor allows new allowlist entries to be created, and existing entries to be edited or removed.

1. Choose an allowlist to edit, then click Edit.

   

   Anchore Enterprise supports allowlisting any policy trigger, however the
   Allowlists editor currently supports only adding Anchore Security checks,
   allowing vulnerabilities to be allowlisted.

2. Choose a gate for the allowlist, for example, vulnerabilities.

   

   A vulnerabilities allowlists entry includes two elements: A CVE / Vulnerability Identifier and a Package.

3. Enter a CVE / Vulnerability Identifier. The CVE/Vulnerability Identifier field contains the vulnerability that should be matched by the allowlists. This can include wildcards.

   

   For example: CVE-2017-7246. This format should match the format of the CVEs shown in the image vulnerabilities report. Wildcards are supported, however, care should be taken with using wildcards to prevent allowlisting too many vulnerabilities.

4. Enter a package. The package name field contains the package that should be matched with a vulnerability. For example libc-bin.

   

   Wildcards are also supported within the Package name field.

   An allowlists entry may include entries for both the CVE and Package field to specify an exact match, for example: Vulnerability: CVE-2005-2541 Package: tar.

   In other cases, wildcards may be used where a multiple packages may match a vulnerability. For example, where multiple packages are built from the same source. Vulnerability: CVE-2017-9000 Package: bind-*

   In this example the packages bind-utils, bind-libs and bind-license will all be allowlisted for CVE-2017-9000.

   Special care should be taken with wildcards in the CVE / Vulnerability Identifier field. In most cases a specific vulnerability identifier will be entered. In some exceptional cases a wild card in this field may be appropriate.

   A good example of a valid use case for a wildcard in the CVE / Vulnerability Identifier field is the bind-license package. This package include a single copyright text file and is included by default in all CentOS:7 images.

   CVEs that are reported against the Bind project are typically applied to all packages built from the Bind source package. So when a CVE is found in Bind it is common to see a CVE reported against the bind-license package. To address this use case it is useful to add an allowlists entry for any vulnerability (*) to the bind-license package.

5. Optional: Click to edit an allowlist.

6. Optional: Click Remove to delete an allowlist.

7. Ensure that all changes are saved before exiting out of the Edit Allowlists Items Page. At that point the edits will be sent to Anchore Enterprise.

6 - Testing Policies

Introduction

The Evaluation Preview feature allows you to perform a test evaluation on an image to verify the mapping, policies and allowlists used to evaluate an image.

To test an image you should enter the name of the image, optionally including the registry if the image is not stored on docker.io In the example below an evaluate was requested for library/debian:latest because no registry was specified the default, docker.io registry was used.

Here we can see that the image was evaluated against the policy named “anchore_security_only” and the evaluate failed, the final action was Stop.

Clicking the “View Policy Test Details” will show a more detailed report.

The image was evaluating using the mapping named and the evaluation failed as the image was found in a denylist.

The next line explains that the image had been denylisted by the No centos denylist rule, however if the image was not denylisted it would only have produced a warning instead of a failure.

The subsequent table lists the policy checks that resulted in any Warning or Stop (failure) checks.

The policy checks are performed on images already analyzed and recorded in Anchore Enterprise. If an image has been added to the system but has not yet completed analysis then the system will display the following error:

If the evaluation test is re-run after a few minutes the image will likely have completed analysis and a policy evaluation result will be returned.

If the image specified has not been analyzed by the system and has not been submitted for analysis then the following error message will be displayed.