[Infrastructures] Version control over sensitive config files

DJ Gregor dj@gregor.com
Sat, 15 Feb 2003 15:10:39 -0500


On Fri, Feb 14, 2003 at 10:57:37AM -0500, ph-infrastructure@bluepenguin.us wrote:
> The application also has some config files with sensitive information -
> clear text passwords for communicating with other applications.  (Not
> what I'd like to see, but that's what I've got to work with.)  There are
> perhaps 60 config files; perhaps 5 of them have this kind of sensitive
> information.  The people who maintain template files and graphics should
> not be automatically allowed to see these config files

The way that I've dealt with this before included removing sensitive
information from the configuration files and then storing the santized
configuration files in CVS.  In one case, the updates into CVS were
manual, and occured whenever someone updated router configuration files
(they would manually run a script which would take the update router
configuration file, remove secrets, and import it into CVS).  Some
of my coworkers who manage a large campus network do a similar thing,
but they have a daemon that runs which regularly downloads router
configurations from all routers that they know about and checks
them into CVS and they have changed (removing secret information in
the process).

A coworker and I also setup a system to automatically import
configuration files from an iPlanet directory (LDAP) server,
although we didn't remove any secret information--the CVS
repository was fairly private.  You could do something like
this, and either remove secret information before it gets
checked in, or keep the permissions on the files (actually,
the directories) in the CVS repository fairly tight.  Here is
the script for th eiPlanet directory server (4.x), BTW:

	http://www.gregor.com/download/scripts/autocvsimport

I'm also going to be working on a solution like this in the
next few months for archiving firewall configurations from
UNIX firewalls into CVS and restoring them back to firewalls.


	- deej

-- 
Daniel (DJ) Gregor, <dj@gregor.com>             http://www.gregor.com/