This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Requirements

Introduction

This section details the requirements to run Anchore Enterprise.

Resourcing

Use-case and usage patterns will determine the resource requirements for Anchore Enterprise. When deploying via Helm, requests and limits are set in the values.yaml file. When deploying via docker compose, add reservations and limits into your docker compose file. The following recommendations can get you started:

  • Requests specify the desired resource amounts for the container, while limits specify the maximum resource amounts the container is allowed. We have found that setting the request and limit to the same value provides the best quality of service (QoS) from Kubernetes.

  • We do not recommend setting less than 1 CPU unit for any containers. Less than this could result in unexpected behaviour and should only be used in testing scenarios.

  • For the catalog, policeEngine and postgresql containers, we recommend a minimum of 2 CPU units.

  • We do not recommend setting memory units to less than 8G except for API and UI services, where we recommend starting at 4G. Less than these values could result in OOM errors or containers restarting unexpectedly.

See below for further guidance.

Database

Anchore Enterprise requires a PostgreSQL version 13 or higher database to provide persistent storage for image, policy and analysis data.

The database can be run in a container, as configured in the example Docker Compose file, or it can be provided as an external service to Anchore Enterprise. PostgreSQL compatible databases, such as Amazon RDS for PostgreSQL, can be used for highly-scalable cloud deployments.

FIPS Enable Hosts

If Anchore Enterprise is deployed on FIPS Enabled Hosts and Amazon RDS (including GovCloud) is hosting the Anchore database, you will be required to have PostgreSQL version 16 or higher. This is due to RHEL 9 enforcing the FIPS-140-3 requirements. Amazon RDS is only supporting EMS or TLS 1.3 with the use of PostgreSQL 16 or greater.

Network

Anchore requires the following two categories of network access:

  • Registry Access Network connectivity, including DNS resolution, to the registries from which Anchore Enterprise needs to download images.
  • Feed Service Anchore Enterprise Feeds requires access to the upstream data feeds from supported Linux distributions and package registries. See Feeds Endpoints for the full list of the endpoints.

Security

Anchore Enterprise is deployed as source repositories or container images that can be run manually using Docker Compose, Kubernetes or any other supported container platform.

By default, Anchore Enterprise does not require any special permissions. It can be run as an unprivileged container with no access to the underlying Docker host.

Note: Anchore Enterprise can be configured to pull images through the Docker Socket. However, this configuration is not recommended, as it grants the Anchore Enterprise container added privileges, and may incur a performance impact on the Docker Host.

Storage

Anchore Enterprise uses a PostgreSQL database to store persistent data for images, tags, policies, subscriptions and other artifacts. One persistent storage volume is required for configuration information, and two optional storage volumes may be provided as described below.

  • Configuration volume This volume is used to provide persistent storage to the container from which it will read its configuration files, and optionally - certificates. Requirement: Less than 1MB.
  • [Optional] Temporary storage The temporary storage volume is recommended but not required. During the analysis of images, Anchore Enterprise downloads and extracts all of the layers required for an image. These layers are extracted and analyzed, after which, the layers and extracted data are deleted. If a temporary storage is not configured, then the container’s ephemeral storage will be used to store temporary files. However, performance is likely be improved by using a dedicated volume. A temporary storage volume may also be used for image-layer caching to speed up analysis. Requirement: Three times the uncompressed image size to be analyzed. Note: A temporary volume is required to work around a kernel driver bug for container hosts that use OverlayFS or OverlayFS2 storage, with a kernel older than 4.13.
  • [Optional] Object storage Anchore Enterprise stores documents containing archives of image analysis data and policies as JSON documents. By default, these documents are stored within the PostgreSQL database. However, Anchore Enterprise can be configured to store archive documents in a filesystem (volume), S3 Object store, or Swift Object Store. Requirement: Number of images x 10MB (estimated).

Enterprise UI

The Anchore Enterprise UI module interfaces with Anchore API using the external API endpoint. The UI requires access to the Anchore database where it creates its own namespace for persistent configuration storage. Additionaly, a Redis database is used to store session information.

  • Runtime

    • Docker compatible runtime (version 1.12 or higher)

  • Storage

    • Configuration volume This volume is used to provide persistent storage to the container from which it will read its configuration files and optionally certificates. Requirement: Less than 1MB

  • Network

    • Ingress
      • The Anchore UI module publishes a web UI service by default on port 3000, however, this port can be remapped.
    • Engress
      • The Anchore UI module requires access to two network services:
        • External API endpoint (typically port 8228)
        • Redis Database (typically port 6379)

  • Redis Service

    • Version 4 or higher

Note: If you’re installing the Anchore Enterprise UI using our installation examples, they include a deployment of a redis service as part of the UI deployment process.

Next Steps

If you feel you have a solid grasp of the requirements for deploying Anchore Enterprise, we recommend following one of our installation guides.