Should server/database config files, including passwords, be stored in source control?

Question

I\'m looking to hear some best practices...

Assuming a web application that interacts with a few different production servers (databases, etc.)... should the configu

Answer 1

No. Production password should be configured directly on the server. You should create a deployment instructions for the deployment team/person to change the right properties file during deployment.

Answer 2

I prefer to have a local_settings file beside the main settings file. This local_settings shouldn't be added to the repository, but I will add a sample.local_setting to the repository to show the structure of this file.

In run time if a local_settings exists, its values will override the values of main settings file.

For example in python:

settings.py:

log='error.log'
db=lambda:None
db.host='localhost'
db.user=''
db.password=''

try:
    import local_settings
except ImportError:
    pass

local_settings.py:

from settings import *

db.user='abcd'
db.password='1234'

Answer 3

Sample configurations file, sure, I would put them under version control. But usually not with realworld access data such as server addresses or passwords. More somethinglike

# program.conf
#
# mysql option for $myprog.
#
#SERVER_ADDR=127.0.0.1
#SERVER_USER=mysql
#SERVER_PASSWD=abcdef

Answer 4

Without a proper build process, I'm using this strategy (for PHP apps):

1. Make a folder /etc/companyname

2. In it, place two files:

   <?php // env.php
   return 'prod'; 
   

   <?php // appname-prod.php
   return array(
     'db' => array( /* credentials */ ),
     /* other host-specific conf data */
   ); 
   

3. Make both files readable only by your PHP process

Now your app's config file will be something like:

<?php // config.php
$env = (require "/etc/companyname/env.php");
$creds = (require "/etc/companyname/appname-{$env}.php");

With this in place, the environment defines the credentials used, and you can move code between pre-configured environments (and control some options with $env). This, of course, can be done with server environment variables, but this a) is simpler to setup and b) doesn't expose credentials to every script on the server (won't show up in a stray debugging junk like phpinfo()).

For easier reading outside PHP you could make the credential files JSON or something and just put up with the tiny performance hit (APC won't cache them).

Answer 5

I would always exclude vital config files that contain passwords or other access details (like for databases), it's purely best practice. Plus on top of that source- and version-control serves usually more than one user and not all of them work with the same database details or even with the same server config (domains etc) and for this purpose config files should stay excluded fromt he whole lot.

Answer 6

Passwords should not be stored in source control. At all. Ever. See How to keep secrets secret

Passwords, servernames, etc. are part of the deployment configuration as performed by the server administrator. It is essential to document this procedure and place the documented procedure under control.

Alternatively the deployment configuration could be performed by a script that the sysadmin would run to perform the configuration, and during the script execution it would ask the sysadmin to provide the required information. Again this script must be kept in version control.

Everything else, apart from server configuration must be in source control.

Storing server configuration in source control is generally a bad idea because it gets in the way of deployments and can cause small disasters (e.g. when someone doesn't realise that their test version deployed from source control is communicating with a live service).

Always keep these configuration files outside of the webroot.

Trusted connections may be an option, allowing known IP addresses to connect to services by configuration of that service..

• When running on Windows use integrated authentication. Refer to Securing Data Access
• MySQL configure to allow connections from localhost and to not require a password. See Step 7: Securing a MySQL Server on Windows
• PostgreSQL you can use ~/.pgpass.