Requirements

This section details the general requirements for running Anchore Enterprise. For a conceptual understanding of Anchore Enterprise, please see the Overview topic prior to deploying the software.

Runtime

Anchore Enterprise requires a Docker compatible runtime (version 1.12 or higher). Deployment is supported on:

Docker Compose (for demo or proof-of-concept and small deployments)
Any Kubernetes Certified Service Provider (KSCP) as certified by the Cloud Native Computing Foundation (CNCF) via Helm.
Any Kubernetes Certified Distribution as certified by the Cloud Native Computing Foundation (CNCF) via Helm.
Amazon Elastic Container Service (ECS) via Helm.

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 limits for CPU.
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, policy and postgresql service 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.

If you intend on using K8s, the default values.yaml found in the Anchore Enterprise Helm Chart provides some resourcing recommendations to get you started.

When considering horizontal scaling, look to maintain a 4:1 analyzer to core services (API, policy, catalog) ratio. For example, an 8 analyzer deployment should generally have 2 API, policy and catalog pods.

Database

The only service dependency strictly required by Anchore Enterprise is a PostgreSQL database (13.0 or higher) that all services connect to, but do not use for communication beyond some very simple service registration/lookup processes. The database is centralized simply for ease of management and operation. For more information, go to Anchore Enterprise Architecture. Anchore Enterprise uses this database to provide persistent storage for image, policy and analysis data.

A PostgreSQL database ships with the default deployment mechanisms for Anchore Enterprise. This is often referred to as the Anchore-managed database. This can be run in a container, as configured in the example Docker Compose file and default Helm values file.

The PostgreSQL database requirement can also 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.

An external PostgreSQL compatible (rather than Anchore-managed) database is broadly recommended for any production deployment.

FIPS Enabled 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

An Anchore Enterprise deployment requires the following three categories of network access:

Service Access
- Connectivity between Anchore Enterprise services, including access to an external database.
Registry Access
- Network connectivity, including DNS resolution, to the registries from which Anchore Enterprise needs to download images.
Anchore Data Service Access
- Anchore Enterprise requires access to the datasets in order to perform analysis and vulnerability matching. See Anchore Enterprise Data Feeds for more information.

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 can be configured to depend on other storage for various artifacts. For full details on storage configuration, see Storage Configuration.

Configuration volumes: 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] Scratch space: this 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.
[Optional] Layer cache: another temporary storage volume may also be used for image-layer caching to speed up analysis. This caches image layers for re-use by analyzers when generating an SBOM / analyzing an image.

When configuring scratch and layer cache, the size of these volumes should generally be three times the uncompressed image size to be analyzed.

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

The estimated storage requirements for object should be the total number of images x 10MB

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. Additionally, a Redis database deployed and managed by Anchore Enterprise through the supported deployment mechanisms is used to store session information.

Network
- Ingress
  - The Anchore UI module publishes a web UI service by default on port 3000, however, this port can be remapped.
- Egress
  - The Anchore UI module requires access to three network services at the minimum:
    - External API endpoint (typically port 8228)
    - Redis Database (typically port 6379)
    - PostgreSQL Database (typically port 5432)
Redis Service
- Version 7 or higher

Optimizing your Deployment

Optimizing your Anchore deployment on Kubernetes, involves various strategies to enhance performance, reliability, and scalability. Here are some key tips:

Ensure that your Analyzer, API, Catalog, and Policy service containers have adequate CPU and memory resources. See the recommended values here: https://github.com/anchore/support-tools/blob/main/customer-onboarding/enterprise-chart-values.yaml
Integrate with monitoring tools like Prometheus and Grafana to monitor key metrics like CPU, memory usage, analysis times, and feed sync status. You can also Set up alerts for critical thresholds. Follow our guide on Prometheus and Grafana setup Monitoring guides
For large deployments, it is good practice to Schedule regular vacuuming, indexing, and performance tuning to keep the database running efficiently.
Layer caching in Docker can significantly speed up the image build process by reusing layers that haven’t changed, reducing build times and improving efficiency. Follow our guide on Layer Caching setup

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.