0

What is the best way to securely distribute config files amongst developers? My team uses git for version control but I don't want to check-in some config files with our codebase as most developers have their own modifications and often developers work remotely and I don't want these configs to be traveling over the web (they have some default passwords we use). Also our production servers are entirely secure and walled off but I want the configs there to be updated when new keys are added. I want it to be easy for new developers to procure the latest default configs. Also, if new config-keys are added, developers automatically get the new key-values and be secure at the same time and not be checked in with the version control system.

pathikrit
  • 32,469
  • 37
  • 142
  • 221
  • 1
    What about this solution? http://stackoverflow.com/questions/3071013/is-there-an-encrypted-version-control-system – darlinton Mar 16 '12 at 20:10
  • @darlinton - That works - but my configuration files can be also production vs dev vs qa configurations. I don't want to check in all those with my code. I want to modify config files on the fly when I run my code without rebuilding/repdeploying. I also want to securely distribute them rsync style to dev/qa machines also. – pathikrit Mar 16 '12 at 20:26
  • You never mentioned, but if your projects are written in Java and you are using maven, you can have several profiles with their own set of settings (like production, development, qa, some-devs' personal config and etc.). Then it only matters to which profile you pass to the command line in order to build. This, however, does not solve the secure config distribution issue. – Ivaylo Slavov Mar 23 '12 at 17:34

3 Answers3

2

I would recommend using Chef (or puppet). Give developers the ability to get the config files directly from the Chef Server and run a chef client on your production server to pull the latest configs down. You can setup Chef to only allow secure connections.

If your developers have dev machines, those can also run chef clients to pull so they don't have to manually check the chef server for updates.

Version control is not for managing system configurations and automating them getting pushed out... thats what chef and puppet are for.

Ray
  • 40,256
  • 21
  • 101
  • 138
0

You could store encrypted copies of the configuration files in the VCS.

Encrypt the config files, separately or as a bundle, with your encryption software of choice (e.g., GnuPG), and then just check them in. Distribute the password to developers however you distribute other passwords they need.

Encrypting the files will break some VCS features like space efficiency and diffs, but a side-channel solution would likely lose those too. This way you still have the advantage of versioned config files with limited history. The loss of space efficiency should also be trivial, unless your configuration files are unusually large.

blahdiblah
  • 33,069
  • 21
  • 98
  • 152
0

If you are really concerned about security, it is much safer to use a certificate based authentication system, like ssh, or the way you can authenticate to webservers using browser client certificates. then you don't need to distribute passwords, but have the developers send you their public keys, which you can then use to authorize ssh or http access to specific resources.

If you must have passwords, you should at least separate them from the rest of the configuration, so you only need to distribute the passwords securely, and can use a more convenient method ( for instance using git patches ) to send updates for the rest of the config files.

Willem Hengeveld
  • 2,758
  • 23
  • 19