I\'m pretty new to rails, but I have some experience programming in PHP and other languages. I really like rails, and I\'m working on an application for my company, but I still
All very good questions. Although there is probably no serious harm in not securing development and test secrets, it is good practice to do so. There is no upside in revealing information which could potentially make it easier for a bad actor to access your application code or data.
As of Rails 4.1, config/secrets.yml
can be used to manage all of your application secrets. This is described in the Rails 4.1 release notes. If you manage your secrets in this file, you should definitely include the file in .gitignore
so that your secrets do not show up in your code repository, even if it is currently private. You never know if you will want to open source your code in the future or share your private repository with another collaborator. As you probably know, once you put a file in git, it can be an involved process to remove all traces of it. Alternatively, you could maintain a secrets.yml template in git so that you have source control of the format of your secrets file, but keep the actual secrets in a separate file.
How you manage your secrets in production depends on your deployment platform. If you deploy to your own server, you just need to make sure that you have a mechanism to separately maintain deployment of secrets.yml
, since it will not be available in your git repository. You should be able to manage this through your deployment process using a tool like Capistrano
or Mina
. If you deploy to Heroku, you need to set config variables either through the Heroku CLI or the Heroku dashboard as described in the documentation.
Hope this helps.
Here's a (hopefully simple) step by step guide FOR HEROKU that should be performed prior to pushing files (secrets.yml) to GitHub, or another host.
*I am not an expert on this topic but this worked well for me and seems like a good solution. It combines info from answers to this question as well as answers to this question (Step by Step explanation for using Rails secrets.yml without exposing keys to public repo when deploying to Heroku) to provide a simple guide :)
1) Copy secrets.yml to another file named secrets_backup.yml
you should now have two files with the same content as secrets.yml
2) Add secrets_backup.yml
to your .gitignore
3) Change the text in secrets.yml
to the following
development:
secret_key_base: <%= ENV["SECRET_KEY_BASE_DEV"] %>
test:
secret_key_base: <%= ENV["SECRET_KEY_BASE_TEST"] %>
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
4) cd
to your rails project folder on the command line
5) In the terminal type heroku config:set SECRET_KEY_BASE_TEST=<pasted key>
,
where <pasted key>
should be copied and pasted from the test: secret_key_base:<key>
which is in secrets_backup.yml
6) In the terminal type heroku config:set SECRET_KEY_BASE_DEV=<pasted key>
,
where <pasted key>
should be copied and pasted from the development: secret_key_base:<key>
which is in secrets_backup.yml
7) My secrets.yml
file already had the SECRET_KEY_BASE instead of the actual key, so I suspect yours will too. But if not, set the SECRET_KEY_BASE variable as the other two were set above.
8) Push your repo to GitHub and Heroku
9) Smile because you're the G.O.A.T and show off your sweet website!
As far as I can tell Rails hasn't solved this one yet (as of Rails 4.2).
Here's a great summary of the mess situation
From Rails 4.1 there's a secrets.yml
file that is for all your secrets, but it's not in .gitignore
by default. People tell you to put it into .gitignore
but that doesn't help Heroku users get it to production. There's a gem that can help with that. If you do that then you might as well just use the Figaro gem that does all that in a neater way.
From the default contents of the secrets.yml
file it looks like the Rails developers intended for it to be included in source code repositories, but for any real secrets you're supposed to use environment variables and import those into the secrets file, which almost defeats the purpose.
If you want to use environment variables to hold the secrets, that means the underlying OS is storing them for you and when you need to use them you ask the OS what the variable is, that way it's not in your code at all. The command for setting the environment variables on Heroku looks like this:
heroku config:set YOUR_SECRET_VAR_NAME=your_secret
There are disadvantages to doing it this way. If you have a lot of secrets things will get messy fast, and it'll be hard to get it set up on a new machine.
the dotenv gem solves these problems letting you do environment variables without all the downsides of them. I recommend you use dotenv in conjunction with secrets.yml
without putting sectrets.yml
in the .gitignore
and manually set environment variable on Heroku.
Rails 5.2 has finally solved this by encrypting all your secrets within then Rails app and the you only need to store one key in the environment variable.
First off, I always add all .yml
files to my .gitignore
file, like this:
*.yml
This serves to keep any configuration files off of git. However, I also create "distribution files" to keep on git. Basically, clone somefile.yml
to somefile.yml.dist
and remove the actual values, but keep the structure/keys intact, so anyone else using your code can "fill in the blanks" themselves.
Keeping your development/test secrets secret isn't that important, as long as they differ from your production secrets. Some secrets (like if you are using Cloudinary) are the same for all environments, so you don't want to share those.