Separate secret_key_base in Rails 5.2?

Question

I just upgraded from 5.1 to 5.2 and I'm quite confused about this 'better' methodology to storing secrets...

Maybe I'm not understanding, but it seems like now development and production have been 'merged' into a SINGLE SECRET_KEY_BASE as well as master.key... is this correct?

If not, how do I use a separate master key and SECRET_KEY_BASE in development?

What if I have developers helping me and I don't want them to know my master key (or secrets) I use in production?

Wivinah

You can (and should) be providing the SECRET_KEY_BASE via a ENV var so that its never checked into the source code. In development you can use whatever SECRET_KEY_BASE you want - its simply used to sign cookies and for stuff like the salt in Devise. – Kelda

How do I do that if it removed the production and development breakdown so I can specify them separately? – Wivinah

I have not actually tried 5.2 but previously you could use ERB syntax in the secrets files <%= ENV.fetch("SECRET_BASE_KEY") %>. You can use direnv or dotenv to make setting the env vars less of a hassle. If you are using docker you can set ENV vars via the container. – Kelda

I'm using heroku. But I can't use ENV.fetch because theres no place to put it anymore (there used to be multiple SECRET_KEY_BASE for each environment). Now its all been combined into one. – Wivinah

It seems this is what I'm supposed to do... is patch it now to get this functionality back? This seems so stupid, and theres no instructions anywhere how to work with this driftingruby.com/episodes/encrypted-credentials-in-rails-5-2 – Wivinah

If you are using ENV vars you don't need to have "separate fields" - just set the production key in the heroku dashboard and something else on the local machine where you are developing. Thats the whole point. devcenter.heroku.com/articles/config-vars – Kelda

So lets say I have a development S3 bucket, and a production S3 bucket... where do my different keys go? – Wivinah

Let us continue this discussion in chat. – Kelda

I was actually completely wrong. The Rails 5.2+ secrets handling works with an encrypted secrets file with RAILS_MASTER_KEY containing the encryption key. Which makes it directly at odds with a ENV based configuration. I'm still not convinced thats its a better approach due to the reasons listed on 12factor.net/config – Kelda

Answer 1

Rails 5.2 changed this quite a bit. For development and test enivoronments, the secret_key_base is generated automatically, so you can just remove it from secrets.yml or wherever you have it set.

As for production, there is the credentials file which you can generate and edit it by running rails credentials:edit. This will also create the master key in config/master.key which is only used for encrypting and decrypting this file. Add this to gitignore so it's not shared with anyone else, which should take care of sharing it with fellow devs.

If all of this sounds a bit tedious, and it is, you can just ignore it and provide the secret_key_base in ENV. Rails will check if it's present in ENV["SECRET_KEY_BASE"] before it complains.

Toodleoo

Thanks. Where do development keys go now? It's seems theres a lot of people here who don't like this change, and theres no good places to put them anymore... github.com/rails/rails/pull/30067 – Wivinah

Yeah, I don't like this change at all. You can still use secrets, they are still working the same as before. – Toodleoo

By secrets, I mean secrets.yml. It's still accessible via Rails.application.secrets – Toodleoo

FWIW, mostly for future me, the secret_key_base is available on object Rails.application.secret_key_base which will pull it from multiple sources, including the auto generated one in development and test. github.com/rails/rails/pull/30067/… – Odoric

Answer 2

There are two ways to access secret_key_base:

1. Rails.application.credentials.secret_key_base
2. Rails.application.secrets.secret_key_base

Rails 5 took the first way by default.

you can change Rails.application.credentials.secret_key_base by rails credentials:edit. for all other environments, remember to set environment variable RAILS_MASTER_KEY to be the same content of config/master.key. the master.key is git ignored by default. this way uses the same secret key for all environments. if you want to use different keys, you need to control namespaces by yourself.

If you prefer the second way Rails.application.secrets.secret_key_base. you need to create config/secrets.yml:

development:
  secret_key_base: ...
test:
  secret_key_base: ...
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

remember to set environment variable SECRET_KEY_BASE on production. if config/secrets.yml file is secret enough, changing <%= ENV["SECRET_KEY_BASE"] %> to plain text is fine.

rake secret can generate a random secret key for you.

I prefer the second way(old way), because of simple.

Teillo

call it through Rails.application.secret_key_base and it will grab the proper one github.com/rails/rails/pull/30067/… – Odoric

how I put the result of rake secret into ENV["SECRET_KEY_BASE"] ? – Celandine

Login as user and type terminal this 'ECRET_KEY_BASE=xxxx' 'export SECRET_KEY_BASE' – Stopped

Answer 3

I used this gem when I didn't want to share the production master.key with my friend developers which I think is the exact same purpose as the OP.

https://github.com/sinsoku/rails-env-credentials

You can have a master key for each evironment as below, so you can have a discretion as to which key you want to share with which developers/deployers.

config/credentials-development.yml.enc
config/credentials-test.yml.enc
config/credentials.yml.enc
master-development.key
master-test.key
master.key

Each key will be generated when you first run something like:

rails env_credentials:edit -e development

If you switch from one master.key setup to this, one error you might encounter will be related to config/database.yml in which Rails tries to evaluate all environment information no matter which environment you are on. (Even if you comment them out, Rails still tries to evaluate the erb parts.)

Vain

@Filnor Updated the answer. – Vain

@Pcriulan Updated. (It kinda sucks I cannot notify 2 users at the same time with one comment...) – Vain