How do you manage secret keys and heroku with Ruby on Rails 4.1.0beta1?

Question

With the release of the secrets.yml file, I removed my reliance on Figaro and moved all of my keys to secrets.yml and added that file to .gitignore.

But when I tried to push to Heroku, Heroku said they needed that file in my repo in order to deploy the website. which makes sense, but I don't want my keys in git if I can avoid it.

With Figaro, I would run a rake task to deploy the keys to heroku as env variables and keep application.yml in the .gitignore. Obviously, I can't do that any more. So how do I handle this?

Answer 1

Secrets isn't a full solution to the environment variables problem and it's not a direct replacement for something like Figaro. Think of Secrets as an extra interface you're now supposed to use between your app and the broader world of environment variables. That's why you're now supposed to call variables by using Rails.application.secrets.your_variable instead of ENV["your_variable"].

The secrets.yml file itself is that interface and it's not meant to contain actual secrets (it's not well named). You can see this because, even in the examples from the documentation, Secrets imports environment variables for any sensitive values (e.g. the SECRET_KEY_BASE value) and it's automatically checked into source control.

So rather than trying to hack Secrets into some sort of full-flow environment variable management solution, go with the flow:

1. Pull anything sensitive out of secrets.yml.
2. Check secrets.yml into source control like they default you to.
3. For all sensitive values, import them from normal environment variables into secrets ERB (e.g. some_var: <%= ENV["some_var"] %>)
4. Manage those ENV vars as you normally would, for instance using the Figaro gem.
5. Send the ENV vars up to Heroku as you normally would, for instance using the Figaro gem's rake task.

The point is, it doesn't matter how you manage your ENV vars -- whether it's manually, using Figaro, a .env file, whatever... secrets.yml is just an interface that translates these ENV vars into your Rails app.

Though it adds an extra step of abstraction and some additional work, there are advantages to using this interface approach.

Whether you believe it's conceptually a good idea or not to use Secrets, it'll save you a LOT of headache to just go with the flow on this one.

PS. If you do choose to hack it, be careful with the heroku_secrets gem. As of this writing, it runs as a before_initialize in the startup sequence so your ENV vars will NOT be available to any config files in your config/environments/ directory (which is where you commonly would put them for things like Amazon S3 keys).

Answer 2

An equivalent for secrets.yml of that Figaro task is provided by the heroku_secrets gem, from https://github.com/alexpeattie/heroku_secrets:

gem 'heroku_secrets', github: 'alexpeattie/heroku_secrets'

This lets you run

rake heroku:secrets RAILS_ENV=production

to make the contents of secrets.yml available to heroku as environment variables.