#123 Encrypted Credentials in Rails 5.2

Summary

In this episode, we take a look at the Encrypted Credentials of Ruby on Rails 5.2 and how we can patch it so that we can use other YAML files like a development.yml and test.yml.
rails environment encryption 12:01

Resources

Source - https://github.com/driftingruby/123-encrypted-secrets-in-rails-52

Additional Notes: To make this more complete, looking at the config_for source, you could add in ERB support and parsing error handling.

config_for# File railties/lib/rails/application.rb, line 227
    def config_for(name)
      yaml = Pathname.new("#{paths["config"].existent.first}/#{name}.yml")

      if yaml.exist?
        require "erb"
        (YAML.load(ERB.new(yaml.read).result) || {})[Rails.env] || {}
      else
        raise "Could not load configuration. No such file - #{yaml}"
      end
    rescue Psych::SyntaxError => e
      raise "YAML syntax error occurred while parsing #{yaml}. " "Please note that YAML must be consistently indented using spaces. Tabs are not allowed. " "Error: #{e.message}"
    end


Download Source Code

Summary

Terminalrails credentials:help
rails credentials:edit

EDITOR='code --wait' rails credentials:edit
rails c
RAILS_ENV=production rails c
Rails ConsoleRails.application.credentials.aws
Rails.application.credentials.env.aws
Rails.application.credentials.env.aws[:access_key_id]
Rails.application.credentials.env.secret_key_base
config/application.rbrequire_relative 'boot'
require 'rails/all'
require_relative 'rails_env'
Bundler.require(*Rails.groups)

module Template
  class Application < Rails::Application
    config.load_defaults 5.2
    config.after_initialize do
      Rails.application.credentials.env = RailsEnv.new
    end
  end
end
config/rails_env.rbclass RailsEnv
  def initialize
    load_environment_variables unless Rails.env.production?
    allow_encrypted_credentials
  end

  private

  def load_environment_variables
    return unless File.exist?(file_name)
    HashWithIndifferentAccess.new(YAML.safe_load(File.open(file_name))).each do |key, value|
      self.class.send :define_method, key.downcase do
        value
      end
    end
  end

  def allow_encrypted_credentials
    self.class.send :define_method, :method_missing do |m, *_args, &_block|
      Rails.application.credentials.send(m)
    end
  end

  def file_name
    File.join(Rails.root, 'config', "#{Rails.env}.yml")
  end
end



sekmo said about 1 year ago on Encrypted Credentials in Rails 5.2 :

How can we use the Credentials feature in a 5.0.2 rails project? Is there any gem that has a similar approach?

kobaltz PRO said about 1 year ago on Encrypted Credentials in Rails 5.2 :

You're best bet would be to upgrade to Rails 5.1.X if possible and use the encrypted secrets. It will at least get the code base up to a point where swapping out the encrypted secrets for credentials an easier task.

sekmo said about 1 year ago on Encrypted Credentials in Rails 5.2 :

Thanks! But what can I do if at the moment I have to keep the 5.0.x version?

kobaltz PRO said about 1 year ago on Encrypted Credentials in Rails 5.2 :

I'd say it would depend on how you're deploying to the production environment.

Basically, you can use your secrets.yml file to store all of the keys and values. Within each of the values, reference an environment variable. So, within the file, you may have something like this:

production:
  database_password: <%= ENV['DATABASE_PASSWORD'] %> 

At least, in this way, you're not storing sensitive information in the codebase. From here, you can set your Environment Variables how you see fit. On a production deployment, it could be through ansible/chef/capistrano that is setting the ENV Vars or something similar.

mcfoton said 10 months ago on Encrypted Credentials in Rails 5.2 :

Thanks for the episode! Though what are the pros compared to this solution?

kobaltz PRO said 10 months ago on Encrypted Credentials in Rails 5.2 :

In this situation, the developers must have access to the master key which would expose production secrets to more people than necessary. This of course depends on the layout of the R&D team. If it is a solo developer working on a personal project then the exposure is obviously limited. However, in a larger setting, often the developers will not have access nor the secrets to the production environment.

mcfoton said 10 months ago on Encrypted Credentials in Rails 5.2 :

Got it, thanks!

Login to Comment