This is the multi-page printable view of this section. Click here to print.
Anchore Enterprise and its components are delivered as Docker container images which can be deployed as co-located, fully distributed, or anything in-between. Anchore Enterprise can run on a single host or be deployed in a scale out pattern for increased analysis throughput.
To get up and running, jump to the following guides of your choosing:
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.
Anchore Enterprise requires a Docker compatible runtime (version 1.12 or higher). Deployment is supported on:
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.
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 Anchore Enterprise deployment requires the following three categories of network access:
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.
Anchore Enterprise can be configured to depend on other storage for various artifacts. For full details on storage configuration, see Storage Configuration.
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.
Optimizing your Anchore deployment on Kubernetes, involves various strategies to enhance performance, reliability, and scalability. Here are some key tips:
If you feel you have a solid grasp of the requirements for deploying Anchore Enterprise, we recommend following one of our installation guides.
In this topic, you’ll learn how to use Docker Compose to get up and running with a stand-alone Anchore Enterprise deployment.
This document is intended to serve as a quickstart guide. Before moving further with Anchore Enterprise, it is highly recommended to read the Overview sections to gain a deeper understanding of fundamentals, concepts, and proper usage.
(Optional) Prometheus Configuration File for Monitoring. See Enabling Prometheus Monitoring
(Optional) Swagger UI Nginx Proxy to browse the API with a Swagger UI. See Enabling Swagger UI
The following instructions assume you are using a system running Docker v1.12 or higher, and a version of Docker Compose that supports at least v2 of the docker compose configuration format.
license.yaml file that has been issued to you by Anchore. If you do not have a license yet, visit the Anchore Contact page to request one.Follow the steps below to get up and running!
You’ll need authenticated access to the anchore/enterprise and anchore/enterprise-ui repositories on DockerHub. Anchore Customer Success will provide a Dockerhub PAT (Personal Access Token) for access to images. Login with your Docker PAT to push and pull images from Docker Hub:
# docker login -u <your_dockerhub_pat_user> -p <your_dockerhub_pat>
Download the Docker Compose File into a working directory where you have also placed the license.yaml file you got from Anchore.
# curl https://docs.anchore.com/current/docs/deployment/docker_compose/docker-compose.yaml > docker-compose.yaml
# cp <path/to/your/license.yaml> ./license.yaml
Edit the compose file to set all instances of ANCHORE_ADMIN_PASSWORD to a strong password of your choice.
- ANCHORE_ADMIN_PASSWORD=yourstrongpassword
Then start your environment from your working directory:
# docker compose up -d
Next, we’ll install the lightweight Anchore Enterprise client tool, quickly test using the version operation, and set up a few environment variables to allow it to interact with your quickstart deployment using the admin password you defined in the previous step.
# curl -sSfL https://anchorectl-releases.anchore.io/anchorectl/install.sh | sh -s -- -b /usr/local/bin v5.13.0
# ./anchorectl version
Application: anchorectl
Version: 5.13.0
SyftVersion: v0.97.1
BuildDate: 2023-11-21T22:09:54Z
GitCommit: f7604438b45f7161c11145999897d4ae3efcb0c8
GitDescription: v5.13.0
Platform: linux/amd64
GoVersion: go1.21.1
Compiler: gc
# export ANCHORECTL_URL="http://localhost:8228"
# export ANCHORECTL_USERNAME="admin"
# export ANCHORECTL_PASSWORD="yourstrongpassword"
NOTE: for this quickstart, we’re installing the tool in your local directory ./ and will be using environment variables throughout. To more permanently install and configure anchorectl to remove the need for setting environment variables and putting the tool in a globally accessible path, see Installing AnchoreCTL.
After a few minutes (depending on system speed) Anchore Enterprise and Anchore UI services should be up and running, ready to use. You can verify the containers are running with docker compose, as shown in the following example.
# docker compose ps
Name Command State Ports
-------------------------------------------------------------------------------------------------------
anchorequickstart_analyzer_1 /docker-entrypoint.sh anch ... Up (healthy) 8228/tcp
anchorequickstart_anchore-db_1 docker-entrypoint.sh postgres Up 5432/tcp
anchorequickstart_api_1 /docker-entrypoint.sh anch ... Up (healthy) 0.0.0.0:8228->8228/tcp
anchorequickstart_catalog_1 /docker-entrypoint.sh anch ... Up (healthy) 8228/tcp
anchorequickstart_data-syncer_1 /docker-entrypoint.sh anch ... Up (healthy) 0.0.0.0:8778->8228/tcp
anchorequickstart_notifications_1 /docker-entrypoint.sh anch ... Up (healthy) 0.0.0.0:8668->8228/tcp
anchorequickstart_policy-engine_1 /docker-entrypoint.sh anch ... Up (healthy) 8228/tcp
anchorequickstart_queue_1 /docker-entrypoint.sh anch ... Up (healthy) 8228/tcp
anchorequickstart_reports_1 /docker-entrypoint.sh anch ... Up (healthy) 0.0.0.0:8558->8228/tcp
anchorequickstart_reports_worker_1 /docker-entrypoint.sh anch ... Up (healthy) 0.0.0.0:55427->8228/tcp
anchorequickstart_ui-redis_1 docker-entrypoint.sh redis ... Up 6379/tcp
anchorequickstart_ui_1 /docker-entrypoint.sh node ... Up 0.0.0.0:3000->3000/tcp
You can then run a command to get the status of the Anchore Enterprise services:
# ./anchorectl system status
✔ Status system
┌─────────────────┬────────────────────┬─────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE │ HOST ID │ URL │ UP │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├─────────────────┼────────────────────┼─────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ analyzer │ anchore-quickstart │ http://analyzer:8228 │ true │ available │ 5130 │ 5.13.0 │
│ policy_engine │ anchore-quickstart │ http://policy-engine:8228 │ true │ available │ 5130 │ 5.13.0 │
│ apiext │ anchore-quickstart │ http://api:8228 │ true │ available │ 5130 │ 5.13.0 │
│ reports │ anchore-quickstart │ http://reports:8228 │ true │ available │ 5130 │ 5.13.0 │
│ reports_worker │ anchore-quickstart │ http://reports-worker:8228 │ true │ available │ 5130 │ 5.13.0 │
│ data_syncer │ anchore-quickstart │ http://data-syncer:8228 │ true │ available | 5130 │ 5.13.0 │
│ simplequeue │ anchore-quickstart │ http://queue:8228 │ true │ available │ 5130 │ 5.13.0 │
│ notifications │ anchore-quickstart │ http://notifications:8228 │ true │ available │ 5130 │ 5.13.0 │
│ catalog │ anchore-quickstart │ http://catalog:8228 │ true │ available │ 5130 │ 5.13.0 │
└─────────────────┴────────────────────┴─────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘
Note: The first time you run Anchore Enterprise, vulnerability data will sync to the system in a few minutes.
For the best experience, wait until the core vulnerability data feeds have completed before proceeding.
You can check the status of your feed sync using AnchoreCTL:
# ./anchorectl feed list
✔ List feed
┌────────────────────────────────────────────┬────────────────────┬─────────┬──────────────────────┬──────────────┐
│ FEED │ GROUP │ ENABLED │ LAST UPDATED │ RECORD COUNT │
├────────────────────────────────────────────┼────────────────────┼─────────┼──────────────────────┼──────────────┤
│ ClamAV Malware Database │ clamav_db │ true │ 2024-09-30T18:06:05Z │ 1 │
│ Vulnerabilities │ github:composer │ true │ 2024-09-30T18:12:03Z │ 4040 │
│ Vulnerabilities │ github:dart │ true │ 2024-09-30T18:12:03Z │ 8 │
│ Vulnerabilities │ github:gem │ true │ 2024-09-30T18:12:03Z │ 817 │
│ Vulnerabilities │ github:go │ true │ 2024-09-30T18:12:03Z │ 1879 │
│ Vulnerabilities │ github:java │ true │ 2024-09-30T18:12:03Z │ 5060 │
│ Vulnerabilities │ github:npm │ true │ 2024-09-30T18:12:03Z │ 15619 │
│ Vulnerabilities │ github:nuget │ true │ 2024-09-30T18:12:03Z │ 624 │
│ Vulnerabilities │ github:python │ true │ 2024-09-30T18:12:03Z │ 3229 │
│ Vulnerabilities │ github:rust │ true │ 2024-09-30T18:12:03Z │ 804 │
│ Vulnerabilities │ github:swift │ true │ 2024-09-30T18:12:03Z │ 32 │
│ Vulnerabilities │ msrc:10378 │ true │ 2024-09-30T18:12:16Z │ 2668 │
│ Vulnerabilities │ msrc:10379 │ true │ 2024-09-30T18:12:16Z │ 2645 │
│ Vulnerabilities │ msrc:10481 │ true │ 2024-09-30T18:12:16Z │ 1951 │
│ Vulnerabilities │ msrc:10482 │ true │ 2024-09-30T18:12:16Z │ 2028 │
│ Vulnerabilities │ msrc:10483 │ true │ 2024-09-30T18:12:16Z │ 2822 │
│ Vulnerabilities │ msrc:10484 │ true │ 2024-09-30T18:12:16Z │ 1934 │
│ Vulnerabilities │ msrc:10543 │ true │ 2024-09-30T18:12:16Z │ 2796 │
│ Vulnerabilities │ msrc:10729 │ true │ 2024-09-30T18:12:16Z │ 2908 │
│ Vulnerabilities │ msrc:10735 │ true │ 2024-09-30T18:12:16Z │ 3006 │
│ Vulnerabilities │ msrc:10788 │ true │ 2024-09-30T18:12:16Z │ 466 │
│ Vulnerabilities │ msrc:10789 │ true │ 2024-09-30T18:12:16Z │ 437 │
│ Vulnerabilities │ msrc:10816 │ true │ 2024-09-30T18:12:16Z │ 3328 │
│ Vulnerabilities │ msrc:10852 │ true │ 2024-09-30T18:12:16Z │ 3043 │
│ Vulnerabilities │ msrc:10853 │ true │ 2024-09-30T18:12:16Z │ 3167 │
│ Vulnerabilities │ msrc:10855 │ true │ 2024-09-30T18:12:16Z │ 3300 │
│ Vulnerabilities │ msrc:10951 │ true │ 2024-09-30T18:12:16Z │ 716 │
│ Vulnerabilities │ msrc:10952 │ true │ 2024-09-30T18:12:16Z │ 766 │
│ Vulnerabilities │ msrc:11453 │ true │ 2024-09-30T18:12:16Z │ 1240 │
│ Vulnerabilities │ msrc:11454 │ true │ 2024-09-30T18:12:16Z │ 1290 │
│ Vulnerabilities │ msrc:11466 │ true │ 2024-09-30T18:12:16Z │ 395 │
│ Vulnerabilities │ msrc:11497 │ true │ 2024-09-30T18:12:16Z │ 1454 │
│ Vulnerabilities │ msrc:11498 │ true │ 2024-09-30T18:12:16Z │ 1514 │
│ Vulnerabilities │ msrc:11499 │ true │ 2024-09-30T18:12:16Z │ 981 │
│ Vulnerabilities │ msrc:11563 │ true │ 2024-09-30T18:12:16Z │ 1344 │
│ Vulnerabilities │ msrc:11568 │ true │ 2024-09-30T18:12:16Z │ 2993 │
│ Vulnerabilities │ msrc:11569 │ true │ 2024-09-30T18:12:16Z │ 3095 │
│ Vulnerabilities │ msrc:11570 │ true │ 2024-09-30T18:12:16Z │ 2900 │
│ Vulnerabilities │ msrc:11571 │ true │ 2024-09-30T18:12:16Z │ 3266 │
│ Vulnerabilities │ msrc:11572 │ true │ 2024-09-30T18:12:16Z │ 3238 │
│ Vulnerabilities │ msrc:11583 │ true │ 2024-09-30T18:12:16Z │ 1038 │
│ Vulnerabilities │ msrc:11644 │ true │ 2024-09-30T18:12:16Z │ 1054 │
│ Vulnerabilities │ msrc:11645 │ true │ 2024-09-30T18:12:16Z │ 1089 │
│ Vulnerabilities │ msrc:11646 │ true │ 2024-09-30T18:12:16Z │ 1055 │
│ Vulnerabilities │ msrc:11647 │ true │ 2024-09-30T18:12:16Z │ 1074 │
│ Vulnerabilities │ msrc:11712 │ true │ 2024-09-30T18:12:16Z │ 1442 │
│ Vulnerabilities │ msrc:11713 │ true │ 2024-09-30T18:12:16Z │ 1491 │
│ Vulnerabilities │ msrc:11714 │ true │ 2024-09-30T18:12:16Z │ 1447 │
│ Vulnerabilities │ msrc:11715 │ true │ 2024-09-30T18:12:16Z │ 999 │
│ Vulnerabilities │ msrc:11766 │ true │ 2024-09-30T18:12:16Z │ 912 │
│ Vulnerabilities │ msrc:11767 │ true │ 2024-09-30T18:12:16Z │ 915 │
│ Vulnerabilities │ msrc:11768 │ true │ 2024-09-30T18:12:16Z │ 940 │
│ Vulnerabilities │ msrc:11769 │ true │ 2024-09-30T18:12:16Z │ 934 │
│ Vulnerabilities │ msrc:11800 │ true │ 2024-09-30T18:12:16Z │ 382 │
│ Vulnerabilities │ msrc:11801 │ true │ 2024-09-30T18:12:16Z │ 1277 │
│ Vulnerabilities │ msrc:11802 │ true │ 2024-09-30T18:12:16Z │ 1277 │
│ Vulnerabilities │ msrc:11803 │ true │ 2024-09-30T18:12:16Z │ 981 │
│ Vulnerabilities │ msrc:11896 │ true │ 2024-09-30T18:12:16Z │ 792 │
│ Vulnerabilities │ msrc:11897 │ true │ 2024-09-30T18:12:16Z │ 762 │
│ Vulnerabilities │ msrc:11898 │ true │ 2024-09-30T18:12:16Z │ 763 │
│ Vulnerabilities │ msrc:11923 │ true │ 2024-09-30T18:12:16Z │ 1733 │
│ Vulnerabilities │ msrc:11924 │ true │ 2024-09-30T18:12:16Z │ 1726 │
│ Vulnerabilities │ msrc:11926 │ true │ 2024-09-30T18:12:16Z │ 1536 │
│ Vulnerabilities │ msrc:11927 │ true │ 2024-09-30T18:12:16Z │ 1503 │
│ Vulnerabilities │ msrc:11929 │ true │ 2024-09-30T18:12:16Z │ 1433 │
│ Vulnerabilities │ msrc:11930 │ true │ 2024-09-30T18:12:16Z │ 1429 │
│ Vulnerabilities │ msrc:11931 │ true │ 2024-09-30T18:12:16Z │ 1474 │
│ Vulnerabilities │ msrc:12085 │ true │ 2024-09-30T18:12:16Z │ 1044 │
│ Vulnerabilities │ msrc:12086 │ true │ 2024-09-30T18:12:16Z │ 1053 │
│ Vulnerabilities │ msrc:12097 │ true │ 2024-09-30T18:12:16Z │ 964 │
│ Vulnerabilities │ msrc:12098 │ true │ 2024-09-30T18:12:16Z │ 939 │
│ Vulnerabilities │ msrc:12099 │ true │ 2024-09-30T18:12:16Z │ 943 │
│ Vulnerabilities │ nvd │ true │ 2024-09-30T18:12:10Z │ 264156 │
│ Vulnerabilities │ alpine:3.10 │ true │ 2024-09-30T18:11:54Z │ 2321 │
│ Vulnerabilities │ alpine:3.11 │ true │ 2024-09-30T18:11:54Z │ 2659 │
│ Vulnerabilities │ alpine:3.12 │ true │ 2024-09-30T18:11:54Z │ 3193 │
│ Vulnerabilities │ alpine:3.13 │ true │ 2024-09-30T18:11:54Z │ 3684 │
│ Vulnerabilities │ alpine:3.14 │ true │ 2024-09-30T18:11:54Z │ 4265 │
│ Vulnerabilities │ alpine:3.15 │ true │ 2024-09-30T18:11:54Z │ 4815 │
│ Vulnerabilities │ alpine:3.16 │ true │ 2024-09-30T18:11:54Z │ 5271 │
│ Vulnerabilities │ alpine:3.17 │ true │ 2024-09-30T18:11:54Z │ 5630 │
│ Vulnerabilities │ alpine:3.18 │ true │ 2024-09-30T18:11:54Z │ 6144 │
│ Vulnerabilities │ alpine:3.19 │ true │ 2024-09-30T18:11:54Z │ 6348 │
│ Vulnerabilities │ alpine:3.2 │ true │ 2024-09-30T18:11:54Z │ 305 │
│ Vulnerabilities │ alpine:3.20 │ true │ 2024-09-30T18:11:54Z │ 6444 │
│ Vulnerabilities │ alpine:3.3 │ true │ 2024-09-30T18:11:54Z │ 470 │
│ Vulnerabilities │ alpine:3.4 │ true │ 2024-09-30T18:11:54Z │ 679 │
│ Vulnerabilities │ alpine:3.5 │ true │ 2024-09-30T18:11:54Z │ 902 │
│ Vulnerabilities │ alpine:3.6 │ true │ 2024-09-30T18:11:54Z │ 1075 │
│ Vulnerabilities │ alpine:3.7 │ true │ 2024-09-30T18:11:54Z │ 1461 │
│ Vulnerabilities │ alpine:3.8 │ true │ 2024-09-30T18:11:54Z │ 1671 │
│ Vulnerabilities │ alpine:3.9 │ true │ 2024-09-30T18:11:54Z │ 1955 │
│ Vulnerabilities │ alpine:edge │ true │ 2024-09-30T18:11:54Z │ 6467 │
│ Vulnerabilities │ amzn:2 │ true │ 2024-09-30T18:11:48Z │ 2280 │
│ Vulnerabilities │ amzn:2022 │ true │ 2024-09-30T18:11:48Z │ 276 │
│ Vulnerabilities │ amzn:2023 │ true │ 2024-09-30T18:11:48Z │ 736 │
│ Vulnerabilities │ chainguard:rolling │ true │ 2024-09-30T18:12:02Z │ 4487 │
│ Vulnerabilities │ debian:10 │ true │ 2024-09-30T18:11:55Z │ 32021 │
│ Vulnerabilities │ debian:11 │ true │ 2024-09-30T18:11:55Z │ 33574 │
│ Vulnerabilities │ debian:12 │ true │ 2024-09-30T18:11:55Z │ 32529 │
│ Vulnerabilities │ debian:13 │ true │ 2024-09-30T18:11:55Z │ 31702 │
│ Vulnerabilities │ debian:7 │ true │ 2024-09-30T18:11:55Z │ 20455 │
│ Vulnerabilities │ debian:8 │ true │ 2024-09-30T18:11:55Z │ 24058 │
│ Vulnerabilities │ debian:9 │ true │ 2024-09-30T18:11:55Z │ 28240 │
│ Vulnerabilities │ debian:unstable │ true │ 2024-09-30T18:11:55Z │ 35992 │
│ Vulnerabilities │ mariner:1.0 │ true │ 2024-09-30T18:12:11Z │ 2092 │
│ Vulnerabilities │ mariner:2.0 │ true │ 2024-09-30T18:12:11Z │ 2627 │
│ Vulnerabilities │ ol:5 │ true │ 2024-09-30T18:12:01Z │ 1255 │
│ Vulnerabilities │ ol:6 │ true │ 2024-09-30T18:12:01Z │ 1709 │
│ Vulnerabilities │ ol:7 │ true │ 2024-09-30T18:12:01Z │ 2199 │
│ Vulnerabilities │ ol:8 │ true │ 2024-09-30T18:12:01Z │ 1910 │
│ Vulnerabilities │ ol:9 │ true │ 2024-09-30T18:12:01Z │ 874 │
│ Vulnerabilities │ rhel:5 │ true │ 2024-09-30T18:12:06Z │ 7193 │
│ Vulnerabilities │ rhel:6 │ true │ 2024-09-30T18:12:06Z │ 11129 │
│ Vulnerabilities │ rhel:7 │ true │ 2024-09-30T18:12:06Z │ 11376 │
│ Vulnerabilities │ rhel:8 │ true │ 2024-09-30T18:12:06Z │ 7007 │
│ Vulnerabilities │ rhel:9 │ true │ 2024-09-30T18:12:06Z │ 4040 │
│ Vulnerabilities │ sles:11 │ true │ 2024-09-30T18:12:19Z │ 594 │
│ Vulnerabilities │ sles:11.1 │ true │ 2024-09-30T18:12:19Z │ 6125 │
│ Vulnerabilities │ sles:11.2 │ true │ 2024-09-30T18:12:19Z │ 3291 │
│ Vulnerabilities │ sles:11.3 │ true │ 2024-09-30T18:12:19Z │ 7081 │
│ Vulnerabilities │ sles:11.4 │ true │ 2024-09-30T18:12:19Z │ 6583 │
│ Vulnerabilities │ sles:12 │ true │ 2024-09-30T18:12:19Z │ 6018 │
│ Vulnerabilities │ sles:12.1 │ true │ 2024-09-30T18:12:19Z │ 6205 │
│ Vulnerabilities │ sles:12.2 │ true │ 2024-09-30T18:12:19Z │ 8339 │
│ Vulnerabilities │ sles:12.3 │ true │ 2024-09-30T18:12:19Z │ 10396 │
│ Vulnerabilities │ sles:12.4 │ true │ 2024-09-30T18:12:19Z │ 10215 │
│ Vulnerabilities │ sles:12.5 │ true │ 2024-09-30T18:12:19Z │ 12444 │
│ Vulnerabilities │ sles:15 │ true │ 2024-09-30T18:12:19Z │ 8737 │
│ Vulnerabilities │ sles:15.1 │ true │ 2024-09-30T18:12:19Z │ 9245 │
│ Vulnerabilities │ sles:15.2 │ true │ 2024-09-30T18:12:19Z │ 9573 │
│ Vulnerabilities │ sles:15.3 │ true │ 2024-09-30T18:12:19Z │ 10074 │
│ Vulnerabilities │ sles:15.4 │ true │ 2024-09-30T18:12:19Z │ 10438 │
│ Vulnerabilities │ sles:15.5 │ true │ 2024-09-30T18:12:19Z │ 10882 │
│ Vulnerabilities │ sles:15.6 │ true │ 2024-09-30T18:12:19Z │ 3778 │
│ Vulnerabilities │ ubuntu:12.04 │ true │ 2024-09-30T18:12:37Z │ 14934 │
│ Vulnerabilities │ ubuntu:12.10 │ true │ 2024-09-30T18:12:37Z │ 5641 │
│ Vulnerabilities │ ubuntu:13.04 │ true │ 2024-09-30T18:12:37Z │ 4117 │
│ Vulnerabilities │ ubuntu:14.04 │ true │ 2024-09-30T18:12:37Z │ 37919 │
│ Vulnerabilities │ ubuntu:14.10 │ true │ 2024-09-30T18:12:37Z │ 4437 │
│ Vulnerabilities │ ubuntu:15.04 │ true │ 2024-09-30T18:12:37Z │ 6220 │
│ Vulnerabilities │ ubuntu:15.10 │ true │ 2024-09-30T18:12:37Z │ 6489 │
│ Vulnerabilities │ ubuntu:16.04 │ true │ 2024-09-30T18:12:37Z │ 35057 │
│ Vulnerabilities │ ubuntu:16.10 │ true │ 2024-09-30T18:12:37Z │ 8607 │
│ Vulnerabilities │ ubuntu:17.04 │ true │ 2024-09-30T18:12:37Z │ 9095 │
│ Vulnerabilities │ ubuntu:17.10 │ true │ 2024-09-30T18:12:37Z │ 7908 │
│ Vulnerabilities │ ubuntu:18.04 │ true │ 2024-09-30T18:12:37Z │ 29591 │
│ Vulnerabilities │ ubuntu:18.10 │ true │ 2024-09-30T18:12:37Z │ 8460 │
│ Vulnerabilities │ ubuntu:19.04 │ true │ 2024-09-30T18:12:37Z │ 8742 │
│ Vulnerabilities │ ubuntu:19.10 │ true │ 2024-09-30T18:12:37Z │ 8496 │
│ Vulnerabilities │ ubuntu:20.04 │ true │ 2024-09-30T18:12:37Z │ 25673 │
│ Vulnerabilities │ ubuntu:20.10 │ true │ 2024-09-30T18:12:37Z │ 10112 │
│ Vulnerabilities │ ubuntu:21.04 │ true │ 2024-09-30T18:12:37Z │ 11365 │
│ Vulnerabilities │ ubuntu:21.10 │ true │ 2024-09-30T18:12:37Z │ 12635 │
│ Vulnerabilities │ ubuntu:22.04 │ true │ 2024-09-30T18:12:37Z │ 24135 │
│ Vulnerabilities │ ubuntu:22.10 │ true │ 2024-09-30T18:12:37Z │ 14483 │
│ Vulnerabilities │ ubuntu:23.04 │ true │ 2024-09-30T18:12:37Z │ 15562 │
│ Vulnerabilities │ ubuntu:23.10 │ true │ 2024-09-30T18:12:37Z │ 18433 │
│ Vulnerabilities │ ubuntu:24.04 │ true │ 2024-09-30T18:12:37Z │ 20148 │
│ Vulnerabilities │ wolfi:rolling │ true │ 2024-09-30T18:11:56Z │ 2906 │
│ Vulnerabilities │ anchore:exclusions │ true │ 2024-09-30T18:11:56Z │ 12851 │
│ CISA KEV (Known Exploited Vulnerabilities) │ kev_db │ true │ 2024-09-30T18:07:21Z │ 1185 │
| Exploit Prediction Scoring System Database │ epss_db │ true │ 2024-11-18T18:04:12Z │ 266565 │
└────────────────────────────────────────────┴────────────────────┴─────────┴──────────────────────┴──────────────┘
As soon as you see RecordCount values set for all vulnerability groups, the system is fully populated and ready to present vulnerability results. Note that data syncs are incremental, so the next time you start up Anchore Enterprise it will be ready immediately. The AnchoreCTL includes a useful utility that will block until the feeds have completed a successful sync:
# ./anchorectl system wait
✔ API available system
✔ Services available [10 up] system
✔ Vulnerabilities feed ready system
To get started, you can add a few images to Anchore Enterprise using AnchoreCTL. Once complete, you can also run an additional AnchoreCTL command to monitor the analysis state of the added images, waiting until the images move into an ‘analyzed’ state.
# ./anchorectl image add docker.io/library/alpine:latest
✔ Added Image docker.io/library/alpine:latest
Image:
status: not-analyzed (active)
tag: docker.io/library/alpine:latest
digest: sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870
id: 9c6f0724472873bb50a2ae67a9e7adcb57673a183cea8b06eb778dca859181b5
# ./anchorectl image add docker.io/library/nginx:latest
✔ Added Image docker.io/library/nginx:latest
Image:
status: not-analyzed (active)
tag: docker.io/library/nginx:latest
digest: sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc
id: 2b7d6430f78d432f89109b29d88d4c36c868cdbf15dc31d2132ceaa02b993763
distro: debian@11 (amd64)
layers: 6
# ./anchorectl image list
✔ Fetched images
┌───────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────┬──────────────┬────────┐
│ TAG │ DIGEST │ ANALYSIS │ STATUS │
├───────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────────┼────────┤
│ docker.io/library/alpine:latest │ sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 │ analyzed │ active │
│ docker.io/library/nginx:latest │ sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc │ not_analyzed │ active │
└───────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────┴──────────────┴────────┘
# ./anchorectl image add docker.io/library/nginx:latest --force --wait
⠏ Adding Image docker.io/library/nginx:latest
⠼ Analyzing Image [analyzing] docker.io/library/nginx:latest
...
...
✔ Analyzed Image docker.io/library/nginx:latest
Image:
status: analyzed (active)
tags: docker.io/library/nginx:latest
digest: sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc
id: 2b7d6430f78d432f89109b29d88d4c36c868cdbf15dc31d2132ceaa02b993763
distro: debian@11 (amd64)
layers: 6
# ./anchorectl image list
✔ Fetched images
┌───────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────┬──────────┬────────┐
│ TAG │ DIGEST │ ANALYSIS │ STATUS │
├───────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┼────────┤
│ docker.io/library/alpine:latest │ sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 │ analyzed │ active │
│ docker.io/library/nginx:latest │ sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc │ analyzed │ active │
└───────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────┴──────────┴────────┘
Now that some images are in place, you can point your browser at the Anchore Enterprise UI by directing it to http://localhost:3000/.
Enter the username admin and the password you defined in the compose file to log in. These are some of the features you can use in the browser:
Now that you have Anchore Enterprise running, you can begin to learn more about Anchore capabilities, architecture, concepts, and more.
Uncomment the following section at the bottom of the docker-compose.yaml file:
# # Uncomment this section to add a prometheus instance to gather metrics. This is mostly for quickstart to demonstrate prometheus metrics exported
# prometheus:
# image: docker.io/prom/prometheus:latest
# depends_on:
# - api
# volumes:
# - ./anchore-prometheus.yml:/etc/prometheus/prometheus.yml:z
# logging:
# driver: "json-file"
# options:
# max-size: 100m
# ports:
# - "9090:9090"
#
For each service entry in the docker-compose.yaml, change the following to enable metrics in the API for each service
ANCHORE_ENABLE_METRICS=false
to
ANCHORE_ENABLE_METRICS=true
Download the example prometheus configuration into the same directory as the docker-compose.yaml file, with name anchore-prometheus.yml:
curl https://docs.anchore.com/current/docs/deployment/anchore-prometheus.yml > anchore-prometheus.yml
docker compose up -d
Result: You should see a new container started and can access prometheus via your browser on http://localhost:9090.
Uncomment the following section at the bottom of the docker-compose.yaml file:
# # Uncomment this section to run a swagger UI service, for inspecting and interacting with the system API via a browser (http://localhost:8080 by default, change if needed in both sections below)
# swagger-ui-nginx:
# image: docker.io/nginx:latest
# depends_on:
# - api
# - swagger-ui
# ports:
# - "8080:8080"
# volumes:
# - ./anchore-swaggerui-nginx.conf:/etc/nginx/nginx.conf:z
# logging:
# driver: "json-file"
# options:
# max-size: 100m
# swagger-ui:
# image: docker.io/swaggerapi/swagger-ui
# environment:
# - URL=http://localhost:8080/v2/openapi.json
# logging:
# driver: "json-file"
# options:
# max-size: 100m
Download the nginx configuration into the same directory as the docker-compose.yaml file, with name anchore-swaggerui-nginx.conf:
curl https://docs.anchore.com/current/docs/deployment/anchore-swaggerui-nginx.conf > anchore-swaggerui-nginx.conf
docker compose up -d
Result: You should see a new container started, and have access Swagger UI via your browser on http://localhost:8080.
The supported method for deploying Anchore Enterprise on Kubernetes is with Helm. The Anchore Enterprise Helm Chart includes configuration options for a full Enterprise deployment.
Important Release Notes can be found in the README in the chart repository
The chart is split into global and service specific configurations for the core features, as well as global and services specific configurations for the optional Enterprise services.
anchoreConfig section of the values file contains the application configuration for Anchore Enterprise. This includes the database connection information, credentials, and other application settings.For a description of each service component see Anchore Enterprise Service Overview
Note If you are moving from the Anchore Engine Helm chart deployment to the updated Anchore Enterprise Helm chart, see here for further guidance.
See the README in the chart repository for prequisities before starting the deployment.
This guide covers deploying Anchore Enterprise on a Kubernetes cluster with the default configuration. Refer to the Configuration section of the chart README for additional guidance on production deployments.
Create the namespace: The steps to follow will require the namespace to have been created already.
export NAMESPACE=anchore
kubectl create namespace ${NAMESPACE}
Create a Kubernetes Secret for License File: Generate a Kubernetes secret to store your Anchore Enterprise license file.
export NAMESPACE=anchore
export LICENSE_PATH="license.yaml"
kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=${LICENSE_PATH} -n ${NAMESPACE}
Create a Kubernetes Secret for DockerHub Credentials: Generate another Kubernetes secret for DockerHub credentials. These credentials should have access to private Anchore Enterprise repositories. We recommend that you create a brand new DockerHub user for these pull credentials. Contact Anchore Support to obtain access.
export NAMESPACE=anchore
export DOCKERHUB_PASSWORD="password"
export DOCKERHUB_USER="username"
export DOCKERHUB_EMAIL="[email protected]"
kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=${DOCKERHUB_USER} --docker-password=${DOCKERHUB_PASSWORD} --docker-email=${DOCKERHUB_EMAIL} -n ${NAMESPACE}
Add Chart Repository & Deploy Anchore Enterprise: Create a custom values file, named anchore_values.yaml, to override any chart parameters. Refer to the Parameters section for available options.
Important: Default passwords are specified in the chart. It’s highly recommended to modify these before deploying.
Note: The RELEASE variable should not contain any dots.
export NAMESPACE=anchore
export RELEASE=my-release
helm repo add anchore https://charts.anchore.io
helm install ${RELEASE} -n ${NAMESPACE} anchore/enterprise -f anchore_values.yaml
Note: This command installs Anchore Enterprise with a chart-managed PostgreSQL database, which may not be suitable for production use. See the External Database section of the chart README for details on using an external database.
Post-Installation Steps: Anchore Enterprise will take some time to initialize. After the bootstrap phase, it will begin a vulnerability feed sync. Image analysis will show zero vulnerabilities, and the UI will show errors until this sync is complete. This can take several hours based on the enabled feeds. Use the following anchorectl commands to check the system status:
export NAMESPACE=anchore
export RELEASE=my-release
export ANCHORECTL_URL=http://localhost:8228
export ANCHORECTL_PASSWORD=$(kubectl get secret "${RELEASE}-enterprise" -o jsonpath='{.data.ANCHORE_ADMIN_PASSWORD}' | base64 -d -)
kubectl port-forward -n ${NAMESPACE} svc/${RELEASE}-enterprise-api 8228:8228 # port forward for anchorectl in another terminal
anchorectl system status # anchorectl defaults to the user admin, and to the password ${ANCHORECTL_PASSWORD} automatically if set
Tip: List all releases using
helm list
Now that you have Anchore Enterprise running, you can begin to learning more about Anchore Enterprise architecture, Anchore concepts, and Anchore usage.
This document will walk you through the deployment of Anchore Enterprise in an Azure Kubernetes Service (AKS) cluster and expose it on the public Internet.
Once you have an AKS cluster up and running with worker nodes launched, you can verity via the following command.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-28659018-0 Ready agent 4m13s v1.13.10
aks-nodepool1-28659018-1 Ready agent 4m15s v1.13.10
aks-nodepool1-28659018-2 Ready agent 4m6s v1.13.10
Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise deployment of the chart will include the following:
To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore, this document is intended to cover the minimum required changes to successfully deploy Anchore Enterprise in AKS.
Note: For this installation, an NGINX ingress controller will be used. You can read more about Kubernetes Ingress in AKS here.
Make the following changes below to your anchore_values.yaml
ingress:
enabled: true
labels: {}
apiPaths:
- /v2/
uiPath: /
annotations:
kubernetes.io/ingress.class: nginx
Note: Configuring ingress is optional. It is used throughout this guide to expose the Anchore deployment on the public internet.
# Pod configuration for the anchore api service.
api:
# kubernetes service configuration for anchore external API
service:
type: NodePort
port: 8228
annotations: {}
Note: Changed the service type to NodePort
ui:
# kubernetes service configuration for anchore UI
service:
type: NodePort
port: 80
annotations: {}
sessionAffinity: ClientIP
Note: Changed service type to NodePort.
Using Helm, install an NGINX ingress controller in your AKS cluster.
helm install stable/nginx-ingress --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux
Enterprise services require an Anchore Enterprise license, as well as credentials with permission to access the private DockerHub repository containing the enterprise software.
Create a Kubernetes secret containing your license file:
kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=<PATH/TO/LICENSE.YAML>
Create a Kubernetes secret containing DockerHub credentials with access to the private Anchore Enterprise software:
kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<DOCKERHUB_USER> --docker-password=<DOCKERHUB_PASSWORD> --docker-email=<EMAIL_ADDRESS>
Deploy Anchore Enterprise:
helm repo add anchore https://charts.anchore.io
helm install anchore anchore/enterprise -f anchore_values.yaml
It will take the system several minutes to bootstrap. You can checks on the status of the pods by running kubectl get pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs 1/1 Running 0 13m
anchore-enterprise-api-754cdb48bc-x8kxt 3/3 Running 0 13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb 1/1 Running 0 13m
anchore-enterprise-notifications-65bd45459f-q28h2 2/2 Running 0 13m
anchore-enterprise-policy-657fdfd7f6-gzkmh 1/1 Running 0 13m
anchore-enterprise-reports-596cb47894-q8g49 1/1 Running 0 13m
anchore-enterprise-simplequeue-98b95f985-5xqcv 1/1 Running 0 13m
anchore-enterprise-ui-6794bbd47-vxljt 1/1 Running 0 13m
anchore-feeds-77b8976c4c-rs8h2 1/1 Running 0 13m
anchore-feeds-db-0 1/1 Running 0 13m
anchore-postgresql-0 1/1 Running 0 13m
anchore-ui-redis-master-0 1/1 Running 0 13m
mangy-serval-nginx-ingress-controller-788dd98c8b-jv2wg 1/1 Running 0 21m
mangy-serval-nginx-ingress-default-backend-8686cd585b-4m2bt 1/1 Running 0 21m
We can see that NGINX ingress controller has been installed as well from the previous step. You can view the services by running the following command:
$ kubectl get services | grep ingress
mangy-serval-nginx-ingress-controller LoadBalancer 10.0.30.174 40.114.26.147 80:31176/TCP,443:30895/TCP 22m
mangy-serval-nginx-ingress-default-backend ClusterIP 10.0.243.221 <none> 80/TCP 22m
Note: The above output shows us that IP address of the NGINX ingress controller is 40.114.26.147. Going to this address in the browser will take us to the Anchore login page.
Check the status of the system with AnchoreCTL to verify all of the Anchore services are up:
Note: Read more on Deploying AnchoreCTL
ANCHORECTL_URL=http://40.114.26.147/v2/ ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl system status
It can take some time to fetch all of the vulnerability feeds from the upstream data sources. Check on the status of feeds with AnchoreCTL:
ANCHORECTL_URL=http://40.114.26.147/v2/ ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl feed list
Note: It is not uncommon for the above command to return a: [] as the initial feed sync occurs.
Once the vulnerability feed sync is complete, Anchore can begin to return vulnerability results on analyzed images. Please continue to the Vulnerability Management section of our documentation for more information.
Get an understanding of the deployment of Anchore Enterprise on an Amazon EKS cluster and expose it on the public Internet.
Note when using AWS consider utilizing Amazon RDS for a managed database service.
Once you have an EKS cluster up and running with worker nodes launched, you can verify it using the following command.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-192-168-2-164.ec2.internal Ready <none> 10m v1.14.6-eks-5047ed
ip-192-168-35-43.ec2.internal Ready <none> 10m v1.14.6-eks-5047ed
ip-192-168-55-228.ec2.internal Ready <none> 10m v1.14.6-eks-5047ed
Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise deployment of the chart will include the following:
To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore. The following is intended to cover the minimum required changes to successfully deploy Anchore Enterprise on Amazon EKS.
Note: For this installation, an ALB ingress controller will be used. You can read more about Kubernetes Ingress with AWS Load Balancer Controller here
Make the following changes below to your anchore_values.yaml
ingress:
enabled: true
apiPaths:
- /v2/
- /version/
uiPath: /
ingressClassName: alb
annotations:
# See https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/docs/guide/ingress/annotations.md for further customization of annotations
alb.ingress.kubernetes.io/scheme: internet-facing
# If you do not plan to bring your own hostname (i.e. use the AWS supplied CNAME for the load balancer) then you can leave apiHosts & uiHosts as empty lists:
apiHosts: []
uiHosts: []
# If you plan to bring your own hostname then you'll likely want to populate them as follows:
# apiHosts:
# - anchore.mydomain.com
# uiHosts:
# - anchore.mydomain.com
Note: There are alternative ways to access services within your EKS cluster besides ingress. It is used throughout this guide to expose the Anchore deployment on the public (or private) internet.
# Pod configuration for the anchore engine api service.
api:
# kubernetes service configuration for anchore external API
service:
type: NodePort
port: 8228
annotations: {}
Note: Changed the service type to NodePort
ui:
# kubernetes service configuration for anchore UI
service:
type: NodePort
port: 80
annotations: {}
sessionAffinity: ClientIP
Note: Changed service type to NodePort.
Please reference https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/docs/deploy/installation.md for installing and configuring AWS load balancer controller (fka alb-ingress-controller).
Enterprise services require an Anchore Enterprise license, as well as credentials with permission to access the private DockerHub repository containing the enterprise software.
Create a Kubernetes secret containing your license file:
kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=<PATH/TO/LICENSE.YAML>
Create a Kubernetes secret containing DockerHub credentials with access to the private Anchore Enterprise software:
kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<DOCKERHUB_USER> --docker-password=<DOCKERHUB_PASSWORD> --docker-email=<EMAIL_ADDRESS>
Deploy Anchore Enterprise:
helm repo add anchore https://charts.anchore.io
helm install anchore anchore/enterprise -f anchore_values.yaml
It will take the system several minutes to bootstrap. You can checks on the status of the pods by running kubectl get pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs 1/1 Running 0 13m
anchore-enterprise-api-754cdb48bc-x8kxt 3/3 Running 0 13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb 1/1 Running 0 13m
anchore-enterprise-notifications-65bd45459f-q28h2 2/2 Running 0 13m
anchore-enterprise-policy-657fdfd7f6-gzkmh 1/1 Running 0 13m
anchore-enterprise-reports-596cb47894-q8g49 1/1 Running 0 13m
anchore-enterprise-simplequeue-98b95f985-5xqcv 1/1 Running 0 13m
anchore-enterprise-ui-6794bbd47-vxljt 1/1 Running 0 13m
anchore-feeds-77b8976c4c-rs8h2 1/1 Running 0 13m
anchore-feeds-db-0 1/1 Running 0 13m
anchore-postgresql-0 1/1 Running 0 13m
anchore-ui-redis-master-0 1/1 Running 0 13m
Run the following command for details on the deployed ingress resource:
$ kubectl describe ingress
Name: anchore-enterprise
Namespace: default
Address: xxxxxxx-default-anchoreen-xxxx-xxxxxxxxx.us-east-1.elb.amazonaws.com
Default backend: default-http-backend:80 (<none>)
Rules:
Host Path Backends
---- ---- --------
*
/v2/* anchore-enterprise-api:8228 (192.168.42.122:8228)
/* anchore-enterprise-ui:80 (192.168.14.212:3000)
Annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
kubernetes.io/ingress.class: alb
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal CREATE 14m alb-ingress-controller LoadBalancer 904f0f3b-default-anchoreen-d4c9 created, ARN: arn:aws:elasticloadbalancing:us-east-1:077257324153:loadbalancer/app/904f0f3b-default-anchoreen-d4c9/4b0e9de48f13daac
Normal CREATE 14m alb-ingress-controller rule 1 created with conditions [{ Field: "path-pattern", Values: ["/v2/*"] }]
Normal CREATE 14m alb-ingress-controller rule 2 created with conditions [{ Field: "path-pattern", Values: ["/*"] }]
The output above shows that an ELB has been created. Navigate to the specified URL in a browser:
Check the status of the system with AnchoreCTL to verify all of the Anchore services are up:
Note: Read more on Deploying AnchoreCTL
ANCHORECTL_URL=http://xxxxxx-default-anchoreen-xxxx-xxxxxxxxxx.us-east-1.elb.amazonaws.com ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl system status
It can take some time to fetch all of the vulnerability feeds from the upstream data sources. Check on the status of feeds with AnchoreCTL:
ANCHORECTL_URL=http://xxxxxx-default-anchoreen-xxxx-xxxxxxxxxx.us-east-1.elb.amazonaws.com ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl feed list
Note: It is not uncommon for the above command to return a: [] as the initial feed sync occurs.
Once the vulnerability feed sync is complete, Anchore can begin to return vulnerability results on analyzed images. Please continue to the Vulnerability Management section of our documentation for more information.
Get an understanding of deploying Anchore Enterprise on a Google Kubernetes Engine (GKE) cluster and exposing it on the public Internet.
Note when using Google Cloud, consider utilizing Cloud SQL for PostgreSQL as a managed database service.
Once you have a GKE cluster up and running with worker nodes launched, you can verify it by using the followiing command.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-standard-cluster-1-default-pool-c04de8f1-hpk4 Ready <none> 78s v1.13.7-gke.24
gke-standard-cluster-1-default-pool-c04de8f1-m03k Ready <none> 79s v1.13.7-gke.24
gke-standard-cluster-1-default-pool-c04de8f1-mz3q Ready <none> 78s v1.13.7-gke.24
Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise deployment of the chart will include the following:
To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore. The following is intended to cover the minimum required changes to successfully deploy Anchore Enterprise on Google Kubernetes Engine.
Note: For this deployment, a GKE ingress controller will be used. You can read more about Kubernetes Ingress with a GKE Ingress Controller here
Make the following changes below to your anchore_values.yaml
ingress:
enabled: true
apiPaths:
- /v2/*
uiPath: /*
Note: Configuring ingress is optional. It is used throughout this guide to expose the Anchore deployment on the public internet.
api:
replicaCount: 1
# kubernetes service configuration for anchore external API
service:
type: NodePort
port: 8228
annotations: {}
Note: Changed the service type to NodePort
ui:
# kubernetes service configuration for anchore UI
service:
type: NodePort
port: 80
annotations: {}
sessionAffinity: ClientIP
Note: Changed service type to NodePort.
Enterprise services require an Anchore Enterprise license, as well as credentials with permission to access the private DockerHub repository containing the enterprise software.
Create a Kubernetes secret containing your license file:
kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=<PATH/TO/LICENSE.YAML>
Create a Kubernetes secret containing DockerHub credentials with access to the private Anchore Enterprise software:
kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<DOCKERHUB_USER> --docker-password=<DOCKERHUB_PASSWORD> --docker-email=<EMAIL_ADDRESS>
Deploy Anchore Enterprise:
helm repo add anchore https://charts.anchore.io
helm install anchore anchore/enterprise -f anchore_values.yaml
It will take the system several minutes to bootstrap. You can checks on the status of the pods by running kubectl get pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs 1/1 Running 0 13m
anchore-enterprise-api-754cdb48bc-x8kxt 3/3 Running 0 13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb 1/1 Running 0 13m
anchore-enterprise-notifications-65bd45459f-q28h2 2/2 Running 0 13m
anchore-enterprise-policy-657fdfd7f6-gzkmh 1/1 Running 0 13m
anchore-enterprise-reports-596cb47894-q8g49 1/1 Running 0 13m
anchore-enterprise-simplequeue-98b95f985-5xqcv 1/1 Running 0 13m
anchore-enterprise-ui-6794bbd47-vxljt 1/1 Running 0 13m
anchore-feeds-77b8976c4c-rs8h2 1/1 Running 0 13m
anchore-feeds-db-0 1/1 Running 0 13m
anchore-postgresql-0 1/1 Running 0 13m
anchore-ui-redis-master-0 1/1 Running 0 13m
Run the following command for details on the deployed ingress resource:
$ kubectl describe ingress
Name: anchore-enterprise
Namespace: default
Address: 34.96.64.148
Default backend: default-http-backend:80 (10.8.2.6:8080)
Rules:
Host Path Backends
---- ---- --------
*
/v2/* anchore-enterprise-api:8228 (<none>)
/* anchore-enterprise-ui:80 (<none>)
Annotations:
kubernetes.io/ingress.class: gce
ingress.kubernetes.io/backends: {"k8s-be-31175--55c0399dc5755377":"HEALTHY","k8s-be-31274--55c0399dc5755377":"HEALTHY","k8s-be-32037--55c0399dc5755377":"HEALTHY"}
ingress.kubernetes.io/forwarding-rule: k8s-fw-default-anchore-enterprise--55c0399dc5750
ingress.kubernetes.io/target-proxy: k8s-tp-default-anchore-enterprise--55c0399dc5750
ingress.kubernetes.io/url-map: k8s-um-default-anchore-enterprise--55c0399dc5750
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 15m loadbalancer-controller default/anchore-enterprise
Normal CREATE 14m loadbalancer-controller ip: 34.96.64.148
The output above shows that an Load Balancer has been created. Navigate to the specified URL in a browser:
Check the status of the system with AnchoreCTL to verify all of the Anchore services are up:
Note: Read more on Deploying AnchoreCTL
ANCHORECTL_URL=http://34.96.64.148 ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl system status
It can take some time to fetch all of the vulnerability feeds from the upstream data sources. Check on the status of feeds with Anchore CTL:
ANCHORECTL_URL=http://34.96.64.148 ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl feed list
Note: It is not uncommon for the above command to return a: [] as the initial feed sync occurs.
Once the vulnerability feed sync is complete, Anchore can begin to return vulnerability results on analyzed images. Please continue to the Vulnerability Management section of our documentation for more information.
This document will walkthrough the deployment of Anchore Enterprise on an OpenShift Kubernetes Distribution (OKD) 3.11 cluster and expose it on the public internet.
Note: While this document walks through deploying on OKD 3.11, it has been successfully deployed and tested on OpenShift 4.2.4 and 4.2.7.
Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise installation of the chart will include the following:
To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore, this document is intended to cover the minimum required changes to successfully deploy Anchore Enterprise on OKD 3.11.
Create a new project called anchore-enterprise:
oc new-project anchore-enterprise
Two secrets are required for an Anchore Enterprise deployment.
Create a secret for the license file:
oc create secret generic anchore-enterprise-license --from-file=license.yaml=license.yaml
Create a secret for pulling the images:
oc create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<username> --docker-password=<password> --docker-email=<email>
Verify these secrets are in the correct namespace: anchore-enterprise
oc describe secret <secret-name>
Link the above Docker registry secret to the default service account:
oc secrets link default anchore-enterprise-pullcreds --for=pull --namespace=anchore-enterprise
Verify this by running the following:
oc describe sa
Note: Validate your OpenShift SCC. Based on the security constraints of your environment, you may need to change SCC. oc adm policy add-scc-to-user anyuid -z default
Create a custom anchore_values.yaml file for your Anchore Enterprise deployment:
# NOTE: This is not a production ready values file for an openshift deployment.
securityContext:
fsGroup: null
runAsGroup: null
runAsUser: null
postgresql:
primary:
containerSecurityContext:
enabled: false
podSecurityContext:
enabled: false
ui-redis:
master:
podSecurityContext:
enabled: false
containerSecurityContext:
enabled: false
Run the following command to install the software:
helm repo add anchore https://charts.anchore.io
helm install anchore -f values.yaml anchore/enterprise
It will take the system several minutes to bootstrap. You can checks on the status of the pods by running oc get pods:
$ oc get pods
NAME READY STATUS RESTARTS AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs 1/1 Running 0 13m
anchore-enterprise-api-754cdb48bc-x8kxt 1/1 Running 0 13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb 1/1 Running 0 13m
anchore-enterprise-notifications-65bd45459f-q28h2 1/1 Running 0 13m
anchore-enterprise-policy-657fdfd7f6-gzkmh 1/1 Running 0 13m
anchore-enterprise-reports-596cb47894-q8g49 1/1 Running 0 13m
anchore-enterprise-simplequeue-98b95f985-5xqcv 1/1 Running 0 13m
anchore-enterprise-ui-6794bbd47-vxljt 1/1 Running 0 13m
anchore-enterprise-datasyncer-585997576d-2fgkg 1/1 Running 0 13m
anchore-enterprise-reportsworker-6fb4f55455-f2ts2 1/1 Running 0 13m
anchore-postgresql-0 1/1 Running 0 13m
anchore-ui-redis-master-0 1/1 Running 0 13m
Create two route object in the OpenShift console to expose the UI and API services on the public internet:
Note: Route configuration is optional. It is used throughout this guide to expose the Anchore deployment on the public internet.
Verify by navigating to the anchore-enterprise-ui route hostname:
First you will need to retrieve the admin password. This is stored as a secret during the helm install process
oc get secret anchore-enterprise-env -o jsonpath='{.data.ANCHORE_ADMIN_PASSWORD}' -n anchore | base64 -d
You can use customize your helm values.yaml file to use an existing / custom secrets rather than have help generate one for you with a generated password.
Verify API route hostname with AnchoreCTL:
Note: Read more on Deploying AnchoreCTL
ANCHORECTL_URL=http://anchore-engine-anchore-enterprise.apps.54.84.147.202.nip.io \
ANCHORECTL_USERNAME=admin \
ANCHORECTL_PASSWORD=foobar \
anchorectl system status
#### Anchore Vulnerability data
Anchore has a datasyncer service that pulls the vulnerability and other data sources such as ClamAV malware database into your Anchore deployment. You can check on the status of these feed data using AnchoreCTL:
```shell
ANCHORECTL_URL=http://anchore-engine-anchore-enterprise.apps.54.84.147.202.nip.io \
ANCHORECTL_USERNAME=admin \
ANCHORECTL_PASSWORD=foobar \
anchorectl feed list
Note: Please continue to the Vulnerability Management section of our documentation for more information about Vulnerability Management within Anchore.
In this section you will learn how to deploy and configure AnchoreCTL, the Anchore Enterprise Command Line Interface.
AnchoreCTL is published as a simple binary available for download either from your Anchore Enterprise deployment or Anchore’s release site.
Using AnchoreCTL, you can manage and inspect all aspects of your Anchore Enterprise deployments, either as a manual human-readable configuration/instrumentation/control tool or as a CLI that is designed to be used in scripted environments such as CI/CD and other automation environments.
AnchoreCTL’s major and minor release version coincides with the release version of Anchore Enterprise, however patch versions may differ. For example,
Important It is highly recommended that the version of AnchoreCTL you are using is supported by the deployed version of Enterprise. Please refer to the Enterprise Release Notes for the supported version of AnchoreCTL.
Specify a release version and destination directory for the installation, the script will download the relevant AnchoreCTL for your environment:
curl -sSfL https://anchorectl-releases.anchore.io/anchorectl/install.sh | sh -s -- -b <DESTINATION_DIR> v5.13.0
Download a local (from your Anchore deployment) or remote (from Anchore servers) version without installation:
Linux Intel/AMD64
# Local
curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*"
# Remote
curl -o anchorectl.tar.gz https://anchorectl-releases.anchore.io/anchorectl/v5.13.0/anchorectl_5.13.0_linux_amd64.tar.gz
MacOS Intel/AMD64
# Local
curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=darwin&architecture=amd64" -H "accept: */*"
# Remote
curl -o anchorectl.tar.gz https://anchorectl-releases.anchore.io/anchorectl/v5.13.0/anchorectl_5.13.0_darwin_amd64.tar.gz
MacOS ARM/M-Series
# Local
curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=darwin&architecture=arm64" -H "accept: */*"
# Remote
curl -o anchorectl.tar.gz https://anchorectl-releases.anchore.io/anchorectl/v5.13.0/anchorectl_5.13.0_darwin_arm64.tar.gz
For windows, you must specify the version of AnchoreCTL to download if using a script.
curl -o anchorectl.zip https://anchorectl-releases.anchore.io/anchorectl/v5.13.0/anchorectl_5.13.0_windows_amd64.zip
Once AnchoreCTL has been installed, learn about AnchoreCTL Configuration.
Anchore Enterprise can run in an isolated environment with no outside internet connectivity. It does require a network connection to its own components and must be able to reach registries (Docker v2 API compatible) where the images to be analyzed are hosted.
Air-gapped deployment follows the standard deployment procedure for either Docker Compose or Kubernetes with Helm.
To ensure that the Anchore Enterprise installation has up-to-date vulnerability data from the vulnerability sources, you will need to periodically download and import feed data into your Anchore Enterprise deployment. Details on how to do this can be found in the Air-Gapped Configuration.
For more detail regarding the Anchore Data Service, please see Anchore Data Service.