How Do You Secure database.yml?

Ruby on-RailsSecurityDeployment

Ruby on-Rails Problem Overview


Within Ruby on Rails applications database.yml is a plain text file that stores database credentials.

When I deploy my Rails applications I have an after deploy callback in my Capistrano recipe that creates a symbolic link within the application's /config directory to the database.yml file. The file itself is stored in a separate directory that's outside the standard Capistrano /releases directory structure. I chmod 400 the file so it's only readable by the user who created it.

  • Is this sufficient to lock it down? If not, what else do you do?
  • Is anyone encrypting their database.yml files?

Ruby on-Rails Solutions


Solution 1 - Ruby on-Rails

The way I have tackled this is to put the database password in a file with read permissions only for the user I run my application as. Then, in database.yml I use ERB to read the file:

production:
  adapter: mysql
  database: my_db
  username: db_user
  password: <%= begin IO.read("/home/my_deploy_user/.db") rescue "" end %>

Works a treat.

Solution 2 - Ruby on-Rails

You'll also want to make sure that your SSH system is well secured to prevent people from logging in as your Capistrano bot. I'd suggest restricting access to password-protected key pairs.

Encrypting the .yml file on the server is useless since you have to give the bot the key, which would be stored . . . on the same server. Encrypting it on your machine is probably a good idea. Capistrano can decrypt it before sending.

Solution 3 - Ruby on-Rails

Take a look at this github solution: https://github.com/NUBIC/bcdatabase. bcdatabase provides an encrypted store where the passwords can be kept separated from the yaml files.

> bcdatabase > > bcdatabase is a library and utility > which provides database configuration > parameter management for Ruby on Rails > applications. It provides a simple > mechanism for separating database > configuration attributes from > application source code so that > there's no temptation to check > passwords into the version control > system. And it centralizes the > parameters for a single server so that > they can be easily shared among > multiple applications and easily > updated by a single administrator.

Solution 4 - Ruby on-Rails

Even if you secure the database.yml file, people can still write that uses the same credentials if they can change the code of your application.

An other way to look at this is: does the web application have to much access to the database. If true lower the permissions. Give just enough permissions to the application. This way an attacker can only do what the web application would be able to do.

Solution 5 - Ruby on-Rails

Better late than never, I am posting my answer as the question still remains relevant. For Rails 5.2+, it is possible to secure any sensitive information using an encrypted file credentials.yml.enc.

Rails stores secrets in config/credentials.yml.enc, which is encrypted and hence cannot be edited directly. We can edit the credentials by running the following command:

$ EDITOR=nano rails credentials:edit

secret_key_base: 3b7cd727ee24e8444053437c36cc66c3
production_dbpwd: my-secret-password

Now, these secrets can be accessed using Rails.application.credentials.

So your database.yml will look like this:

production:
  adapter: mysql
  database: my_db
  username: db_user
  password: <%= Rails.application.credentials.production_dbpwd %>

You can read more about this here

Solution 6 - Ruby on-Rails

If you're very concerned about security of the yml file, I have to ask: Is it stored in your version control? If so, that's another point where an attacker can get at it. If you're doing checkout/checkin over non-SSL, someone could intercept it.

Also, with some version control (svn, for exampl), even if you remove it, it's still there in the history. So, even if you removed it at some point in the past, it's still a good idea to change the passwords.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJohn TopleyView Question on Stackoverflow
Solution 1 - Ruby on-RailsOllyView Answer on Stackoverflow
Solution 2 - Ruby on-RailsJames A. RosenView Answer on Stackoverflow
Solution 3 - Ruby on-RailsslmView Answer on Stackoverflow
Solution 4 - Ruby on-RailsPeter StuifzandView Answer on Stackoverflow
Solution 5 - Ruby on-RailsRajkaran MishraView Answer on Stackoverflow
Solution 6 - Ruby on-RailsMicahView Answer on Stackoverflow