API Accessible Configuration

Anchore Enterprise provides the ability to view the majority of system configurations via the API. A select number of configurations can also be modified through the API, or through the System Configuration tab from the UI. This enables control of system behaviours and characteristics in a programmatic way without needing to restart your deployment.

Configuration Provenance

Configuration values are established by a priority system which derives the final running value based on the location from which the value was read. This provenance priority mechanism enables backwards compatibility and increased security for customers wishing tighter control of their systems runtime.

1. Config File Source

Any configuration variable which is declared within an on-disk configuration file will be honored first (ie. via a Helm values.yaml). These configuration variables will be read-only through the API and UI. Any configuration that is currently set for your deployment will be preserved.

2. API Config Source

When a configuration variable is not declared in a config file and is one of the select few that are allowed to be modified via the API, its value will be stored in the system database. These configuration variables can be modified via the API and the changes will be reflected within the deployment within a short time without having to restart your deployment.

The following configuration variables are modifiable through the API:

• services.analyzer.analyzer_scanner_config.malware.clamav.enabled
• logging.log_level
• services.apiext.logging.log_level
• services.analyzer.logging.log_level
• services.catalog.logging.log_level
• services.policy_engine.logging.log_level
• services.simplequeue.logging.log_level
• services.notifications.logging.log_level
• services.data_syncer.logging.log_level
• services.reports.logging.log_level
• services.reports_worker.logging.log_level

3. Anchore Enterprise Defaults

If a configuration variable has not been declared by any other source it inherits the default system value. These are values chosen by Anchore as safe and functional defaults.

For the majority of deployments we recommend you simply use the default settings for most values as they have been calibrated to offer the best experience out of the box.

⚠️ Note: These values may change from release to release. Notable changes will be communicated through Release Notes. Significant system behaviour changes will not be performed between minor releases. If you wish to ensure a default is not changed, “pin” the value either by providing it explicitly in the config file or setting it directly via the API (when available).

Blocked by Config File

Attempts to set a configurations through the API may return a blocked_by_config_file error. This error is raised when a configuration key is not API editable as it is set in a config file.

Locations to inspect for a pinned config value are:

• the Helm attached values.yaml file (continue reading for further instructions)
• the compose attached config.yaml file
• the environment keys being passed into the container

Some system deployers can lock certain configurations down through configuration files (ie “Git-ops”). These declared values are runtime immutable and are only editable through further config file changes.

Disabling Helm Chart Configs

For Helm users, to make a value configurable through the API, set the value in the attached values.yaml to "<ALLOW_API_CONFIGURATION>"

As an example:

services:
  analyzer:
      malware:
        clamav:
          enabled: "<ALLOW_API_CONFIGURATION>"

Disabling API driven configuration

By default, API driven configurations are enabled for all deployments. However, if you run a deployment where you wish to strictly enforce only explicit configuration through on-disk config files you may enable it by setting the following value, at the root of your config file:

configuration:
  api_driven_configuration_enabled: false

API configurations refresh

Each running container will refresh its internal configuration state approximately every 30 seconds. After making a change please allow a minute to elapse for the changes to flush out to all running nodes.

Config file configurations refresh

Changes made to a mounted config file will be detected and will cause a system configuration refresh, if a key is changed that requires a system restart a log message will be printed to that effect. If a system is pending restart, none of the changes will take effect until this is performed. This config file watcher includes a mounted .env file if in use.

Strict mode

In a future release of Anchore we will be enabling a strict mode type and data validation to our configuration. This will result in non-compliant Enterprise deployments refusing to boot. For now this is not enforced. On system boot; you will see a log message mentioning lenient mode if strict mode validation has failed. This will be accompanied by detail on what entries have failed. To avoid system downtime in a future major release consider resolving these issues.

Secret values

Secret values cannot be read through the API, they will return as the string <redacted> it is however possible to update them. It is not possible to set any secret value to the string <redacted>.

Backwards compatibility

This new API system maintains backwards compatibility with all existing deployments. It continues to support the “Git-ops” approach to deploy Anchore Enterprise through commit-able config files.

Security permissions

Config file permissions have not changed, they are editable by the system deployer. API requests to make changes to configuration will only be accepted if coming from an Anchore admin account.