Recommendations for storing non-secrets as well

[AlexCline]

Love the Cryptex project! It solves a really tricky challenge in my organization for the protection of secrets.

Something that I've been mulling over recently is how best to store non-secrets along with secrets when using Cryptex. For example, while encrypting the database password is a no-brainer, encrypting the hostname may leads to confusion as to which host is being hit in which environment.

I've considered utilizing motdotla/dotenv and just using cryptex via environment variables, but this seems like a bit of a patchy/hacky solution that doesn't fully utilize Cryptex's environments.

Another alternative was to create a PR for Cryptex that would support a non-secrets object within an environment in cryptex.json which could be used as a non-encrypted configuration store. What are your thoughts about this option?

Can plaintext encoded 'secrets' be stored alongside KMS encrypted secrets in the same environment? The way I read the docs and code, this doesn't seem possible.

Currently we store secrets in environment variables segmented per-environment within the deployment infrastructure, but this leads to separate sources of truth - something I'd like to consolidate back in to the repo.

Do you have any suggestions for alternatives for storing non-secrets along with secrets in Cryptex?

[TomFrost]

Hi Alex! Thanks for the kind words :)

What you've described is a pretty common use case/concern. Generally it's solved in one of three ways:

1. Use an environment-aware CI/CD tool, or layer environment information on top of one that isn't. Wercker is but is shockingly expensive; Travis, Circle, and Codebuild aren't. My solution for the latter 3 is to set environment variables with a prefix like STAGING__DB_HOST or PRODUCTION__DB_HOST, then have a bootstrap script detect the appropriate environment, loop through all env vars, and un-prefix the appropriate ones. Now, you can store general config right alongside your cryptex secrets.

2. Use dotenv's environments feature to achieve the same as the above. You'll have files like .env.staging and .env.production instead of a single .env.

3. Just keep them separate. It seems counterintuitive, but when working on a team, it can be useful to have two distinct locations for public data and private data, where 100% of the private data is encrypted. It may feel dirty to break the source of truth into two pieces, but it does a great job of making it extraordinarily obvious when someone tries to add an unencrypted secret.

I've personally done both #1 and #3, and I've heard of folks having successful workflows with #2. Your PR suggestion is interesting, but I think I'd like for Cryptex to stay just about encryption/decryption concerns and keep it focused on that one thing that it does best. There are some fantastic full-featured libraries out there for environment-specific config and that's a big rabbit-hole to go down to start adding that into Cryptex as well. Perhaps a great opportunity, though, would be to integrate Cryptex into something like Loren West's popular node-config library, or write another module that sits on top of Cryptex to make great secret-optional config management its focus.

Let me know where you land with this -- and let me know if I can be of more help!

[AlexCline]

Thanks for the feedback Tom. Sounds like we're gonna go back to the drawing board to figure out what might be the best solution for us.