Allow the config decryption key to be retrieved by a user-provided function

[seanpk]

Currently the config service supports 3 ways to provide a decryption key:

1. in the config itself at security.key (don't abuse this by checking that into your source control! - have a deployment script write a file config/security.json with the key in it)
2. in the environment variable decryptionKey
3. interactively on the command line

Writing a file to disk, or setting an environment variable with the decryption key, leaves that key available to several exploits to use.

Let's add support for retrieving the key from a callback function the developer can write to get the key from whatever secure storage they choose to implement.

Also, then, since in clustered mode the decryption key is passed to each worker as an environment variable, we should look at alternatives, for all cases, to that method.
Further, since the decryption key is exported from the config service (and kept in memory), we should look for an alternative to that too. (NOTE: even though this will change the exports of the config service, it is not a documented export and should not be considered a breaking change.)

[seanpk]

@dannylevenson - what do you think?
@adamrbennett & @jwsm?

[adamrbennett]

This definitely sounds better than storing or passing the key everywhere it is needed. The key could potentially be retrieved from secure storage (i.e.: SSM) in the callback, which I'm sure you have in mind.

That leads me to wonder, why not retrieve the secrets themselves from secure storage? It's appealing to store secrets all in one place and use policies to govern access. I guess I'm feeling like secrets are maybe outside the scope of BlueOak. In any case, it's already a feature, so it makes sense to introduce a more secure way to use it.

I don't fully understand everything at work here, like the clustering process, so I might be way off base :)

[seanpk]

@adamrbennett - yes, there are definitely other options for handling secrets.
For BOS applications, the config service is the common way for controlling the behavior of services and middleware, especially those that may be installed via npm. For example, a database service can learn which databases to connect to, with what credentials, by looking for those details at a known config location.
Developers can definite take different approaches, but the designed approach for BOS apps is to use the config, and so we can improve the security of that design.

Regarding clustering, it currently happens by setting an environment variable and forking (cluster.fork) the running process. I'm thinking to do the fork, but have each process look up the key itself. This duplicates the work of getting the key and decrypting the secrets in the config, but keeps the secret in the running processes, only when they need them to decrypt.