Providing the Feature-Key File

Overview

This page describes the feature-key file and how to use it.

The feature-key file is a cryptographically-signed list of enabled server features, issued upon purchase of a paid version of Aerospike Database. Aerospike Database Enterprise Edition (EE) and Aerospike Database Standard Edition (SE) require a feature-key file to start up. Aerospike Database Community Edition (CE) does not use a feature-key file.

Starting with Database 6.1, a default feature-key file is included with Aerospike EE. This feature-key file provides a single-node evaluation for developers, so customers should swap in their production feature-key file before deploying to production.

If the server cannot find the feature-key file, it exits early in its startup sequence with the following log message:

Apr 09 2021 06:35:12 GMT: CRITICAL (config): (features_ee.c:142) failed to get feature-key /etc/aerospike/features.conf

Loading the feature-key file

The server can load the feature-key file from the following sources:

• The filesystem
• An environment variable
• HashiCorp Vault
• An external secrets management service using Aerospike Secret Manager

From the filesystem

The default path to the feature-key file is /etc/aerospike/features.conf. If you want to use a different file location, you can add the feature-key-file configuration parameter to the service stanza.

service {
    feature-key-file /path/to/feature-key.conf
}

The path can also be a directory, where all the files it contains are feature-key files. The server checks each one for validity and expiration, and merges valid ones into its feature set. This feature is useful for limited-time trials of new features.

service {
    feature-key-file /path/to/feature-key.d/
}

The feature-key directory behavior was added in Database 5.5.

note

If multiple feature-key files include asdb-cluster-nodes-limit, the highest non-zero value restricts the cluster size.

From an environment variable

You can set the feature-key file in an environment variable as a base64-encoded secret.

export MY_FEATURE_FILE=$(base64 ~/evaluation-features.conf)

Now configure the feature-key-file parameter to load the secret from the environment variable. The prefix env-b64: is a literal string.

service {
    feature-key-file env-b64:MY_FEATURE_FILE
}

From HashiCorp Vault

The server can fetch the feature-key file from HashiCorp Vault servers, such as HCP Vault. The prefix vault: is a literal string.

service {
    feature-key-file vault:feature-key
}

See Fetching secrets from Vault for more information.

From Aerospike Secret Agent

In Database 6.4 and later, the server can use Aerospike Secret Agent to fetch from a secrets management service, such as AWS Secrets Manager.

The configuration parameter must follow the format secrets:[resource:]secret_name. The prefix secrets: is a literal string.

service {
  feature-key-file secrets:TestingSecret:FeatureKey
  ...
}

For more information, see Integrating with secrets management services.

Updating the contents or location of the feature-key file

If you get a new feature-key file and put it in the same location (so the file path remains identical) you do not need to update the feature-key-file configuration parameter. If the path changes, you must update the parameter with the new path whether or not the contents of the file change.

The server reads the feature-key file at startup. To refresh and read from the new file, perform a rolling restart of your cluster. Do not wait too long to restart the cluster after an update, because if a node restarts unexpectedly it could result in a prolonged feature mismatch between nodes.