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

Return to the regular view of this page.

Verifying Feeds

Anchore Enterprise runs a feed service which downloads vulnerability data from a number of configurable sources.

This data is stored on disk and is processed into a holistic vulnerability dataset. Once built and compiled, the dataset is stored in a postgres database and served to other Anchore Enterprise application services via an API endpoint.

The API endpoint is periodically queried by the policy service to fetch the latest dataset. If a newer vulnerability dataset is available, the policy service will download and propagate the new dataset across all instances/pods. This updated data is used to generate vulnerability analysis results.

The accuracy of vulnerability analysis is determined by the ability for your Anchore Enterprise deployment to download, store and distribute this feed data. Ensuring the health of this process is critical to the operation of the platform.

Performing a basic health check

Run $ anchorectl feed list as admin and ensure that:

  • The last sync date shown is recent and that the feed has enabled set to true.
  • Review the feed list to see if you have the required feed sources enabled.
    • Missing an expected source? Review the configuration and operational sections on this page

Run $ anchorectl feed sync as admin which will:

  • Queue an update to fetch and propagate feed data across internal services.
    • Otherwise, this runs on a regular schedule.
    • Note: It can take several hours to download, build and distribute the dataset.

You can also visually check the health in the ‘System’ section of the UI when logged in as admin.

Anchore Enterprise relies on multiple sources in order to build a high resolution picture of vulnerability data. It is generally recommended that all vendor sources are enabled.

We highly recommend that you enable the GitHub GHSA feed for high quality vulnerability data

  • This can often be misconfigured due to the nature of the nested feeds property in helm values file, due to the feeds service being a dependancy and independent chart.
  • You must also ensure you set a valid GitHub Token, see below for a complete Helm values example.
feeds:
  anchoreConfig:
    feeds:
      drivers:
        github:
          enabled: true
          # The GitHub feeds driver requires a GitHub developer personal access token with no permission scopes selected.
          # See https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token
          token: your-github-token

Enable the applicable feeds within Anchore e.g. if you use Ubuntu base images, enable the vendor specific feed in this case: Ubuntu. See Helm values example below

feeds:
  anchoreConfig:
    feeds:
      drivers:
        PROVIDER: true

For an air-gapped environment your high side feed service should be configured with api_only = true. This will ensure the feed service will only serve built databases stored locally.

Finally, operate your feeds database on a separate server to the anchore server. This ensures separation of concerns, ease of backup and less performance impacts. Where possible use a managed postgres service like RDS.

Operational & Configuration checks

Check that the feed pod/container has enough disk space:

  • Ensure free disk space is (>10gb). The /workspace directory is where feed data is stored. By running:
    $ df -h

Check that the feed pod/container and the feeds database has enough compute, memory and disk resources as covered in requirements

Check that your feed service has network connectivity to feed sources:

  • Ensure the feed pod / container has network connectivity to feed sources.
    • You can verify this by running a curl check - example: $ curl -v https://secdb.alpinelinux.org
    • For other feed sources, you can find the domains listed here.
  • If you have a network proxy deployed, you might need to configure the feed service to use it:
    • Depending on proxy, you might also require embedding your proxy cert into the Anchore Enterprise image as per instructions here.
      • You can test this by running $ curl -v https://secdb.alpinelinux.org and verifying the output returns “SSL certificate verify ok.”

Check that the policy service has been configured to use your local feed service:

  • Check your policy pod / container configuration by reviewing
    • Run $ cat '/config/config.yaml' and check policy_engine.vulnerabilities.sync.data.grypedb.url is set.
    • Ensure the set value or set ENV $ echo $ANCHORE_GRYPE_DB_URL points to your local feed service.
  • Ensure your policy pod / container has network connectivity to your local feed pod / container
    • Run $ curl -v ${ANCHORE_GRYPE_DB_URL} returns a response to confirm connectivity.

Check that your desired configuration has been correctly applied for both the feeds and policy services:

  • On the feeds or policy pod / container run $ cat '/config/config.yaml'
    • Review the configuration displayed matches your desired configuration.
    • Any issues review your deployment process e.g. helm values

Finally, it should be noted, the feed service can take several hours to download, build and distribute an updated vulnerability dataset:

  • To check the status of a feeds sync you can:

    • Review the feed logs, and even enable DEBUG for increased verbosity.
    • Use the tasks api to return a tasks summary $ curl ${ANCHORE_ENTERPRISE_FEEDS_EXTERNAL_URL}/tasks and for localising results use specific $ curl ${ANCHORE_ENTERPRISE_FEEDS_EXTERNAL_URL}/tasks/<parent-id-or-task-id>.
    • Use the feeds databases/grypedb endpont and review results $ curl -v ${ANCHORE_GRYPE_DB_URL};

  • NOTE: On occasion a feed source might be experiencing downtime or a maintenance window. In this scenario, the feeds service will continue to operate for the remaining providers and will retry on the next run.