Skip to content

Integration with encrypted Rails credentials #68

Open

Description

@smith

Rails 4.1 introduces a built-in convention for having a secrets.yml with secrets in it: http://edgeguides.rubyonrails.org/4_1_release_notes.html#config-secrets-yml

It would be cool if this gem did some of these things:

  • Aliased Rails.application.secrets to Settings.secrets
  • Shimmed the secrets.yml functionality in for Rails < 4.1
  • Allowed you to have a secrets.local.yml or config/secrets/production.yml that behave the same way as the existing conventions do for non-secrets files

I think this gem is a better overall solution to managing configuration, but if Rails is making this a thing, it would make sense to go along with it and make this gem work nicely with the new stuff.

Activity

  1. added this to the 1.0 milestone on Mar 31, 2014
  2. Darkside73 commented on Aug 18, 2014

    @Darkside73

    Will be great

  3. modified the milestone: 1.0 on May 12, 2016
  4. pkuczynski commented on Jun 28, 2019

    @pkuczynski
    Member

    @rdubya would you like to have a look at this one?

  5. added this to the 2.0.1 milestone on Jun 28, 2019
  6. rdubya commented on Jul 1, 2019

    @rdubya
    Contributor

    Rails 5 gets away from using secrets and now has a credentials file. It would be cool to have similar functionality built into this gem since it provides a much more flexible way of managing environment settings.

  7. pkuczynski commented on Aug 6, 2019

    @pkuczynski
    Member

    I think we could add alias Rails.application.secrets to Settings.secrets if anybody is interested in this. However, I would keep the way secrets.yml work meaning with environments groups.

    @smith @Darkside73 are you still interested in this?

  8. modified the milestones: 2.1.0, 2.2.0, 2.3.0 on Jan 3, 2020
  9. modified the milestones: 4.0.0, 4.0.1 on Jun 1, 2022
  10. smtlaissezfaire commented on Oct 23, 2023

    @smtlaissezfaire

    FYI This bug caused me so much pain...

    the config gem eager loads credentials, causing any overrides to not be respected in config/application.rb

  11. pkuczynski commented on Oct 24, 2023

    @pkuczynski
    Member

    @smtlaissezfaire I would welcome a PR fixing this. Would like to have a look? I no longer work with Rails for few years now so it would be hard for me to get back to it...

  12. modified the milestones: 4.1.0, Next on Dec 18, 2023
  13. noxasch commented on Feb 12, 2024

    @noxasch

    Just sharing my workaround to work with Rails.application.credentials. Not sure if this the best solution, but this monkey patch works for me to utilize Setting and Rails secret management.

    # config/initializers/config.rb
    module Config
      def self.load_files(*sources)
        config = Options.new
    
        # add settings sources
        [sources].flatten.compact.each do |source|
          config.add_source!(source)
        end
    
        config.add_source!(Sources::EnvSource.new(ENV)) if Config.use_env
        load_credentials(config) # call Settings override
        config.load!
        config
      end
     
      # override with crendentials
      def self.load_credentials(config)
        if Rails.env.production? || Rails.env.staging?
          # Load and replace secret from credentials
          config.add_source!(Rails.application.credentials.to_h)
        end
      end
    end
    
    Config.setup do |config|
      # your config
    end
  14. cjlarose commented on Feb 12, 2024

    @cjlarose
    Member

    @noxasch I like the idea of merging the Rails credentials into the Settings exported by config. I think that's probably the most ergonomic workflow: all configuration lives in Settings, but you can still use encrypted credentials (they just get merged in)

    I could use help understanding why the monkey patch is necessary, though. If, in an initializer, you just

    Settings.add_source!(Rails.application.credentials.to_h)
    Settings.reload!

    Does that work? Or does it not have the opportunity to pick up the credentials correctly?

  15. changed the title [-]Integration with secrets.yml[/-] [+]Integration with encrypted Rails credentials[/+] on Feb 12, 2024
  16. noxasch commented on Feb 13, 2024

    @noxasch

    @cjlarose Yup correct, you can also do that. As for me I want to load the Settings when the config gem is being initialize. So everything related to Settings work as if it is part of the gem. Probably better if the gem allow us to include a block before the config first load though.

  17. cjlarose commented on Feb 13, 2024

    @cjlarose
    Member

    Yeah, that makes sense. In a non-Rails application, config doesn't do anything automatically and the user has the opportunity to customize everything that gets merged into Settings (specific YAML files, hard-coded Hashes, environment variables, etc), but the Rails integration makes some assumptions and performs the first load before the user has the chance to customize anything. That's a separate issue. In the meantime, I'm open to a PR that adds a new (off by default) setting Config.use_rails_credentials that would basically just do what @noxasch 's patch does.

    Config.setup do |config|
      config.use_rails_credentials = true
    end

    I think we might have to use something like Rails.application.credentials.to_h.deep_stringify_keys though in order for merging to work correctly with other config sources.

  18. pkuczynski commented on Feb 18, 2024

    @pkuczynski
    Member

    @noxasch would you like to fire up a PR for this change?

  19. noxasch commented on Feb 19, 2024

    @noxasch

    Sure I can work on a PR for this @pkuczynski

  20. dominh commented on Apr 22, 2024

    @dominh
    Contributor

    Is any help still needed?
    I'd like to have it in my project too and I see needs help badge, but I'm not getting what help is still needed.

  21. modified the milestones: 5.6.0, Next on Jul 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions