This is the multi-page printable view of this section. Click here to print.
The Anchore Enterprise UI client can be used to scan repositories and images, edit policies, manage users accounts and roles via RBAC, and view and generate security vulnerability and policy evaluation reports.
If you have not installed the Anchore Enterprise UI, please refer to the installation guide.
To jump to a particular guide, select from the following below:
The Dashboard is your configurable landing page where insights into the collective status of your container image environment can be displayed through various widgets. Utilizing the Enterprise Reporting Service, the widgets are hydrated with metrics which are generated and updated on a cycle, the duration of which is determined by application configuration.
Note: Because the reporting data cycle is configurable, the results shown in this view may not precisely reflect actual analysis output at any given time.
For more information on how to modify this cycle or the Reporting Service in general, please refer to the Reporting Service.
The following sections in this document describe how to add widgets to the dashboard and how to customize the dashboard layout to your preference.
To add a new widget, click the Add New Widget button present in the Dashboard view. Or, if no widgets are defined, click the Let’s add one! button shown.
Upon doing so, a modal will appear with several properties described below:
| Property | Description |
|---|---|
| Name | The name shown within the Widget’s header. |
| Mode | ‘Compact’ a widget to keep data easily digestable at a glance. ‘Expand’ to view how your data has evolved over a configurable time period. |
| Collection | The collection of tags you’re interested in. Toggle to view metrics for all tags - including historical ones. |
| Time Series Settings | The time period you wish to view metrics for within the expanded mode. |
| Type | The category of information such as ‘Vulnerabilities’ or ‘Policy Evaluations’ which denotes what metrics are capable of being shown. |
| Metrics | The list of metrics available based on Type. |
Once you enter the required properties and click OK, the widget will be created and any metrics needed to hydrate your Dashboard will be fetched and updated.
Note: All fields except Type are editable by clicking the button shown on the top right of the header when hovering over a widget.
The Reporting Service at its core aggregates data on resources across accounts and generates metrics. These metrics, in turn, fuel the Dashboard’s mission to provide actionable items straight to the user - that’s you!
Leverage these results to dive into the exact reason for a failed policy evaluation or the cause and fix of a critical vulnerability.
Vulnerabilities are grouped and colored by severity. Critical, High, and Medium vulnerabilities are included by default but you can toggle which ones are relevant to your interests by clicking the button.
Clicking one of these metrics navigates you to a view (shown below) where you can browse the filtered set of vulnerabilities matching that severity.
For more info on a particular vulnerability, click on its corresponding button visible in the Links column. To view the exact tags affected, drill down to a specific repository by expanding the arrows ().
View that tag’s in-depth analysis by clicking on the value within its Image Digest column.
Policy Evaluations are grouped by their evaluation outcome such as Pass or Fail and can be further filtered by the reason for that result. All reasons are included by default but as with other widget properties, they can be edited by clicking the button.
Clicking one of these results navigates you to a view (shown below) where you can browse the affected and filtered set of tags.
Dig down to a specific tag by expanding the arrow () shown on the left side of the row.
Navigate using the Image Digest value to view even more info such as the specific policy being triggered and what exactly is triggering it. If you’re interested in viewing the contents of your policy, click on the Policy ID value.
After populating your Dashboard with various widgets, you can easily modify the layout by using some methods explained below:
Click this icon shown in the top right or the header of a widget to Drag and Drop it into a new location.
Click this icon shown in the top right of a widget to Expand it and include a graphical representation of how your data has evolved over a time period of your choice.
Click this icon shown in the top right of a widget to Compact it into an easily digestable view of the metrics you’re interested in.
Click this icon shown in the top right of a widget to Delete it from the dashboard.
Administrators and specially-entitled standard users are offered the ability to context switch between the image analysis data contexts of different accounts. This capability allows you to view the analysis data held inside a different account while still retaining your own user profile configuration.
When you switch data context, the data-oriented aspects of the application will change but the qualities specific to your original account—herein referred to as your actual account—remain the same. Administrators keep their original permission set and have full control within the switched account. The account availability and associated permission set for standard users is decided by the role configuration of their switching entitlement, and these roles can be additionally set to differ per account.
This feature allows users to gain insights into multiple datasets, can be used by administrators for troubleshooting purposes or to make ad-hoc modifications to the data-oriented aspects of any account, and provides standard users with an additional level and vector of access control.
This following sections in this document describes how to switch and reset data contexts—both as an administrator and as a standard user—and how administrators can assign this capability to standard users.
Context switching as as an administrator is available without prior configuration, and only requires that an account other than your own be available. When you click the account button in the top-right of the screen you are presented with a menu that contains an entry called Switch Account Data Context, which will be enabled when one or more accounts other than your own are present.
Clicking this item displays a submenu that describes all currently available accounts—both active and disabled—into which you can switch context:
Your home account is represented by the label Actual. If an account is disabled, this is indicated by the label Disabled (note that only administrators can context switch into disabled accounts). The account category—administrator or standard user—is indicated by the user-type icon.
Your current data context is represented by an entry with an emphasized title and checkmark prefix. When you click an entry for a different account, the application view will switch to use the data provided by this new context. The account button and dropdown items are similarly updated to reflect this change:
You will also notice a change to the background color of the main view, which serves as a reminder that your current data context is now different than the one provided by your actual account. In addition, a button is now present on the navigation bar that allows you to immediately revert to your actual data context when clicked (you can of course also use the menu to do this):
In the above example, the analysis information now presented is exactly what a user of the standard account would see in their actual account. As an administrator, you are now free to browse and interact with this data, add tags or repositories for analysis, create policies etc., and there are no permission restrictions on any of these operations.
Note: only the analysis data context has switched, and this new state does not extend to application data items such a private registry configurations.
Non-administrative users can also switch context if this capability has been conferred upon them by an administrator within an RBAC-enabled environment.
When you add a new standard user (or modify an existing one) you can optionally associate them with one or more additional accounts, providing those accounts are not currently disabled. The Add a New User dialog, which is accessed from within the account editor in the Configuration > Accounts view, is shown below:
Note: If an account is currently active and available for addition, but is subsequently disabled, the standard user will not be able to switch into that account.
For each associated account you must also provide one or more RBAC roles that determine how the standard user can interact with that account after they have switched context:
For example, a user may have full-control within their actual account, but could be restricted to read-only operations after switching context. You can provide multiple different roles for different accounts, but you must provide at least one role per account association:
Account associations can also be removed by clicking the X adjacent to each role list, or by removing the labels directly from the Associate Account(s) dropdown control.
Once you are satisfied with the user configuration, click OK to create (or update) these associations. The standard user will now be able to switch account data context using the same procedure as the one described for administrators, presented earlier in this document.
The Events tab is your gateway to current and historical activity happening in your system. View various events such as policy evaluation and vulnerability updates, system errors, feed syncs, and more.
The following sections in this document describe how to view event details, how to filter for specific events you’re interested in, and how to manage events with bulk deletion.
In order to view events, navigate to the Events & Notifications > View Events tab. By default, the most recent activity (up to 1000 events) is shown and is automatically updated for you every 5 minutes. Note that if you have applied any filters through the search bar, your results will need to be refreshed manually.
Top-level details such as the event’s level (whether it’s an INFO or ERROR event), type, message, and affected resource is shown. Dig in to a specific event by clicking View Details under its Actions column to expand the row.
Additional information such as the origininating service and host ID are available in the expanded row. Any details given by the service are also provided in JSON format to view or copy to clipboard.
Often, you might want to search for a specific event type or events that happened after a certain time. In this case, use the Search Events bar near the top of the page to select a filter to search on. These include:
Once you have selected and populated the filter fields you’re interested in, click Apply Filters to search and show those filtered results.
An alternative way to filter your results is through the in-table filter input. Note that this only applies against any data already fetched. To increase what you’re filtering on, click Fetch More near the top-right of the table for up to an additional 1000 items.
To remove any filters and reset to the default view, click Clear Filters.
To assist with event management, event deletion has been added in the Enterprise 2.3 release.
Deleting individual events can be done simply through clicking Delete under the Actions column and selecting Yes to confirm. Note that after deletion, events are not recoverable.
Multi-select is available for deleting multiple events at a time. Upon selecting an event using the checkbox in the far-left column, a toolbar-like component will slide in at the bottom of the table. The number of events selected is shown along with the selection type, Clear Selection, and Delete Events options.
Checking the box in the header will select all events within that page.
By default, it is viewed as a Custom selection. Choosing to select All Retrieved events auto-selects everything already fetched and present in the table (i.e. if a filter is applied, events not matching the filter are not selected but will be upon removal of the filter). In this state, deselecting an item will trigger a custom selection again.
Selecting All events will again auto-select all events already fetched and present in the table but while applying a filter may modify what’s viewable, this option is solely for clearing the entire backlog of events - including those not shown. In this state, deselecting an item will also trigger a custom selection.
Once you have selected the events you wish to remove, click Delete Events to open a modal and review up to 50 items. Any events you don’t wish to delete anymore can be deselected as well. To continue with removal, click Yes to confirm and start the process.
Note that events are account-wide and that any events removed will be mirrored across all users in the account.
In this section you will learn how to submit images for analysis using the user interface, and how to execute a bulk removal of pending items or previously-analyzed items from within a repository group.
Note: Only administrators and standard users with the requisite role-based access control permissions are allowed to submit items for analysis, or remove previously analyzed assets.
From within an authenticated session, click the Image Analysis button on the navigation bar:
You will be presented with the Image Analysis view. On the right-hand side of this view you will see the Analyze Repository and Analyze Tag buttons:
These controls allow you to add entire repositories or individual items to the Anchore analysis queue, and to also provide details about how you would like the analysis of these submissions to be handled on an ongoing basis. Both options are described below in the following sections.
After clicking the Analyze Repository button, you are presented with the following dialog:
The following fields are required:
docker.iolibrary/centosProvided below these fields is the Watch Tags in Repository configuration toggle. By default, when One-Time Tag Analysis is selected all tags currently present in the repository will be analyzed; once initial analysis is complete the repository will not be watched for future additions.
Setting the toggle to Automatically Check for Updates to Tags specifies that the repository will be monitored for any new tag additions that take place after the initial analysis is complete. Note that you are also able to set this option for any submitted repository from within the Image Analysis view.
Once you have populated the required fields and click OK, you will be notified of the overhead of submitting this repository by way of a count that shows the maximum number of tags detected within that repository that will be analyzed:
You can either click Cancel to abandon the repository analysis request at this point, or click OK to proceed, whereupon the specified repository will be flagged for analysis.
Max image size configuration applies to repositories added via UI. See max image size
After clicking the Analyze Tag button, you are presented with the following dialog:
The following fields are required:
docker.iolibrary/centoslatestNote: Depending upon where the dialog was invoked, the above fields may be pre-populated. For example, if you clicked the Analyze Tag button while looking at a view under Image Analysis that describes a previously-analyzed repository, the name of that repository and its associated registry will be displayed in those fields.
Some additional options are provided on the right-hand side of the dialog:
Watch Tag—enabling this toggle specifies that the tag should be monitored for image updates on an ongoing basis after the initial analysis
Force Reanalysis—if the specified tag has already been analyzed, you can force re-analysis by enabling this option. You may want to force re-analysis if you decide to add annotations (see below) after the initial analysis. This option is ignored if the tag has not yet been analyzed.
Add Annotation—annotations are optional key-pair values that can be added to the image metadata. They are visible within the Overview tab of the Image Analysis view once the image has been analyzed, as well as from within the payload of any webhook notification from Anchore that contains image information.
Once you have populated the required fields and click OK, the specified tag will be scheduled for analysis.
Max image size configuration applies to images added via UI. See max image size
Note: Anchore will attempt to download images from any registry without requiring further configuration. However, if your registry needs authentication then the corresponding credentials will need to be defined. See Configuring Registries for more information.
Shown below is an example of a repository view under Image Analysis:
From a repository view you can carry out actions relating to the bulk removal of items in that repository. The Analysis Cancellation / Repository Removal control is provided in this view, adjacent to the analysis controls:
After clicking this button you are presented with the following options:
Cancel Images Currently Pending Analysis—this option is only enabled if you have one or more tags in the repository view that are currently scheduled for analysis. When invoked, all pending items will be removed from the queue. This option is particularly useful if you have selected a repository for analysis that contains many tags, and the overall analysis operation is taking longer than initially expected.
Note: If there is at least one item present in the repository that is not pending analysis, you will be offered the opportunity to decide if you want the repository to be watched after this operation is complete.
Remove Repository and Analyzed Items—In order to remove a repository from the repository view in its entirety, all items currently present within the repository must first be removed from Anchore. When invoked, all items (in any state of analysis) will be removed. If the repository is being watched, this subscription is also removed.
Anchore Enterprise allows you to navigate through your Kubernetes clusters to quickly and easy asses your vulnerabilities, apply policies, and take action on them. You’ll need to configure your clusters for collection before being able to take advantage of these features. See our installation instructions to get setup.
Users can opt to automatically scan all the images that are deployed to a specific cluster or namespace. This is helpful to monitor your overall security posture in your runtime and enforce policies. Before opting to subscribe to a new cluster, it’s important to ensure you have proper credentials saved in Anchore to pull the images from the registry. Also watching a new cluster can create a considerable queue of images to work through and impact other users of your Anchore Enterprise deployment.
The charts at the top of the UI provide key contextual information about your runtime. Upon landing on the page you’ll see a summary of your policy evaluations and vulnerabilities for all your clusters. Drilling down into a cluster or namespace will update these charts to represent the data for the selected cluster and/or namespace. Additionally, users can select to only view clusters or namespaces with the selected filters. For example selecting only high and critical vulnerabilities will only show the clusters and/or namespaces that have those vulnerabilities.
In addition to navigating your runtime inventory by clusters and namespaces, users can opt to view the images or vulnerabilities across. This is a great way to identify vulnerabilities across your runtime and asses their impact.
Another important aspect of the Kubernetes Inventory UI is the ability to assess how a vulnerability in a container images impacts your environment. For every container when you see a note about it usage being seen in particular cluster and X more… you will be able to mouse over the link for a detailed list of where else that container image is being used. This is fast way to determine the “blast-radius” of a vulnerability.
Due to the processing required to generate the data used by the Kubernetes Inventory UI, the results displayed may not be fully up to date. The overall delay depends on the configuration of how often inventory data is collected, and how frequently your reporting data is refreshed. This is similar to delays present on the dashboard.
The Kubernetes Inventory is only available for an account’s default policy. You may want to consider setting up an account specifically for tracking your Kubernetes Inventory and enforcing a policy.
The Lightweight Directory Access Protocol (LDAP) is a standardized and widely-used client-server protocol for accessing directory information, and can be enabled in Anchore Enterprise Client to authenticate users against an existing directory server.
In order to configure Anchore Enterprise Client for use with LDAP, the requisite information for connecting and authenticating with an LDAP directory server must first be provided by an administrator. For the purposes of determining what users can see and do once they are logged in, the administrator must also create one or more account association entries, called user mappings.
When an LDAP user authenticates, the Anchore Enterprise account associated with their session is determined by the first user mapping containing a search filter that matches the information in their LDAP record. LDAP authentication will fail if no matches are found, if the associated account is disabled, or if the user’s login credentials are incorrect.
The following sections in this document describe how to configure the Anchore Enterprise Client for use with an LDAP directory server, how to add user mappings, and how to log in to the application as an LDAP user.
Administrators can provide the information used to connect Anchore Enterprise Client to an LDAP server from the LDAP sidetab in the Configuration view. Please note that this sidetab is not visible to non-administrative users.
The connection property fields shown in this view are described below:
| Property | Description |
|---|---|
| Server URI | The ldap:// or ldaps:// URI of the LDAP directory server to query. |
| Manager DN | The distinguished name (DN) of an LDAP directory manager that the Anchore Enterprise Client can use to perform further queries about LDAP users during login. The directory manager is typically a privileged server administrator who, once authenticated, can access the LDAP record of any user intended to access the application. |
| Manager Password | The password associated with the Manager DN. |
| Base DN | The relative distinguished name in the LDAP directory tree hierarchy under which queries about users should be performed. |
After you have entered the required connection properties, click the Save button to store them. Once stored, you can click the Test button to verify that the application can authenticate with the LDAP server using the details you’ve provided.
Note: Clicking Save when no values are provided in any of the fields will disable LDAP in the application and prevent LDAP from being displayed as an authentication option on the login screen.
LDAP user mappings contain search filters that unite the results of searches made against the data attributes of LDAP records with account information stored in Anchore Enterprise.
When an LDAP user submits their credentials on the login page, the first match encountered will provide Anchore Enterprise Client with an associated Anchore Enterprise account that is used to define the scope of what the user can see and do once they are fully authenticated.
If a match is detected, the submitted password is then validated against the one stored inside the matched LDAP record. If the password is correct and the associated Anchore Enterprise account is not suspended, the user will be successfully logged in. If no match is found or the password is incorrect, authentication will fail.
User mappings can be created by administrators from inside an account within the Accounts sidetab in the Configuration view, or from the LDAP sidetab in the area below the server connection properties form.
To add a new user mapping containing an LDAP search filter, click the Add New LDAP User Mapping button—or if no user mappings are currently defined, click the Let’s add one! button in the empty table.
You will be presented a dialog, similar to the one shown below, where you can provide an LDAP search filter:
The LDAP search filter in each mapping provides the criteria for associating that mapping with an Anchore Enterprise account. For example:
uid=$USERNAME
In the above example, the user mapping requires that the uid (user ID) attribute in an LDAP record matches the data represented by the $USERNAME token.
The =$USERNAME string is a required entry, and the actual value of the token resolves to whatever value the user enters in the Username field when they log in to Anchore Enterprise Client.
In Microsoft® Active Directory® (AD) implementations that support the LDAP protocol, the sAMAccountName attribute is the broad equivalent of uid:
sAMAccountName=$USERNAME
Note: The submitted value of $USERNAME should always correspond to an attribute with a unique value within the LDAP user record, or one that is unique in combination with other criteria. In Active Directory, the uniqueness of sAMAccountName is enforced, whereas this may not be true for uid (which is an optional attribute in AD).
Additional filter criteria beyond the user identity can be provided to assert granular control over user access. The following examples describe filters with narrower scope:
(&(cn=$USERNAME)(|(ou:dn:=Administrative)(ou:dn:=Management)))
(&(ou=devops)(uniqueMember=uid=$USERNAME,dc=example,dc=org))
A detailed summary of the syntax and formula of LDAP search filters is beyond the scope of this document, however RFC 1558 provides a comprehensive description of how these entries are structured.
By default, mappings are evaluated in priority order, with new entries being stored at the lowest priority. It can be challenging to infer the exact order of all mappings when they are spread across multiple accounts, so the table listing all current mappings the LDAP sidetab shows the priority of every item and includes the account with which they are associated. Example:
From here you can move row entries to a higher or lower order of precedence by clicking down on a hotspot () and then dragging the row up or down the list.
The priority order of user mappings determines the order in which search filters are evaluated when a user logs in. The first mapping to successfully locate an LDAP user record that matches the $USERNAME and any other criteria in its search filter will be used to determine the Anchore Enterprise account association for that user.
Once a user is located, subsequent mapping entries will be ignored, regardless of (possibly narrower) specificity, as only priority order matters here.
You can evaluate the behavior of your user mappings by entering $USERNAME data (for example, the uid of a user) in the Check $USERNAME Against LDAP Mappings search field.
If an LDAP record is located that matches the search filter criteria of a mapping, you’ll be informed of which mapping provided the match, the associated Anchore Enterprise user, and the distinguished name of the user whose LDAP record was returned.
If a set of valid LDAP server connection properties have been stored by an administrator, the LDAP authentication option is activated in the application login view, in addition to the Default option of authenticating against the user records stored in Anchore Enterprise:
The value entered in the Username field will be used by the application to populate the $USERNAME token when evaluating each user mapping. The value entered in the Password field will be used to authenticate the matched user with the LDAP directory server.
Once these operations have completed, and providing the account associated with the mapping is not disabled, the user will be logged in.
A policy is composed of a set of rules that are used to perform an evaluation on a source repository or container image. These rules include—but are not limited to—checks on security, known vulnerabilities, configuration file contents, the presence of credentials, manifest changes, exposed ports, or any user defined checks.
Policies can be deployed site wide, or customized to run against specific sources, container images, or categories of application. For additional information, refer to the Policy concepts section.
Once a policy has been applied to a source repository or image container, it can return one of two results:
indicating that source or image complies
with your policy.
indicating that the source or image is non-compliant with your policy.
Each rule contained within a policy is configured with a check to perform. For
example, check if deny-listed package openssh-server present. The policy
additionally specifies the action to take place, based on the result of the
evaluation.
Policy rule checks are made up of gates and triggers. A gate is a set of policy checks against broad categories like vulnerabilities, secret scans, licenses, and so forth. It will include one or more triggers, which are checks specific to the gate category.
The area under the Policies sub-tab in the policy editor contains a table that lists the policies defined within a selected policy. The numeric indicator represents the overall number of polices currently defined in the policy.
Adjacent to each name in the policy list is a counter that indicates the number of rules within that policy.
Note: A lock icon next to the rule counter indicates that the policy cannot be deleted. Policy rules that are used by policy mappings in the policy (which will be listed under the Used By Mapping(s) column entry) cannot be deleted until they are removed from every associated mapping.
The Tools dropdown menu in the Actions column provides options to:
Edit the policy
Copy the policy
Download the policy as a JSON document
Delete the policy (if it is not being used by any policy mapping)
You can add new rule sets to a policy.
Click Add New Rule Set.
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.
Type a uniqe name for the new policy (you can also add an optional description) and click OK.
From the Edit Source Repository Policy Rules modal, set up the policy rules for the new policy. 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.
After selecting a gate item, hover over the (i) indicator next to Gate to see additional descriptive details about the gate you have selected.
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.
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.
Click Save and Close.
Existing rule sets from a source repository or container image may be modified.
From Actions, either select Edit, or Tools > Edit Policy Rules. You can also copy a policy, download the policy to JSON, or delete the policy.
From the Edit Source Repository Policy Rules or Edit Container Image Policy Rules modal (depending on whether you choose to edit a policy for a source repository or container image), you can change the policy name and description.
You can also change any documentation associated with individual policy rules by editing the descriptions presented within each row of the table.
Note: If you are editing a policy rule for a source repository, only vulnerabilities are available under Gate.
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.
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.
After a rule has been added to the policy, you will see it in the the edit policy list page as a new entry.
The final action of each rule can be modified by clicking the STOP, WARN, or GO buttons.
Click Remove to get rid of any unwanted rules.
Click Edit to edit the policy rule again.
After modifying the existing rule, click Apply and the rule will be updated.
When you are satisfied that all your new (or updated) rules are correct, you can click Save new rule, and Close to update and store your policy.
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 policy and add it to the list of policies.
To add a new policy , click Create New Bundle.
Enter a unique name, along with an optional (but recommended) description for your new policy.
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.
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.
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.
Click Edit Name to rename the policy.
Enter the new name.
Click the green check to rename the policy.
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.
Click Policies, or use the browsers navigation buttons to navigate back to the list of Policies.
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.
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
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.
| 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
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.
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.
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.
| 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 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.
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.
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*/*. |
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.
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
Add a name for the policy. This name should be unique.
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.
If you have a JSON document containing an existing policy, then you can upload it into Anchore Enterprise.
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.
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
You can edit existing policies at any time, including the policies, allowlists, mappings, and allowed or denied images.
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.
Optional: You can add a description to explain the new policy. This is recommended.
Click OK to copy the 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.
*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
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
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.
The workflow for adding Allowed or Denied images is identical.
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
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.
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.
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.
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.
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.
Click Add New Allowlist to create a new, empty allowlist.
Add a name for the allowlist. A name is required and should be unique.
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”.
If you have a JSON document containing an existing allowlist, then you can upload it into Anchore Enterprise.
Click Upload / Paste Allowlist to upload an allowlist. You can also manually edit the allowlist in the native JSON format.
Drag an allowlist file into the dropzone. Or, you can click the “Add a Local File” button and load it from a local filesystem.
Click OK to upload the allowlist. The system will perform a validation for the allowlist. Only validated allowlists may be stored by Anchore Enterprise.
You can copy an existing allowlist, give it a new name, and use it for a policy evaluation.
From the Tools drop down, select Copy Allowlist.
Enter a unique name for the allowlist.
Optional: Add a description. This is recommended. Often the description is updated as new entries are added to the allowlist to explain any background.
You can download an existing allowlists as a JSON file. From the Tools drop down, click Download to JSON.
The Allowlists editor allows new allowlist entries to be created, and existing entries to be edited or removed.
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.
Choose a gate for the allowlist, for example, vulnerabilities.
A vulnerabilities allowlists entry includes two elements: A CVE / Vulnerability Identifier and a Package.
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.
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.
Optional: Click 
to edit an allowlist.
Optional: Click Remove to delete an allowlist.
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.
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.
In this section you will learn how to configure access to registies within the Anchore Enterprise UI.
The UI will attempt to download images from any registry without requiring further configuration. However, if your registry requires authentication then the registry and corresponding credentials will need to be defined.
First off, after a successful login, navigate to the Configuration tab in the main menu.
In order to define a registry and its credentials, navigate to the Registries tab within Configuration. If you have not yet defined any registries, select the Let’s add one! button. Otherwise, select the Add New Registry button on the right-hand side.
Upon selection, a modal will appear:
A few items will be required:
As the required field values may vary depending on the type of registry and credential options, they will be covered in more depth below. A couple additional options are also provided:
Allow Self Signed By default, the UI will only pull images from a TLS/SSL enabled registry. If the registry is protected with a self signed certificate or a certificate signed by an unknown certificate authority, you can enable this option by sliding the toggle to the right to instruct the UI not to validate the certificate.
Validate on Add Credential validation is attempted by default upon registry addition although there may be cases where a credential can be valid but the validation routine can fail (in particular, credential validation methods are changing for public registries over time). Disabling this option by sliding the toggle to the left will instruct the UI to bypass the validation process.
Once a registry has been successfully configured, its credentials as well as the options mentioned above can be updated by clicking Edit under the Actions column. For more information on analyzing images with your newly defined registry, refer to: UI - Analyzing Images.
The instructions provided below for setting up the various registry types can also be seen inline by clicking ‘Need some help setting up your registry?’ near the bottom of the modal.
Regular docker v2 registries include dockerhub, quay.io, artifactory, docker registry v2 container, redhat public container registry, and many others. Generally, if you can execute a ‘docker login’ with a pair of credentials, Anchore can use those.
Registry Hostname or IP of your registry endpoint, with an optional port Ex: docker.io, mydocker.com:5000, 192.168.1.20:5000
Type Set this to docker_v2
Username Username that has access to the registry
Password Password for the specified user
Registry The ECR endpoint hostname Ex: 123456789012.dkr.ecr.us-east-1.amazonaws.com
Type Set this to awsecr
For Username and Password, there are three different modes that require different settings when adding an ECR registry, depending on where your Anchore Enterprise is running and how your AWS IAM settings are configured to allow access to a given ECR registry.
API Keys Provide access/secret keys from an account or IAM user. We highly recommend using a dedicated IAM user with specific access restrictions for this mode.
Username AWS access key
Password AWS secret key
Local Credentials Uses the AWS credentials found in the local execution environment for Anchore Enterprise (Ex. env vars, ~/.aws/credentials, or instance profile).
Username Set this to awsauto
Password Set this to awsauto
ECR Assume Role To have Anchore Enterprise assume a specific role different from the role it currently runs within, specify a different role ARN. Anchore Enterprise will use the execution role (as in iamauto mode from the instance/task profile) to assume a different role. The execution role must have permissions to assume the role requested.
Username Set this to _iam_role
Password The desired role’s ARN
For more information, see: Working with Amazon ECR Registry Credentials
When working with Google Container Registry, it is recommended that you use service account JSON keys rather than the short lived access tokens. Learn more about how to generate a JSON key here.
Registry GCR registry hostname endpoint Ex: gcr.io, us.gcr.io, eu.gcr.io, asia.gcr.io
Type Set this to docker_v2
Username Set this to _json_key
Password Full JSON string of your JSOn key (the content of the key.json file you got from GCR)
For more information, see: Working with Google Container Registry (GCR) Credentials
To use an Azure Registry, you can configure Anchore to use either the admin credential(s) or a service principal. Refer to Azure documentation for differences and how to setup each.
Registry The login server Ex. myregistry1.azurecr.io
Type Set this to docker_v2
Admin Account Username The username in the ‘az acr credentials show –name ’ output
Password The password or password2 value from the ‘az acr credentials show’ command result
Service Principal Username The service principal app id
Password The service principal password
For more information, see: Working with Azure Registry Credentials
The Reports tab is your gateway to producing insights into the collective status of your container image environment based on the back-end Enterprise Reporting Service.
Note: Because the reporting data cycle is configurable, the results shown in this view may not precisely reflect actual analysis output at any given time.
For more information on how to modify this cycle or the Reporting Service in general, please refer to the Reporting Service documentation.
The Report feature provides the tools to create custom reports, set a report to run on a schedule (or store the report for future use), and get notified when they’re executed in order to receive the insights you’re interested in for account-wide artifacts.
In addition, you can create user templates (also known as custom templates) that use any of the preconfigured system templates offered with the application as their basis, or create your own templates from scratch. Templates provide the structure and filter definitions the application uses in order to generate reports.
To jump to a particular guide, select from the following below:
The New Reports tab in the Reports view is where you can create a new report, either on an ad-hoc basis for immediate download, or for it to be saved for future use. Saved reports can be executed immediately, scheduled, or both.
Note: The New Reports tab will be the default tab selected in the Reports view when you don’t yet have any saved reports.
Reports created in this view are based on templates. Templates provide the output structure and filter definitions the user can configure in order for the application to generate the shape of the report. Anchore Enterprise client provides immediate access to a number of preconfigured system templates that can be used as the basis for user templates. For more information on how to create and manage templates, please refer to the Templates documentation.
The initial view of the New Reports tab is shown below:
In the above view you can see that the application is inviting you to select a template from the dropdown menu. You can either select an item from this dropdown or click in the field itself and enter text in order to filter the list.
Once a template is selected, the view will change to show the available filters for the selected template. The following screenshot shows the view after selecting the Artifacts by Vulnerability template:
At this point you can click Preview Report to see the summary output and download the information, or you can refine the report by adding filters from the associated dropdown. As with the template selection, you can either select an item from the dropdown or click in the field itself and enter text in order to filter the list.
After you click the Preview Report button, you are presented with the summary output and the ability to download the report in a variety of formats:
At this point you can click any of the filters you applied in order to adjust them (or remove them entirely). The results will update automatically. If you want to add more filters you can click the [ Edit ] button and select more items from the available options and then click Preview Report again to see the updated results.
You can now optionally configure the output information by clicking the [ Configure Columns ] button. The resulting popup allows you to reorder and rename the columns, as well as remove columns you don’t want to see in the output or add columns that are not present by default:
Once you’re satisfied with the output, click Download Full Report to download the report in the selected format. The formats provided are:
The above describes the generation of an ad-hoc report for download, which may be all you need. However, you can also save the report for future use. To do so, click the Save Report button. The following popup will appear:
Provide a name and optional description for the report, and then select whether you want to save the report and store results immediately, set it to run on a schedule, or both. If you select the Generate Report option, you can then select the frequency of the report generation. Once you’re satisfied with the configuration, click Save.
The saved report will be stored under Saved Reports and you will immediately be transitioned to this view on success. The features within this view are described in the Saved Reports section.
Generate a report utilizing the back-end Enterprise Reporting Service through a variety of formats - table, JSON, and CSV. If you’re interested in refining your results, we recommend using the plethora of optional filters provided.
Note: Because the reporting data cycle is configurable, the results shown in this view may not precisely reflect actual analysis output at any given time.
For more information on how to modify this cycle or the Reporting Service in general, please refer to the Reporting Service documentation.
The following sections in this document describe how to select a query, add optional filters, and generate a report.
To select a query, click the available dropdown present in the view and select the type of report you’re interested in generating.
View a list of images and their various artifacts that are affected by a vulnerability. By default, a couple optional filters are provided:
| Filter | Description |
|---|---|
| Vulnerability Id | Vulnerability ID |
| Tag Current Only | If set to true, current tag mappings are evaluated. Otherwise, all historic tag mappings are evaluated |
Query your policy evaluation data using this report type. By default, this report was crafted with compliance history in mind. Quite a few optional filters are provided to include historic tag mappings and historic policy evaluations from any policy that is or was set to active. More info below:
| Filter | Description |
|---|---|
| Registry Name | Name of the registry |
| Repository Name | Name of the repository |
| Tag Name | Name of the tag |
| Tag Current Only | If set to true, current tag mappings are evaluated. Otherwise, all historic tag mappings are evaluated |
| Policy Evaluation Latest Only | If set to true, only the most recent policy evaluation is processed. Otherwise, all historic policy evaluations are evaluated |
| Policy Active | If set to true, only the active policy at the time of this query is used. Otherwise, all historically active policies are also included. This attribute is ignored if a policy ID or digest is specified in the filter |
Note that the default filters provided are optional.
Once a report type has been selected, an Optional Filters dropdown becomes available with items specific to that Query. Such as those listed above, any filters considered default to that report type are also shown.
You can remove any filters you don’t need by pressing the in their top right corner but as long as they’re empty/unset, they will be ignored at the time of report generation.
After a report type has been selected, you immediately can Generate Report by clicking the button shown in the bottom left of the view.
By default, the Table format is selected but you can click the dropdown and modify the format for your report by selecting either JSON or CSV.
A fast and easy way to browse your data, the table report retrieves paginated results and provides optional sorting by clicking on any column header. Each column is also resizable for your convenience. You can choose to fetch more or fetch all items although please note that depending on the size of your data, fetching all items may take a while.
Download your report in JSON or CSV format. Various metadata such as the report type, any filters used when querying, and the timestamp of the report are included with your results. Please note that depending on the size of your data, the download may take a while.
Use the Report Manager view to create custom queries, set a report to run on a schedule (or store the configuration for future use), and get notified when they’re executed in order to receive the insights you’re interested in for account-wide artifacts. The results are provided through a variety of formats - tabular, JSON, or CSV - and rely on data retrieved from the back-end Enterprise Reporting Service.
Note: Because the reporting data cycle is configurable, the results shown in this view may not precisely reflect actual analysis output at any given time.
For more information on how to modify this cycle or the Reporting Service in general, please refer to the Reporting Service documentation.
The following sections in this document describe templates, queries, scheduling reports, and viewing your results.
Templates define the filters and table field columns used by queries to generate report output. The templates provided by the sytem or stored by other users in your account can be used directly to create a new query or as the basis for crafting new templates.
By default, the UI provides a set of system templates:
In order to define a template’s list of fields and filters, navigate to the Create a New Template section of the page, select a base configuration provided by the various System Templates listed above, and click Next to open a modal.
Provide a name for your new template, add an optional description, and modify any fields or filters to your liking.
The fields you choose control what data is shown in your results and are displayed from left to right within a report table. To optionally refine the result set returned, you can add or remove filter options, set a default value for each entry and specify if the filter is optional or required.
Note that templates must contain at least one field and one filter.
Once the template is configured to your satisfaction, click OK to save it as a Stored Template. Your new template is now available to hydrate a query or as a basis for future templates.
To view or edit a template that has been stored previously, click its name under Stored Report Items on the right of the page. As with the creation of a template, the list of fields and filters can be customized to your preference.
When you’re done, click OK to save any new changes or Cancel to discard them.
To delete a template that you have configured previously, click the red “x” to the left of its name under Stored Report Items and click Yes to remove it. Note that once the template has been removed, you won’t be able to recover it.
Queries are based on a template’s configuration and can then be submitted to the back-end Enterprise Reporting Service on a reoccurring schedule to generate reports. These results can then be previewed in tabular form and downloaded in JSON or CSV format.
To create a query, navigate to the Create a New Query section of the page, select a template configuration, and click Next to open a modal.
After you provide a unique name for the query and an optional description, click OK to save your new query. You will be automatically navigated to view it.
To view or edit a query, click its name under Stored Report Items on the right of the page to be navigated to the Query View.
Within this view, you can edit its name and description, set a schedule to act as the base configuration for Scheduled Items, and view the various filters set by the template this query was based on.
To save any changes to the query, click Save Query or Save Query and Schedule Report.
In order to set or modify a query’s schedule, click Add/Change Schedule to open a modal.
Reports can be generated daily, weekly, or monthly at a time of your choosing. This can be set according to your timezone or UTC. By default, the schedule is set for weekly on Mondays at 12PM your time.
When scheduling reports to be generated monthly, note that multiple days of the month can be selected and that certain days (the 31st, for example) may not trigger every month.
In the top-right corner of the modal, you can toggle the enabled state of the schedule which determines whether reports will be executed continuously on the timed interval you saved. Note that pressing OK modifies the schedule but does not save it to the query. Please click the Save Query or Save Query and Schedule Report to do so.
To delete a query, click the red “x” to the left of its name under Stored Report Items and click Yes to remove it. Note that every scheduled report associated with that query will also be removed and not be recoverable.
Once you’ve crafted a query based on a system or custom template, supplied any filters to refine the results, and previewed the report generated to ensure it is to your satisfaction, you can add it to be scheduled by clicking Save Query and Schedule Report.
Any schedules created from this view will be listed at the bottom.
To edit a scheduled item, click on Tools within that entry’s Actions column and select Edit Scheduled Item to open a modal.
Here, you can modify the name, description, and schedule for that item. Click Yes to save any new changes or Cancel to discard them.
To delete a scheduled item, click on Tools within that entry’s Actions column and select Delete Scheduled Item. Note that every report generated from that schedule will also be removed upon clicking Yes and will not be recoverable.
Click View under a scheduled item’s Actions column to expand the row and view its list of associated reports sorted by most recent. Click View or Tools > View Results to navigate to that report’s results.
If you configured notifications to be sent when a report has been executed, you can navigate to the report’s results by clicking the link provided in its notification.
A preview of up to 1000 result items are shown in tabular form which provides optional sorting by clicking on any column header. If a report contains more than 1000 results, please download the data to view the full report. To do so, click Download to JSON or Download to CSV based on your preferred format.
Various metadata such as the report type, any filters used when querying, and the timestamp of the report are included with your results. Please note that depending on the size of your data, the download may take a while.
To be notified whenever a report has been generated, navigate to Events & Notifications > Manage Notifications. Once any previous notification configurations have loaded, add a new one from your preferred endpoint (Email, Slack, etc), and select the predefined event selector option for Scheduled Reports.
This includes the availability of a new result or any report execution failures.
Once you receive a notification, click on the link provided to automatically navigate to the UI to view the results for that report.
The Saved Reports tab in the Reports view is where you can view, configure, download, or delete reports that have been saved for future use. Each report entry may contain zero or more results, depending on whether the report has been run or not.
Note: The Saved Reports tab will be the default tab selected in the Reports view when you have one or more saved reports.
An example of the Saved Reports tab is shown below:
Clicking anywhere within the row other than on an active report title or on the Actions button will expand it, displaying the executions for that report if any are available. Clicking an active report title will take you to a view displaying the latest execution for that report. An inactive report title indicates that no results are yet available.
If a report has been scheduled but has no executions, the expanded row will look like the following example:
Reports with one or more executions will look like the following example:
In the above example you can see a list of previously executed reports. Their completion status is indicated by the green check mark. Reports that are still in progress are indicated by a spinning icon. Reports that are queued for execution are indicated by an hourglass icon. The reports shown here are all complete, so they can be downloaded by clicking the Download Full Report button. Incomplete, queued, or failed reports cannot be downloaded.
The initial view shows up to four reports, with any older items being viewable by clicking the View More button. The View More button will disappear when there are no more reports to show. In addition:
Clicking the Refresh List button will refresh the list of reports, including any executions that may have completed since the last time the list was refreshed. Clicking the Generate Now button will generate a new execution of the report.
Individual report items can be deleted by clicking the Delete button. If the topmost report item is deleted, the link in the table row will correspond to the next report item in the list (if any are available).
Note: Deleting all the execution entries for a report will not delete the report itself. The report will still be available for future executions.
Each report row has a Tools control that allows you to perform the following actions:
The Templates tab in the Reports view is where you can view and manage report templates. Templates provide the basis for creating the reports executed by the system and specify which filters are applied to the retrieved dataset and how the returned data is shaped.
A number of system templates are provided with the application and all of these and can be used as-is, or as a starting point for creating your own user templates.
An example of the System Templates view in the Templates tab is shown below:
In this view you can see all the system templates provided by default, and their associated descriptions. System templates cannot be deleted, but can be copied and modified to create your own user templates.
An alternate way of creating a new user template is by clicking the Create New Template button. You will be presented with a dialog that allows you to select an existing system template as your starting point, or base your composition on any of the custom templates created by you or other users:
Selecting a template from the provided dropdown will open the Create a New Template dialog:
Within this dialog you can provide a unique name and optional description for the new template. In addition, you can modify the filters available when composing reports based on this template, and the columns that will be displayed in the resulting report:
Filters: You can add or remove filters, set default values, and specify if the filter is optional or required. Filters are displayed from left to right when composing a report—you can change the display order by clicking on a row hotspot and dragging the row item up or down the list.
Columns: You can add or remove columns, change their display order, or provide custom column names to be used when the data is presented in the tabular form offered by comma-separated variable (CSV) file downloads. Columns are displayed from left to right within a report table—you can change the display order by clicking on a row hotspot and dragging the row item up or down the list. Note that templates must contain at least one column.
Once you have configured the filters and columns, you can specify if the report will be scoped to return results against the analysis data in either the current selected account or from all accounts, and click OK. The new template will be added to the list of available user templates.
The custom templates view shows all user-defined templates present in the current selected account. An example of the Custom Templates view is shown below:
Unlike system templates, custom templates can be edited or deleted in addition to being copied. Clicking the Tools button for a custom template will display the following options:
Note that any changes you make to templates in this view, or any new entries you create, will be available to all users in the current selected account.
In this section you will learn how to create accounts, users, and role assignment with the Anchore Enterprise UI.
For more information on accounts, users, roles, and permissions see: Role Based Access Control
In order to create accounts, navigate to the accounts tab from inside the configuration view and select “Create New Account”.
Upon selection, a popup window will display asking for two items:
Now that a group has been created, I can begin to add users to it.
To view the permissions associated with a specific role using the UI, select an account, and navigate to the roles tab:
To view the members in the account assigned to a specific role, select the ‘View’ button on the right-hand side.
Upon immediate creation of an account, there will, by default be zero users. To add users, select the edit button corresponding the account you would like to add users to. This will bring you to the account page, where you can add your first user by selecting the “Let’s add one!” button.
Upon selection, a popup window will display asking for three items:
In this case I’ve assigned three roles to the user:
Once ‘OK’ is selected, the user will be created and you will be able to edit or remove the user as needed.
In order to delete an account, disable the account by sliding the button under the ‘Active’ column for the corresponding account, then select the ‘Remove’ button on the right-hand side.
A few notes to keep in mind when deleting accounts:
A couple notes on disabling accounts:
System administrator users are able to view another account’s data context using the dropdown located at the top-right:
Added in Anchore Enterprise v2.2
Alert external endpoints (Email, GitHub, Slack, and more) about Anchore events such as policy evaluation results, vulnerability updates, and system errors with our new Notifications service. Configure notification endpoints and manage which specific events you need through Anchore Enterprise UI.
For more information on the Notifications Service in general, its concepts, and details on its configuration, please refer to the Notifications Service.
The following sections in this document describe the current endpoints available for configuration, the options provided for selecting events, the various actions you can do with a configuration (add, edit, test, and remove), and how to disable an endpoint as an admin.
When adding or editing a configuration, selecting which events to be notified on can be as easy as choosing one of the above three options: All Notification Events, Policy & Vulnerability Events, or Error Events.
Advanced users can select Add Custom Selector for more granularity:
In the example shown, we configure to be notified on all system info events affecting any resource associated with the user’s account. For an in-depth explanation on the provided properties and their possible values, view our Selector documentation.
If you haven’t already defined a configuration for an endpoint, simply click Let’s Add One! as shown above. Once you have, add additional configurations with Add New Configuration as shown below.
Upon doing so, a modal will appear with various properties shown on the left side. Note that based on the type of endpoint, these properties may differ.
To view the various requirements, check the documentation for Email, GitHub, JIRA, Slack, and Teams.
For more information on adding a custom selector, please view our Selector documentation.
Prior to saving your new configuration, feel free to test with the Test Configuration button. Then save with OK.
Note: If OK is not enabled, be sure all required fields have been filled out.
The process to edit a configuration entry is started by clicking Edit which is found within the Actions column as shown above.
The various fields available for editing are the same shown when adding the configuration. For additional info on a specific field, hover over the provided question icon circled with an orange ring next to the field name.
At any time, you can select Cancel to disregard any changes you’ve made.
For testing any new changes prior to saving them, click Test Configuration.
To save your changes, click OK. If OK is not enabled, be sure all required fields have been filled out.
When viewing your configurations, testing is easy - just look under the Actions column and click Test for that entry.
Otherwise, when adding or editing a configuration, search for the test button pictured above. It can be found near the bottom of the modal, next to the Cancel and OK buttons.
To remove a specific notification configuration, simply click on the Remove button (as shown above) within the Actions column for that entry.
Select Yes to proceed with the deletion process or No to cancel. Please note that once you agree to remove the configuration, you won’t be able to recover it.
As an admin, navigate to System > Notifications and click on the toggle visible in the lower-right corner of the specific endpoint you’re aiming to disable.
By default, all endpoints (such as Email, Slack, and Webhook) are enabled out of the box. Disabling a specific endpoint requires admin privileges as it ensures all notifications are stopped from going out to any configuration for that endpoint system-wide.
Note that users are still able to add, edit, test, and remove notification configuration items, but no event messages will be sent for that endpoint until it is re-enabled.
Added in Anchore Enterprise 2.2, the Health section within the System tab is an administrator’s new display for investigating the operational status of their system’s various services and feeds. Leverage this view to understand when your system is ready or if it requires intervention.
The following sections in this document describe how to determine system readiness, the state of your services, and the progression of your feed sync.
For more information on the overall architecture of a full Anchore Enterprise deployment, please refer to the Architecture documentation. Or refer to the Feeds Overview if you’re interested in the feeds-side of things.
Ready
(Tentatively) Ready
Not Ready
The indicator for system readiness can be seen from any screen by viewing the System tab header:
The system readiness status relies on the service and feed data which are routinely updated every 5 minutes. Using the example indicator provided above, once all the feed groups are successfully synced, the status icon will turn green.
For up-to-date information outside of the normal update cycle, navigate to the Health section within the System tab and click on Refresh Service Health, Refresh Feed Data, or manually refresh the page.
As shown above and as of 2.2, there are five services required by the system to function (API, Catalog, Policy Engine, SimpleQueue, and Analyzer).
For every service, the Base URL, Host ID, and Version is displayed. As long as one instance of each service is up and available, the main system is regarded as ready. In the example image provided above, we see that we have multiple instances of the Policy Engine and Analyzer services.
For the full, filterable list of instances for that service, click on the numbers provided. In the case of the Policy Engine, that would be the 1/2 Available.
Note that orphaned services are filtered out by default in this view (with a toggle to include it again) but will still impact the availability count on the main page.
In the case of service errors, they are logged within the Events & Notifications tab so we recommend following up there for more information or browse our Troubleshooting documentation for remediation guidance.
Listed in this section are the various feed groups your system relies on for vulnerability and package data. This data comes from a variety of upstream sources which is vital for policy engine operations such as evaluating policies or listing vulnerabilities.
As shown, you can keep track of your sync progression using the Last Sync column. To manually update the feed data displayed outside of its normal 5-minute cycle, click the Refresh Feed Data button or refresh the page.
If you’d rather have them grouped by feed rather than listed out individually, you can toggle the layout from list to cards using the buttons in the top-right corner above the table:
Similar to the service cards, if you decide to have them grouped as we show below using the layout buttons, you can click on the number of groups synced to view the full, filterable list within.
When viewing a list of feed groups - whether through the default list or through a specific feed card - you can filter for a specific value using the input provided or click on the button attached to filter by category. In this case, groups can be filtered by whether they are synced or unsynced.
In the case of feed sync errors, they are logged within the Events & Notifications tab so we recommend following up there for more information or browse our Troubleshooting documentation for remediation guidance.
Or if you’re interested in an overview of the various drivers Enterprise Feeds uses, check out our Feeds Overview.