2

I read the solution at: Best way to create custom config options for my Rails app? which seems promising. i.e. storing development and production credentials in config/config.yml. But then I thought.

If we have a team of developers, and interns, they would be exposed to this file with all production credentials. The consensus, is to trust your team. But honest human mistakes do happen: computer left on / unlocked, trojans, friends using the computer, etc.

I know Heroku has something called config vars + foreman. However, for things like AWS, its not as simple as creating a new access key and delegating that access key to a specific bucket. It doesn't work like that. The only way I can think of is to create a new AWS account solely for development purposes. If I go this route, I would have to create development accounts for other similar 3rd party services too.

Is there an alternative option?

Community
  • 1
  • 1
Christian Fazzini
  • 19,613
  • 21
  • 110
  • 215

2 Answers2

1

I use SettingsLogic.

I create two models for that : Settings and PrivateSettings. And I separate the settings : passwords, token, api key... in PrivateSettings and the rest in Settings.

For Settings :

class Settings < Settingslogic
  source "#{Rails.root}/config/settings.yml"
  namespace Rails.env
end

The settings.yml file is stored in Git.

For PrivateSettings :

class PrivateSettings < Settingslogic
  source "#{Rails.root}/config/private_settings.yml"
  namespace Rails.env
end

I store a private_settings-sample.yml file in Git, to keep an example in sync. The production data are obvioulsy not populated. A dev clone the repo, and rename it to private_settings.yml to be able to work.

config/private_settings.yml is also in .gitignore to avoid an inclusion by mistake.

Going to prod, I use a specific task in Capistrano to create a symbolic link to the proper private_settings.yml file stored in the server (in a dir config next to current, releases and shared) :

namespace :deploy do
  task :config_settings do
    run "cd #{current_path}/config && ln -sf #{shared_path}/../config/private_settings.yml private_settings.yml"
  end
end
after "deploy:update", "deploy:config_settings"
Maxime Garcia
  • 610
  • 3
  • 6
  • I don't store yet MyApp::Application.config.secret_token (located in `config/initializers/secret_token.rb`) in PrivateSettings. It would be a good practice to not leave this in Git as it secures your cookies. – Maxime Garcia Jun 08 '12 at 08:08
0

i'm not sure if you can prevent developers from knowing the password. even if you have completely separated service that provides you the correct credentials/keys, developers can always debug the working application, add code that logs passwords etc. those are people you have to trust. the only way i see it possible is to have admins that puts required keys on the classpath and always do code reviews to prevent all attempts of reading the credentials at runtime

piotrek
  • 13,982
  • 13
  • 79
  • 165