1

Rails 4.1.0 introduced a new secrets.yml file. This is what I find myself doing right now: generally for the production environment, I use environment variables and inject them into the file like this:

production:
  secret_key_base: ENV['SECRETS_KEY_BASE']

(I use Heroku, so I use environment variables for configuration rather than secrets.yml, since you can't just upload arbitrary files to a Heroku server.)

For development and test environments, though, I find myself saying, whatever; and I just include the "secrets" in the repo. I figure it doesn't really matter if these values are exposed when I'm just doing local development.

I also put things such as OAuth keys/secrets in here. With Google, for example, I register an application with two clients from the developer console, one for production (with the URL set to my actual domain) and one for dev/test (with localhost:3000 or whatever). And again, I'm inclined to just include the client secret in the repo for dev, but put it in an environment variable and inject it for production.

Is this a sane approach? Are there risks I'm not thinking of from exposing development/test credentials like this?

Dan Tao
  • 125,917
  • 54
  • 300
  • 447

1 Answers1

0

If you have to ask...

Security breaches happen when a single, common, important password gets compromised, allowing attackers to get into treasure troves of secrets.

Treat your secrets file the way everyone treats database.yml - that's well-documented as a way to keep your database password (if any;) out of git...

Phlip
  • 5,253
  • 5
  • 32
  • 48
  • 1
    So you believe it's a bad idea to include dev/test "secrets" because it opens up the possibility you might let a real production secret slip through by mistake? – Dan Tao Jan 15 '14 at 21:14
  • the rationale for not checking in database.yml is so your colleagues can develop on their own workstations, with their own databases, without knowing the real server's secret password. So your secrets.yml is the same. (BTW, if you are already compromised, you can command your provider to retire your secret keys & generate new ones...) – Phlip Jan 15 '14 at 21:38