I'm looking to hear some best practices...
Assuming a web application that interacts with a few different production servers (databases, etc.)... should the configuration files that include database passwords be stored in source control (e.g., git, svn)?
If not, what's the best way to keep track of server database (or other related) passwords that your application needs access to?
Edit: added a bounty to encourage more discussion and to hear what more people consider best practice.
Storing a password in the registry does not secure it. Anyone with access to the server can read it there.
It really depends on your application. Storing the settings in the database has several advantages: Security - users can easily alter settings in the file or overwrite the contents. For Distribution - the same settings can be updated and loaded onto any machines on the network.
Configuration data is stored in operating system environment variables.
There's no single "silver bullet" answer here and it would all greatly depend on details.
First of all, I consider best practice to separate all source code from configuration in separate repository. So, source code remains source code, but it's installation or deployment (with configuration, passwords, etc) is the whole other thing. This way you'll firmly separate developers' tasks from sysadmins' tasks and can ultimately build 2 distinct teams doing what's they're good at.
When you have separate source code repository + deployment repository, your best next bet is considering deployment options. Best way I see here is using deployment procedures typical for a chosen OS (i.e. building autonomous packages for a chosen OS the way that OS's maintainers do).
For example, Red Hat or Debian packaging procedures usually mean grabbing a tarball of software from external site (that would be exporting sources from your source code VCS), unpacking it, compiling and preparing packages ready for deployment. Deployment itself should ideally mean just doing a quick & simple command that would install the packages, such as rpm -U package.rpm
, dpkg --install package.deb
or apt-get dist-upgrade
(given that your built packages go to a repository where apt-get would be able to find them).
Obviously, to get it working this way, you'll have to supply all configuration files for all components of a system in a fully working state, including all addresses and credentials.
To get more concise, let's consider a typical "small service" situation: one PHP application deployed across n application servers running apache / mod_php, accessing m MySQL servers. All these servers (or virtual containers, that doesn't really matter) reside in a protected private network. To make this example easier, let's assume that all real internet connectivity is fronted by a cluster of k http accelerators / reverse proxies (such as nginx / lighttpd / apache) which have very easy configuration (just internal IPs to forward to).
What do we have for them to be connected and fully working?
Note that there are 2 different "types" of information here: IPs/hostnames is something fixed, you'd likely want to assign them once and for all. Logins & passwords (and even database names), on the other hand, are purely for connectivity purposes here - to make sure for MySQL that it's really our PHP application connecting to it. So, my recommendations here would be splitting these 2 "types":
The last and the toughest question remains here: how to create deployment packages? There are multiple techniques available, 2 main ways are:
For an example above, I'd create packages like:
my-application-php
- which would depend on mod_php, apache and would include generated file like /etc/my-php-application/config.inc.php
that will include MySQL database IPs/hostnames and login / password generated as md5(current source code revision + salt)
. This package would be installed on every of n application servers. Ideally, it should be able install on a cleanly installed OS and make a fully working application cluster node without any manual activity.my-application-mysql
- which would depend on MySQL-server and would include post-install script that: /etc/my-php-application/config.inc.php
, using md5 algorithm)Ultimately, it should bring the benefit of upgrading your deployment using single command like generate-packages && ssh-all apt-get dist-upgrade
. Also, you do not store inter-applications passwords anywhere and they get regenerated on every update.
This fairly simple example illustrates a lot of methods you can employ here - but, ultimately, it's up to you to decide which solution is better here and which one is overkill. If you'll put more details here or as a separate question, I'll gladly try to get into details.
Leaving aside the point that passwords should never be stored in plain text anywhere (other than someone's cranium or a locked vault accessible only to the CEO, CFO and CIO (and needing all three keys at once)), you should store everything into source control that's required to build your product.
That means not just your source, but even the specifications for the build machines, compiler options, the compilers themselves and so on.
If we could find a way to check in the physical hardware, we'd do that too :-)
Everything that can be reproduced by the build process itself, or anything for running rather than building the software (such as your passwords) does not generally belong under source control but some shops will do that for their executables, generated docs and so on, just so that they can quickly get a specific release out for installation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With