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

Add support for multi environment credentials. #33521

Merged
merged 1 commit into from Sep 19, 2018

Conversation

Projects
None yet
@morgoth
Member

morgoth commented Aug 2, 2018

Usage:

If one wants to use staging encrypted credentials:

rails credentials:edit --environment staging

This will create files config/credentials/staging.yml.enc and config/credentials/staging.key
When calling Rails.application.credentials in staging environment, it takes precedence over default
config/credentials.yml.enc
Default paths can be overwritten by setting config.credentials.content_path and config.credentials.key_path

It is backward compatible.

Another try for #30067 (comment)

@rails-bot

This comment has been minimized.

Show comment
Hide comment
@rails-bot

rails-bot Aug 2, 2018

r? @schneems

(@rails-bot has picked a reviewer for you, use r? to override)

rails-bot commented Aug 2, 2018

r? @schneems

(@rails-bot has picked a reviewer for you, use r? to override)

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth
Member

morgoth commented Aug 2, 2018

r? @kaspth

@rails-bot rails-bot assigned kaspth and unassigned schneems Aug 2, 2018

@sidot3291

This comment has been minimized.

Show comment
Hide comment
@sidot3291

sidot3291 Aug 2, 2018

How do you handle editing different credential files? (What key do you use to decrypt, where do you put the different keys for the different files)

sidot3291 commented Aug 2, 2018

How do you handle editing different credential files? (What key do you use to decrypt, where do you put the different keys for the different files)

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Aug 2, 2018

Member

@sidot3291 editing is already possible:
bin/rails encrypted:edit config/your-enctyped-file.yml.enc --key config/your-master.key

To decrypt on staging there is always config/master.key or RAILS_MASTER_KEY but it should be fine - on staging/production you don't need to decrypt 2 files, so you can set appropriate master key for given env

Member

morgoth commented Aug 2, 2018

@sidot3291 editing is already possible:
bin/rails encrypted:edit config/your-enctyped-file.yml.enc --key config/your-master.key

To decrypt on staging there is always config/master.key or RAILS_MASTER_KEY but it should be fine - on staging/production you don't need to decrypt 2 files, so you can set appropriate master key for given env

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Aug 12, 2018

Member

Let's figure out a sensible file structure, so users don't have to muck with config.credentials_file. It'll simply use the env appropriate file or fall back on credentials.yml.enc.

For starters, let's try it out with config/environments/development/credentials.yml.enc and config/environments/development/master.key. Then credentials:edit needs to support a --environment option.

Then the global credentials file + master key is still geared towards production (and staging could use that as well) and the majority use case. But people could even do credentials:edit --production if they'd want it split.

There's more things to decide, but I think that makes the flow easy to understand and gives us an avenue to explore further.

Member

kaspth commented Aug 12, 2018

Let's figure out a sensible file structure, so users don't have to muck with config.credentials_file. It'll simply use the env appropriate file or fall back on credentials.yml.enc.

For starters, let's try it out with config/environments/development/credentials.yml.enc and config/environments/development/master.key. Then credentials:edit needs to support a --environment option.

Then the global credentials file + master key is still geared towards production (and staging could use that as well) and the majority use case. But people could even do credentials:edit --production if they'd want it split.

There's more things to decide, but I think that makes the flow easy to understand and gives us an avenue to explore further.

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Aug 12, 2018

Member

@kaspth thanks for feedback.
What if one wants to use development/test credentials without encryption? Is it fine to look for config/environments/development/credentials.yml.enc first and if not found, fallback to config/environments/development/credentials.yml? I know that it somehow defeats the original idea, but many mention it as a pain point.

Also this way I guess it won't be possible to share it between development/test (which usually are almost the same)

Also I think it will make a trouble for heroku-like flow, when staging/qa apps are using production environment, so it wouldn't be possible to specify separate encrypted credentials file for them - https://devcenter.heroku.com/articles/multiple-environments

Member

morgoth commented Aug 12, 2018

@kaspth thanks for feedback.
What if one wants to use development/test credentials without encryption? Is it fine to look for config/environments/development/credentials.yml.enc first and if not found, fallback to config/environments/development/credentials.yml? I know that it somehow defeats the original idea, but many mention it as a pain point.

Also this way I guess it won't be possible to share it between development/test (which usually are almost the same)

Also I think it will make a trouble for heroku-like flow, when staging/qa apps are using production environment, so it wouldn't be possible to specify separate encrypted credentials file for them - https://devcenter.heroku.com/articles/multiple-environments

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Aug 12, 2018

Member

What if one wants to use development/test credentials without encryption?

Credentials should always be encrypted. They'll have to merge the unencrypted ones in in some other way.

Also this way I guess it won't be possible to share it between development/test (which usually are almost the same)

For now my stance is: too bad. I really don't care much for the development.credentials.yml.enc constructs or some such. That or my config.credentials.content_path suggestion in the main thread.

Also I think it will make a trouble for heroku-like flow, when staging/qa apps are using production environment, so it wouldn't be possible to specify separate encrypted credentials file for them - https://devcenter.heroku.com/articles/multiple-environments

What's the Heroku flow for the 5.2 credentials? Why do they need separate files? Isn't the point that staging uses production credentials? Sounds like a case for config.credentials.content_path.

Member

kaspth commented Aug 12, 2018

What if one wants to use development/test credentials without encryption?

Credentials should always be encrypted. They'll have to merge the unencrypted ones in in some other way.

Also this way I guess it won't be possible to share it between development/test (which usually are almost the same)

For now my stance is: too bad. I really don't care much for the development.credentials.yml.enc constructs or some such. That or my config.credentials.content_path suggestion in the main thread.

Also I think it will make a trouble for heroku-like flow, when staging/qa apps are using production environment, so it wouldn't be possible to specify separate encrypted credentials file for them - https://devcenter.heroku.com/articles/multiple-environments

What's the Heroku flow for the 5.2 credentials? Why do they need separate files? Isn't the point that staging uses production credentials? Sounds like a case for config.credentials.content_path.

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Aug 12, 2018

Member

I think having config.credentials.content_path would solve many complains.

What about:

When calling Rails.application.credentials

  1. take a file from config.credentials.content_path if set
  2. if not set, fallback to config/credentials.yml.enc
  3. for new apps (Rails 6.0?) generate a line in config/environments/production.rb: config.credentials.content_path = "config/environments/production/credentials.yml.enc

or

  1. take a file from config.credentials.content_path always
  2. by default set it to config/credentials.yml.enc (so it's compatible with current apps)
  3. do not expose config.credentials.content_path in newly generated apps, but allow to set it (for people that need it)
  4. Eventually deprecate (in Rails 6.0) old location of config/credentials.yml.enc and by default generate file in config/environments/production/credentials.yml.enc, to even more emphasize it's a production thingy and not a general tool for all envs.

If one would really need to use development/test credentials (which cannot be unencrypted) then can set path by hand (eventually config.credentials.key_path could also be exposed). But I don't think that using encrypted development/test files make much sense overall.

When calling bin/rails credentials:edit --environment staging:

  1. just look in the folder config/environments/staging/ for credentails.yml.enc and master.key (this obviously cannot take config.credentials.content_path)

For a heroku-like flow it would be a little weird as there would be config/environments/staging folder, but no config/environments/staging.rb. However it would work at least.

There is a still gotcha what to do for development/test, but maybe exploring usage of Rails.application.config_for(:feature) could be an option? Like:

# config/s3.yml
production:
  access_key_id: <%= Rails.application.credentials.s3_access_key_id %>
staging:
  access_key_id: <%= Rails.application.credentials.s3_access_key_id %>
development:
  access_key_id: "dev-key"

and then calling Rails.application.config_for(:s3)["access_key_id"] in the app code. This still is not that nice in syntax and config_for doesn't cache read file.
Anyway that could be discussed separately - just a random thought :)

Member

morgoth commented Aug 12, 2018

I think having config.credentials.content_path would solve many complains.

What about:

When calling Rails.application.credentials

  1. take a file from config.credentials.content_path if set
  2. if not set, fallback to config/credentials.yml.enc
  3. for new apps (Rails 6.0?) generate a line in config/environments/production.rb: config.credentials.content_path = "config/environments/production/credentials.yml.enc

or

  1. take a file from config.credentials.content_path always
  2. by default set it to config/credentials.yml.enc (so it's compatible with current apps)
  3. do not expose config.credentials.content_path in newly generated apps, but allow to set it (for people that need it)
  4. Eventually deprecate (in Rails 6.0) old location of config/credentials.yml.enc and by default generate file in config/environments/production/credentials.yml.enc, to even more emphasize it's a production thingy and not a general tool for all envs.

If one would really need to use development/test credentials (which cannot be unencrypted) then can set path by hand (eventually config.credentials.key_path could also be exposed). But I don't think that using encrypted development/test files make much sense overall.

When calling bin/rails credentials:edit --environment staging:

  1. just look in the folder config/environments/staging/ for credentails.yml.enc and master.key (this obviously cannot take config.credentials.content_path)

For a heroku-like flow it would be a little weird as there would be config/environments/staging folder, but no config/environments/staging.rb. However it would work at least.

There is a still gotcha what to do for development/test, but maybe exploring usage of Rails.application.config_for(:feature) could be an option? Like:

# config/s3.yml
production:
  access_key_id: <%= Rails.application.credentials.s3_access_key_id %>
staging:
  access_key_id: <%= Rails.application.credentials.s3_access_key_id %>
development:
  access_key_id: "dev-key"

and then calling Rails.application.config_for(:s3)["access_key_id"] in the app code. This still is not that nice in syntax and config_for doesn't cache read file.
Anyway that could be discussed separately - just a random thought :)

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Aug 13, 2018

Member

Here's what I'd like to see. By default, everything stays as it is, but we provide the following path to allow an environment-specific credentials file. It's automatically configured and loaded if the file config/credentials/$environment.yml.enc is available. The key used to decrypt will be either config/credentials/$environment.key or ENV["RAILS_#{Rails.env.upcase}_KEY"].

There's no merging. If you're in the development environment, and config/credentials/development.yml.enc is found, then that'll be loaded. We won't even try to do anything with config/credentials.yml.enc. We won't try to merge some intersection of both files either. These are separate files and separate stores of credentials.

No interest in doing anything with unencrypted credentials for this feature. The word "credentials" should mean "encrypted".

This approach will require no configuration. All we'd need is a way to specify an environment when using the credential commands.

Beyond this, I see any other use of encrypted configuration as an exercise for the developer. We have the primitives for saving and loading encrypted files. That should be enough.

Member

dhh commented Aug 13, 2018

Here's what I'd like to see. By default, everything stays as it is, but we provide the following path to allow an environment-specific credentials file. It's automatically configured and loaded if the file config/credentials/$environment.yml.enc is available. The key used to decrypt will be either config/credentials/$environment.key or ENV["RAILS_#{Rails.env.upcase}_KEY"].

There's no merging. If you're in the development environment, and config/credentials/development.yml.enc is found, then that'll be loaded. We won't even try to do anything with config/credentials.yml.enc. We won't try to merge some intersection of both files either. These are separate files and separate stores of credentials.

No interest in doing anything with unencrypted credentials for this feature. The word "credentials" should mean "encrypted".

This approach will require no configuration. All we'd need is a way to specify an environment when using the credential commands.

Beyond this, I see any other use of encrypted configuration as an exercise for the developer. We have the primitives for saving and loading encrypted files. That should be enough.

@prashantham

This comment has been minimized.

Show comment
Hide comment
@prashantham

prashantham Aug 13, 2018

Would the above work if environment is production, but the enc file is a staging one? Staging would usually run in production mode.

prashantham commented Aug 13, 2018

Would the above work if environment is production, but the enc file is a staging one? Staging would usually run in production mode.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Aug 13, 2018

Member
Member

dhh commented Aug 13, 2018

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Aug 13, 2018

Member

OK, I can start with this, it's already some improvement.
@schneems maybe you could share your experience with this feature on Heroku. Are people using encrypted credentials?

Member

morgoth commented Aug 13, 2018

OK, I can start with this, it's already some improvement.
@schneems maybe you could share your experience with this feature on Heroku. Are people using encrypted credentials?

@mladenilic

This comment has been minimized.

Show comment
Hide comment
@mladenilic

mladenilic Aug 13, 2018

Definitely +1 for the multi environment credentials.

Here's my two cents on the subject. I like the idea of exposing config.credentials_file. This would allow credentials path to be set per environment and it can fallback to config/credentials.yml.enc, so the change is backward compatible.

I see why the no configuration approach with the config/credentials/$environment.yml.enc can be appealing, but I don't like the confusion it will introduce with multiple options for credentials: config/credentials/$environment.yml.enc and config/credentials.yml.enc.

Lastly, dropping any kind of support for unencrypted credentials sounds great.

Cheers.

mladenilic commented Aug 13, 2018

Definitely +1 for the multi environment credentials.

Here's my two cents on the subject. I like the idea of exposing config.credentials_file. This would allow credentials path to be set per environment and it can fallback to config/credentials.yml.enc, so the change is backward compatible.

I see why the no configuration approach with the config/credentials/$environment.yml.enc can be appealing, but I don't like the confusion it will introduce with multiple options for credentials: config/credentials/$environment.yml.enc and config/credentials.yml.enc.

Lastly, dropping any kind of support for unencrypted credentials sounds great.

Cheers.

@Edouard-chin

This comment has been minimized.

Show comment
Hide comment
@Edouard-chin

Edouard-chin Aug 13, 2018

Contributor

It's automatically configured and loaded if the file config/credentials/$environment.yml.enc is available.

👍 on the idea but I'll suggest that we expose an environment variable CREDENTIALS_PATH (or something) that will take precedence over it.

The main reason is to be able in development to run a production-like environment if one has the production master key (which we can already set using the RAILS_MASTER_KEY env)

Contributor

Edouard-chin commented Aug 13, 2018

It's automatically configured and loaded if the file config/credentials/$environment.yml.enc is available.

👍 on the idea but I'll suggest that we expose an environment variable CREDENTIALS_PATH (or something) that will take precedence over it.

The main reason is to be able in development to run a production-like environment if one has the production master key (which we can already set using the RAILS_MASTER_KEY env)

@rvirani1

This comment has been minimized.

Show comment
Hide comment
@rvirani1

rvirani1 Aug 13, 2018

I completely agree with @Edouard-chin. We should have a simple approach to set where the credentials file is. I've always used had applications that run in production mode, but are actually QA, staging, beta, or other environments. Those environments might use something like a Stripe test key that needs to be different from the production key.

rvirani1 commented Aug 13, 2018

I completely agree with @Edouard-chin. We should have a simple approach to set where the credentials file is. I've always used had applications that run in production mode, but are actually QA, staging, beta, or other environments. Those environments might use something like a Stripe test key that needs to be different from the production key.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Aug 13, 2018

Member
Member

dhh commented Aug 13, 2018

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Aug 14, 2018

Member

I pushed some changes.
I'm not sure about having different name for env key (RAILS_PRODUCTION_KEY). I think using always RAILS_MASTER_KEY for all cases would be more convenient, as there is no need to have RAILS_PRODUCTION_KEY and RAILS_STAGING_KEY in the same time.


Fallback to config/credentials.yml.enc could go already to Rails 5.x.
What about having a new default for Rails 6.0 to always genereate config/credentials/production.yml.enc and config/credentials/production.key in new apps?
One reason to do it, would be to avoid having 2 ways of doing the same and to emphasize that encrypted credentials is for production-like environments.

This could be done by adding Rails.config.credentials.content_path and Rails.config.credentials.key_path that would be set to currently running environment by default, but allowing user to overwrite it (heroku-like flow). And also this way we would not break upgrading apps from 5.x to 6 as it could be done by load_defaults https://github.com/rails/rails/blob/master/railties/lib/rails/application/configuration.rb#L117-L132

Member

morgoth commented Aug 14, 2018

I pushed some changes.
I'm not sure about having different name for env key (RAILS_PRODUCTION_KEY). I think using always RAILS_MASTER_KEY for all cases would be more convenient, as there is no need to have RAILS_PRODUCTION_KEY and RAILS_STAGING_KEY in the same time.


Fallback to config/credentials.yml.enc could go already to Rails 5.x.
What about having a new default for Rails 6.0 to always genereate config/credentials/production.yml.enc and config/credentials/production.key in new apps?
One reason to do it, would be to avoid having 2 ways of doing the same and to emphasize that encrypted credentials is for production-like environments.

This could be done by adding Rails.config.credentials.content_path and Rails.config.credentials.key_path that would be set to currently running environment by default, but allowing user to overwrite it (heroku-like flow). And also this way we would not break upgrading apps from 5.x to 6 as it could be done by load_defaults https://github.com/rails/rails/blob/master/railties/lib/rails/application/configuration.rb#L117-L132

@fredngo

This comment has been minimized.

Show comment
Hide comment
@fredngo

fredngo Aug 15, 2018

@schneems maybe you could share your experience with this feature on Heroku. Are people using encrypted credentials?

Definitely would love to see @schneems' input here for how all of this can coexist with the Heroku ENV variable flow.

One possibility is to allow alligator tags in the encrypted yml file, like you can normally do in other yml files.

Example: In config/credentials/production.yml.enc, you would be able to write:

some_heroku_plugin_key: <%= ENV['SOME_HEROKU_PLUGIN_KEY' %>
some_other_api_key: axifdsr43jhgf9f

then the app can be deployed in different heroku container apps, as they are all running in production environment, but each still has their own ENV variables.

(I don't know if there would be any security implications in allowing alligator tags in the encrypted yml files -- I tried alligator tags on a vanilla credentials.yml.enc and it does not work, so it must have been disabled for a reason.)

fredngo commented Aug 15, 2018

@schneems maybe you could share your experience with this feature on Heroku. Are people using encrypted credentials?

Definitely would love to see @schneems' input here for how all of this can coexist with the Heroku ENV variable flow.

One possibility is to allow alligator tags in the encrypted yml file, like you can normally do in other yml files.

Example: In config/credentials/production.yml.enc, you would be able to write:

some_heroku_plugin_key: <%= ENV['SOME_HEROKU_PLUGIN_KEY' %>
some_other_api_key: axifdsr43jhgf9f

then the app can be deployed in different heroku container apps, as they are all running in production environment, but each still has their own ENV variables.

(I don't know if there would be any security implications in allowing alligator tags in the encrypted yml files -- I tried alligator tags on a vanilla credentials.yml.enc and it does not work, so it must have been disabled for a reason.)

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Aug 15, 2018

Member

Generally, I don't see people on Heroku using encrypted credential store at all. Instead, they use the heroku config env var store we provide them directly. As long as new behavior doesn't require people to use the encrypted config stores then it won't affect that story much.

Member

schneems commented Aug 15, 2018

Generally, I don't see people on Heroku using encrypted credential store at all. Instead, they use the heroku config env var store we provide them directly. As long as new behavior doesn't require people to use the encrypted config stores then it won't affect that story much.

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Sep 14, 2018

Member

@dhh @kaspth This is what I was talking about freeletics@df12269 - it gives possibility to customize paths and not rely only on Rails env.

Let me know if this would be fine or if we should go with solution present in this PR.

Member

morgoth commented Sep 14, 2018

@dhh @kaspth This is what I was talking about freeletics@df12269 - it gives possibility to customize paths and not rely only on Rails env.

Let me know if this would be fine or if we should go with solution present in this PR.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 14, 2018

Member

@morgoth Quick cursory look says this is the right direction. Look for a environment-specific credentials first, if not found, fall back to global credentials.

Member

dhh commented Sep 14, 2018

@morgoth Quick cursory look says this is the right direction. Look for a environment-specific credentials first, if not found, fall back to global credentials.

@morgoth morgoth changed the title from [PoC] Add support for multi environment credentials. to Add support for multi environment credentials. Sep 15, 2018

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Sep 15, 2018

Member

I implemented @dhh suggestion from #33521 (comment)
Test failure looks like some timeout, so not related to this PR.
Let me know if there is anything more missing.

Member

morgoth commented Sep 15, 2018

I implemented @dhh suggestion from #33521 (comment)
Test failure looks like some timeout, so not related to this PR.
Let me know if there is anything more missing.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 17, 2018

Member

This looks good to me. @kaspth any concerns?

Member

dhh commented Sep 17, 2018

This looks good to me. @kaspth any concerns?

@Edouard-chin

Looks great and fit all use cases I had on few of our apps

@sidot3291

This comment has been minimized.

Show comment
Hide comment
@sidot3291

sidot3291 Sep 17, 2018

Which is being approved here? Code in this PR or @morgoth's new one linked in #33521 (comment) ?

I prefer the new PR since it would allow credentials on heroku with separation between production/staging.

sidot3291 commented Sep 17, 2018

Which is being approved here? Code in this PR or @morgoth's new one linked in #33521 (comment) ?

I prefer the new PR since it would allow credentials on heroku with separation between production/staging.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 17, 2018

Member

Ah, I didn't even realize they were different. @morgoth Which approach are you proposing?

Member

dhh commented Sep 17, 2018

Ah, I didn't even realize they were different. @morgoth Which approach are you proposing?

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Sep 17, 2018

Member

I was proposing freeletics@df12269 but thought it was rejected ;-), that's why I finished the original idea.
With proposed solution, the difference is that in Rails 6.0 default would change (config/credentials.yml.enc -> config/credentials/production.yml.enc), but it would be more flexible as @sidot3291 noticed

Member

morgoth commented Sep 17, 2018

I was proposing freeletics@df12269 but thought it was rejected ;-), that's why I finished the original idea.
With proposed solution, the difference is that in Rails 6.0 default would change (config/credentials.yml.enc -> config/credentials/production.yml.enc), but it would be more flexible as @sidot3291 noticed

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 17, 2018

Member

My mistake. I'm happy to allow the flexibility of config.credentials.content_path/key_path as long as the per-environment defaults are as described. Feel free to update this PR to include that flexibility, and then I think we're good to go pending an implementation review by @kaspth. Thanks for sticking with this 🙏

Member

dhh commented Sep 17, 2018

My mistake. I'm happy to allow the flexibility of config.credentials.content_path/key_path as long as the per-environment defaults are as described. Feel free to update this PR to include that flexibility, and then I think we're good to go pending an implementation review by @kaspth. Thanks for sticking with this 🙏

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Sep 18, 2018

Member

What about now? It adds the possibility to set config.credentials.content_path and config.credentials.key_path and there will be no switch in defaults for Rails 6.

@Edouard-chin would you mind having another look, as the code changed?

Member

morgoth commented Sep 18, 2018

What about now? It adds the possibility to set config.credentials.content_path and config.credentials.key_path and there will be no switch in defaults for Rails 6.

@Edouard-chin would you mind having another look, as the code changed?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 19, 2018

Member

Just one implementation comment, then I think we're good to go. Lovely work on this! 👌

Member

dhh commented Sep 19, 2018

Just one implementation comment, then I think we're good to go. Lovely work on this! 👌

Support environment specific credentials file.
For `production` environment look first for `config/credentials/production.yml.enc` file that can be decrypted by
`ENV["RAILS_MASTER_KEY"]` or `config/credentials/production.key` master key.
Edit given environment credentials file by command `rails credentials:edit --environment production`.
Default behavior can be overwritten by setting `config.credentials.content_path` and `config.credentials.key_path`.
@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Sep 19, 2018

Member

Code updated and tests are green.

Member

morgoth commented Sep 19, 2018

Code updated and tests are green.

@dhh dhh merged commit e0d3313 into rails:master Sep 19, 2018

2 checks passed

codeclimate All good!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jeremy

This comment has been minimized.

Show comment
Hide comment
@jeremy

jeremy Sep 19, 2018

Member

This rocks!

Member

jeremy commented Sep 19, 2018

This rocks!

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Sep 20, 2018

Member

@morgoth why you little! 😄 …thanks for stepping up on this ❤️

Member

kaspth commented Sep 20, 2018

@morgoth why you little! 😄 …thanks for stepping up on this ❤️

@fredngo

This comment has been minimized.

Show comment
Hide comment
@fredngo

fredngo Sep 21, 2018

Will this only make it into Rails 6.0?

TBH I've held off upgrading from 5.1 to 5.2 because there was some uncertainty as to how to deal with multi-environment credentials.. Any chance this will make it into Rails 5.2.2?

fredngo commented Sep 21, 2018

Will this only make it into Rails 6.0?

TBH I've held off upgrading from 5.1 to 5.2 because there was some uncertainty as to how to deal with multi-environment credentials.. Any chance this will make it into Rails 5.2.2?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 21, 2018

Member
Member

dhh commented Sep 21, 2018

@kissu

This comment has been minimized.

Show comment
Hide comment
@kissu

kissu Oct 11, 2018

Hi , sorry but I do not understand how we do actually use it.
I've pulled 5.2.1 and tried bin/rails credentials:edit --environment staging but no success.

I did not find anything in the docs neither. 😓

kissu commented Oct 11, 2018

Hi , sorry but I do not understand how we do actually use it.
I've pulled 5.2.1 and tried bin/rails credentials:edit --environment staging but no success.

I did not find anything in the docs neither. 😓

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Oct 11, 2018

Member

@kissu it will be only available in Rails 6.0

Member

morgoth commented Oct 11, 2018

@kissu it will be only available in Rails 6.0

@kissu

This comment has been minimized.

Show comment
Hide comment
@kissu

kissu Oct 11, 2018

@morgoth I guess I understood this part poorly

This is an upgrade for Rails 6.0. But if you wanted to extract the changes into a gem and have that as a stop-gap, feel free! Or you can upgrade to this version of master and verify that it works.

So, until then, what can we use to get multi environment credentials ?

I guess sinsoku/rails-env-credentials should make it. :D

kissu commented Oct 11, 2018

@morgoth I guess I understood this part poorly

This is an upgrade for Rails 6.0. But if you wanted to extract the changes into a gem and have that as a stop-gap, feel free! Or you can upgrade to this version of master and verify that it works.

So, until then, what can we use to get multi environment credentials ?

I guess sinsoku/rails-env-credentials should make it. :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment