Managing Policies

Policies

The Policy tab 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. AnchoreCTL, API, 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: Policies which are not marked as Active can still be explicitly requested as part of a policy evaluation.

If multiple users are accessing Policies, or if policies are being added or removed through the API or AnchoreCTL, then you may update the list of policies by clicking on the Refresh the Policy List button.

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

# anchorectl policy list

Adding and Editing Policies

You can add a new policy with custom rule rests within the Policies tab.

1. Click Create New Policy and provide a name and description.

2. Click Add New Rule Set and select Source Repository if you want the new policy to apply to a source, or select Container Image to have the policy apply to an image.

3. You can configure each rule set under the Edit option. Start by selecting an item from the Gate dropdown list, where each item represents a category of policy checks.

   Note: If you are creating a policy rule for a source repository, only vulnerabilities are available.

4. After selecting a gate item, hover over the (i) indicator next to Gate to see additional descriptive details about the gate you have selected.

5. Click the Triggers drop down and select a specific check that you want associated with this item, such as package, vulnerability data unavailable, and so on. Triggers may have parameters, some of which may be optional.

   If any optional parameters are associated with the trigger you select, these will also be displayed in an additional field where they can be added or removed. Optional parameters are described in more detail in the next section.

6. Select an action to apply to the policy rule. Choose STOP, WARN, or GO. The action options are only displayed once all required parameters have been provided, or if no mandatory parameters are required. Once an action has been selected, the rule is added to the main list of rules contained in the policy.

7. Click Save and Close.

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

Note: Adding a policy will not automatically make it active. You will need to activate the policy using the activate command.

The policy activate command can be used to activate a policy. The policy is referenced using its unique POLICY ID which can be retrieved using the policy list command.

# anchorectl policy activate 2c53a13c-1765-11e8-82ef-23527761d061
 ✔ Activate policy
┌─────────────────┬──────────────────────────────────────┬────────┬──────────────────────┐
│ NAME            │ POLICY ID                            │ ACTIVE │ UPDATED              │
├─────────────────┼──────────────────────────────────────┼────────┼──────────────────────┤
│ Default policy  │ 2c53a13c-1765-11e8-82ef-23527761d061 │ true   │ 2023-10-25T20:50:17Z │
└─────────────────┴──────────────────────────────────────┴────────┴──────────────────────┘

Upload a Policy

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 a policy file 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

Copy an Existing Policy

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

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.

Download a Policy

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

Delete a Policy

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

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

Example Gate Configuration

The following example shows a sophisticated policy check. The metadata gate has a single trigger that allows checks to be performed against various attributes of an image, including image size, architecture, and operating system distribution:

The Attribute parameter drop-down includes a number of attributes taken from image metadata, including the operating system distribution, number of layers, and architecture of the image (AMD64, ARM, and so forth).

Once an attribute has been selected, the Check dropdown is used to create a comparison expression.

The type of comparison varies based on the attribute. For example the numeric comparison operators such as >, <, >= would be relevant for numeric field such as size, while other operators such as not in may be useful for querying data field such as distro.

In this example, by entering rhel centos oracle in the Value field, our rule will check that the distro (that is, the operating system) under analysis is not RHEL, Centos, or Oracle.

Optional Parameters

If a trigger has optional parameters, they will be automatically displayed in the policy editor, and an editable field next to the Triggers drop-down will show all the current selections.

You can remove unneeded optional parameters by clicking the X button associated with each entry in the Optional Parameters list, or by clicking the X button within each associated parameter block.

If an optional parameter is removed, it can be reapplied to the rule by clicking the Optional Parameters field and selecting it from the resulting dropdown list.