Allow private key to be passed in as a CLI option or an environment variable

[stevehodgkiss]

After fetching the private key from S3 we need to write it to disk so that ejson can use it to decrypt. It would be better if we could avoid writing it to disk and pass the key directly into ejson via an environment variable or option. Use cases:

• Docker containers. The private key is fetched from secure storage on container start then ejson is executed with the privatekey option to obtain the decrypted secrets.
• Heroku. The private key is provided via EJSON_PRIVATE_KEY then ejson is executed to obtain the decrypted secrets.

Addresses #23

[burke]

Thanks for diving in! Bad news though -- It was a very specific choice that ejson shouldn't allow reading secrets from environment variables -- it encourages key storage practices that leak secrets to child and other processes. (e.g. 1, 2).

For some context, the way we use ejson with docker is roughly:

• symlink the key into a temporary directory on the host;
• start the container with CAP_SYS_ADMIN and the key volume mounted at /opt/ejson/keys
• in the container:
  • decrypt any secrets;
  • umount the key volume;
  • drop the CAP_SYS_ADMIN capability;
  • spawn the application.

I realize that not supporting environment variables does make things more difficult on platforms like heroku. My intention was to make it more difficult to unintentionally implement bad key management, and I think environment variables make it far too easy to ignore the problem.

TL;DR: sorry, but it's awkward because of decisions.

[stevehodgkiss]

I agree; automatically reading from an environment variable would make it easy to store the secret in the application's environment and that would bring with it all the issues pointed out in those articles. That’s not the way we intend to use this - we’re not planning to store the EJSON private key in the environment of an application.

Our current docker usage pattern is similar (we use AWS ECS):

• Fetch the private key from S3 (encrypted with a KMS key)
• Mount the key to /opt/ejson/keys in the container (through task definitions)
• Invoke EJSON to obtain decrypted secrets

What we'd like to move to, is:

• On container start, fetch the private key from S3 or ParameterStore (encrypted with a KMS key)
• Invoke EJSON to obtain decrypted secrets

In this scenario, we don't need to store the private key on the filesystem at any point, and the host doesn't have access to the key (The IAM policy to allow access is associated with the ECS task's IAM Role, not the cluster's IAM Role like before).

We can implement a version of the second scenario with how EJSON currently works by writing the private key to disk but we'd rather avoid that if possible.

What do you think about allowing an option for the private key (and removing the environment variable support)?

[burke]

Yeah, I'd be open to passing a private key by command line parameter or stdin.