@tsmx/secure-config

Easy and secure configuration management.

Manage JSON based configurations with encrypted secrets and optional HMAC validation to ensure data integrity.

Works with CommonJS and ESM/ECMAScript.

If you are upgrading from an older version prior to 2.x please read this important note.

Usage

1. Encrypt sensitive data in your JSON configuration file. Most easy way to do this is using the secure-config-tool. For more details please see generating an encrypted configuration and naming conventions.

   {
     "database": {
       "host": "127.0.0.1",
       "user": "ENCRYPTED|50ceed2f97223100fbdf842ecbd4541f|df9ed9002bfc956eb14b1d2f8d960a11",
       "pass": "ENCRYPTED|8fbf6ded36bcb15bd4734b3dc78f2890|7463b2ea8ed2c8d71272ac2e41761a35"
     }
   }

2. Use your configuration in the code.

   // CommonJS
   const conf = require('@tsmx/secure-config')();
   
   // ESM
   import secureConfig from '@tsmx/secure-config';
   const conf = secureConfig();
   
   function MyFunc() {
     let dbHost = conf.database.host; // = '127.0.0.1'
     let dbUser = conf.database.user; // = 'MySecretDbUser'
     let dbPass = conf.database.pass; // = 'MySecretDbPass'
     //...
   }

   For further customization and advanced features like HMAC validation you can pass an options object - please refer to the options section.

3. Run your app. See below for different options on how to pass the key.

   $ export CONFIG_ENCRYPTION_KEY=...
   $ node app.js

A fully working example project is also available on GitHub.

To get all information please also check out the full documentation.

Naming conventions

You can have multiple configuration files for different environments or stages. They are distinguished by the environment variable NODE_ENV. The basic configuration file name is config.json if this variable is not present. If it is present, a configuration file with the name config-[NODE_ENV].json is used. An exception will be thrown if no configuration file is found.

To change the default configuration file name or loading multiple configuration files you can pass the prefix option.

All configuration files must be located in a conf/ directory of the current running app, meaning a direct subdirectory of the current working directory (CWD/conf/).

Example structure

| Stage | Value of NODE_ENV | Filename | |-------------|-------------------|-----------------------------| | Development | not set | conf/config.json | | Production | production | conf/config-production.json | | Test | test | conf/config-test.json |

Resulting folders/files setup:

path-to-your-app/
├── conf/
│   ├── config.json
│   ├── config-production.json
│   └── config-test.json
├── app.js
└── package.json

Options

To retrieve a configuration using all default values and without advanced features, you simply invoke a function after the require/import statement without any argument (set of parenthesis after require or simple method call after import).

// CommonJS
const conf = require('@tsmx/secure-config')();

// ESM
import secureConfig from '@tsmx/secure-config';
const conf = secureConfig();

To make use of the more advanced features and customize default values, you can pass an options object to this function call.

const confOptions = {
  keyVariable: 'CUSTOM_CONFIG_KEY',
  hmacValidation: true, 
  hmacProperty: '_signature',
  prefix: 'myconf'
}

// CommonJS
const conf = require('@tsmx/secure-config')(confOptions);

// ESM
import secureConfig from '@tsmx/secure-config';
const conf = secureConfig(confOptions);

The following options are available.

keyVariable

Type: String Default: CONFIG_ENCRYPTION_KEY

The name of the environment variable containing the key for decrypting configuration values and validating the HMAC. See also options on how to pass the key.

hmacValidation

Type: Boolean Default: false

Specifies if the loaded configuration should be validated against a given HMAC. If set to true, secure-config will validate the HMAC of the decrypted configuration content against a given HMAC using the current key. If the validation fails, an exception will be thrown. If it succeeds, the decrypted configuration will be returned.

The given HMAC is retrieved from a configuration file property with the name of hmacProperty, e.g.:

{
  "database": {
    "host": "127.0.0.1",
    "user": "ENCRYPTED|50ceed2f97223100fbdf842ecbd4541f|df9ed9002bfc956eb14b1d2f8d960a11",
    "pass": "ENCRYPTED|8fbf6ded36bcb15bd4734b3dc78f2890|7463b2ea8ed2c8d71272ac2e41761a35"
  },
  "__hmac": "3023eb8cf76894c0d5c7f893819916d876f98f781f8944b77e87257ef77c1adf"
}

Enabling this option is recommended for production environments as it adds more security to your configuration management ensuring the loaded configuration is safe against tampering. Unwanted modifications of any - even unencrypted - entries in your configuration would cause the HMAC validation to fail and throw the error HMAC validation failed.

Please ensure that your stored configuration files have an appropriate HMAC property before enabling this option. Otherwise loading the configuration would always fail. secure-config-tool adds the HMAC by default when creating secured configuration files.

To get more information on how the HMAC creation & validation works under the hood, please refer to the package object-hmac which is used for that. The HMAC value is created out of the entire configuration object before optional encryption is applied.

hmacProperty

Type: String Default: __hmac

The name of the HMAC property in a configuration file to be validated against. Only used when hmacValidation is set tor true.

Example configuration file using a custom HMAC property name:

{
  "database": {
    "host": "127.0.0.1",
    "user": "ENCRYPTED|50ceed2f97223100fbdf842ecbd4541f|df9ed9002bfc956eb14b1d2f8d960a11",
    "pass": "ENCRYPTED|8fbf6ded36bcb15bd4734b3dc78f2890|7463b2ea8ed2c8d71272ac2e41761a35"
  },
  "_signature": "3023eb8cf76894c0d5c7f893819916d876f98f781f8944b77e87257ef77c1adf"
}

Loading the configuration with HMAC validation enabled:

const confOptions = {
    hmacValidation: true, 
    hmacProperty: '_signature'
}
const conf = require('@tsmx/secure-config')(confOptions);

prefix

Type: String Default: config

Use this parameter to change the default file name pattern from config-[NODE_ENV].json to [prefix]-[NODE_ENV].json for loading files with deviating names or additional ones. The value of NODE_ENV will be evaluated as described in the naming conventions.

To load multiple configurations, use the following pattern in your code.

const secureConf = require('@tsmx/secure-config');
const config = secureConf();
const myconf = secureConf({ prefix: 'myconf', keyVariable: 'MYCONF_KEY' });

This example will load the default config.json using the the key from environment variable CONFIG_ENCRYPTION_KEY as well as the additional myconf.json using the key from MYCONF_KEY. Note that different configurations should use different encryption keys.

Depending on the value of NODE_ENV the following configuration files will be loaded in this example.

| Value of NODE_ENV | variable | Filename | |-------------------|----------------------|------------------------------------------------------------| | not set | configmyconf | conf/config.jsonconf/myconf.json | | production | configmyconf | conf/config-production.jsonconf/myconf-production.json | | test | configmyconf | conf/config-test.jsonconf/myconfig-test.json |

Injecting the decryption key

The key for decrypting the encrypted values is derived from an environment variable. The default name of this variable is CONFIG_ENCRYPTION_KEY, but you can also pass any other name via options. You can set the environment variable whatever way is most suitable, e.g.

• set/export in the command line or in your bash pofile

  export CONFIG_ENCRYPTION_KEY=0123456789qwertzuiopasdfghjklyxc

• using an env block in your VS-Code launch configuration

  "env": {
    "CONFIG_ENCRYPTION_KEY": "0123456789qwertzuiopasdfghjklyxc"
  }

• using an env block in your deployment descriptor, e.g. app.yaml for Google App Engine

  env_variables:
    CONFIG_ENCRYPTION_KEY: "0123456789qwertzuiopasdfghjklyxc"

• for testing with Jest I recommend to create a test key and set it globally for all tests in the jest.config.js, e.g.

  process.env['CONFIG_ENCRYPTION_KEY'] = '0123456789qwertzuiopasdfghjklyxc';
  
  module.exports = {
      testEnvironment: 'node'
  };

• etc.

More examples are available in the full documentation.

The key length must be 32 bytes! The value set in CONFIG_ENCRYPTION_KEY has to be:

• a string of 32 characters length, or
• a hexadecimal value of 64 characters length (= 32 bytes)

Otherwise an error will be thrown.

Examples of valid key strings:

• 32 byte string: MySecretConfigurationKey-123$%&/
• 32 byte hex value: 9af7d400be4705147dc724db25bfd2513aa11d6013d7bf7bdb2bfe050593bd0f

Different keys for each configuration environment are strongly recommended.

Generating an encrypted configuration

Option 1: secure-config-tool

For better convenience I provided a very basic secure-config-tool to easily generate encrypted configuration files with an optional HMAC.

Option 2: NodeJS crypto functions

You can also simply use crypto functions from NodeJS with the following snippet to create the encrypted entries in a configuration file on your own:

const crypto = require('crypto');
const algorithm = 'aes-256-cbc';

function encrypt(value) {
  let iv = crypto.randomBytes(16);
  let key = Buffer.from('YOUR_KEY_HERE');
  let cipher = crypto.createCipheriv(algorithm, key, iv);
  let encrypted = cipher.update(value);
  encrypted = Buffer.concat([encrypted, cipher.final()]);
  return 'ENCRYPTED|' + iv.toString('hex') + '|' + encrypted.toString('hex');
}

Remarks

The generated encrypted entry must always have the form: ENCRYPTED | IV | DATA.

| Part | Description | |-------------|-------------| | ENCRYPTED | The prefix ENCRYPTED used to identify configuration values that must be decrypted. | | IV | The ciphers initialization vector (IV) that was used for encryption. Hexadecimal value. | | DATA | The AES-256-CBC encrypted value. Hexadecimal value. |

Upgrading from versions prior to 2.x

In versions before 2.x, secure-config directly exported the configuration object when requiring in the module. To add more flexibility and being able to provide new features, this was changed in the 2.x versions. The module now exports a function which can receive additional options.

Since there's a full backward compatibility, all you have to do in your existing code using version 1.x so far is to invoke the function by adding a set of parenthesis.

// version 1.x - requiring in without any function call
const conf = require('@tsmx/secure-config');

// version 2.x - change to that for retaining full backward compatibility
const conf = require('@tsmx/secure-config')();

// use conf as you did before...

Changelog

2.1.0

• Support for encrypted properties of objects in arrays added, e.g. { configArray: [ { key: 'ENCRYPTED|...' }, { key: 'ENCRYPTED|... ' } ] }

2.2.0

• Support for loading multiple configurations with new option prefix added.

Test

npm install
npm test