-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encrypted runtime config #10
Comments
Ok, I think I have something. Looking into how Plug works and found this article http://rrrene.org/2018/04/09/flow-elixir-metaprogramming/ on using metaprogramming for flow. |
Thanks for the research here! I don't have much time these days to chase this down but I'll gladly accept a PR or any notes toward getting this implemented 👍 |
I think I have something. Will write specs for it soon and get a PR out to you if you think this DSL makes sense? The config looks like this (can change the name of the module too, not sure if defmodule MyApp.EncryptedConfig do
use EncryptedSecrets.RuntimeConfig
config :flashcards, MyApp.Mailer, api_key: :mailer_api_key
end where :mailer_api_key is the yaml key. mailer_api_key: 'my_api_key'
some_other_key: 'testing' Or you can pass in nested keys by using a list config :flashcards, MyApp.Mailer, api_key: [:mailer_provider, :api_key] mailer_provider:
api_key: 'my_api_key' |
I like that DSL! What you've got makes sense to me so far. As an aside, I've been thinking about what approach is the most flexible while being the least likely to leak secret data. I'm wondering about an approach similar to dotenv but with encrypted secrets. Loading these secrets into env pre-compilation should work for normal Elixir apps as well as Distillery releases, but I'd have to look deeper into security implications (secrets in build artifacts as well as leaking ENV globally). |
Any updates on this? I'd love to use in my project; this is the blocker currently. |
Sorry I haven't completed this and sadly don't have time to continue. I'm not using elixir anymore for the time being and have been very busy with other projects. |
Now that I have more experience with releases I think that this library's approach is totally incompatible with releases (or Distillery, for that matter). I'm thinking that instead of trying to fight against the current, perhaps this project could change direction and encrypt your |
Do believe this concern applies here, I am using
Why would providing / decrypting them in |
It seems that loading the secrets in config/runtime.exs solves this issue. Can anybody confirm that? |
I've been scratching my head with a problem which your post on elixirforum helped me squash. https://elixirforum.com/t/loading-custom-module-in-config-exs/23232
The problem being how to use the encrypted secrets inside a config file.
I am a long time ruby developer so this also seemed intuitive to me and was what I was looking for a solution to! Surprisingly hard to google, only found that thread after reading 10s of posts on compilation.
Anyway, based on the fact that it's not a good idea to decrypt these secrets during compilation as they'll be in the build unencrypted... maybe another solution is to create a runtime config module that behaves in a similar way but is called during startup. Similar to how you've proposed in the thread.
Then in Application#start/2 call this file
Just thinking out loud. For now I'm probably just going to build a module to do this for myself but while it was fresh thought it was worth writing down. The readme could also do with updating on how people actually get these credentials into the app and the limitations e.g. dependencies that require compiled configs rather than runtime
The text was updated successfully, but these errors were encountered: