Adding support for .yml and .encoded.yml to allow for encrypted and un-encrypted credential files

[crimson-knight]

I'd like to take point on this, and I'm creating this issue to outline my plans going forward.

I want to add:

• Support for a yml file to be used for credentials, allowing credentials to be separated by environment in a single place
• Support for a yml file that is base64 encoded from a master.key file similar to what Rails does with the rails credentials:edit. This would make deployments radically easier if you only need to put the master.key as an ENV variable that unlocks all of your credentials.
• Continue support of using a .env file so that it's fully compatible with anyone already using it.

I've already forked the repo and begun working on splitting the file types up. First iteration through will support the yml file to keep it simple, then I'll add the necessary methods for generating a master.key file and using that to encode the yml file.

I think the best approach is to read through the .encoded.yml file, and Base64 encode each line using the master.key. That way it's still a yml file but the data is useless without the key. That could be wrong, but it's a starting point and I'm really dying for a feature like this because I love how simple my Rails 6+ deployments are using this approach.

I've forked the repo and begun working on this. I'll put up PR's as I make progress.

[jwoertink]

That's awesome you want to tackle this! I think it would be huge to add this in.

Just a few things though before you get too deep in to it.

1. We already have a built-in way of encrypting things https://github.com/luckyframework/lucky/tree/master/src/lucky/support. I don't know if it's the best way, but if possible, I think we should try to utilize what we have and avoid re-rolling new stuff (if we can..)
2. Granted, Rails has a pretty nice system with the yml file setup; however, I always found myself split between using .env and the encrypted creds. Rails added in ERB parsing allowing you to set the value to an ENV in those, which for me, made things too messy and error prone. I think we can do better.
3. We need to make sure we tackle this from a Lucky perspective. Which means, in development, your app should not boot if critical pieces are missing (e.g. no key file). It should be type-safe where possible (see my notes in Not just another .env parser #1)

My thought was, what if we turned the .env file itself in to some encrypted file? I'm imagining a system where it reads and decrypts the file at compile-time, then shoves the data in to class level settings. Then it's not having to decrypt at runtime, and this allows us to do checking similar to how Habitat does it by tanking the compiler if required settings are missing (or blank, etc...)